Setting Up Profile API

Below are the best-practices that you need to adhere while setting up Profile API.

As per the Profile API use cases defined in the Discovery Phase, each use case or system must have a separate API key to ensure traceability.
You should invoke the Profile API once per session, only. As the response is unlikely to change, even if the API is called multiple times, you can cache the response locally for subsequent use within the session. However, note that calling the API multiple times is still counted against your usage metrics.
To avoid unnecessary count against your usage metrics, you can add a check to prevent calling the Profile API when there is no ID to look up.
You can use a separate API token for each interface. This ensures that each interface is uniquely identified and managed separately. Using separate API tokens also enhances the security of your system by limiting access to individual interfaces when one token is compromised.
For user lookups, you can use one of the immutable IDs or primary IDs that you have selected for ID resolution. This ensures that the user is identified uniquely and the lookup is consistent across the different systems.
To ensure security, we do not recommend you implement Profile API on a web interface. Instead, you can implement the API remotely using a service layer. This approach minimises the risk of unauthorised access and other security vulnerabilities that may arise when implementing the API on a web interface.
To call a specific attribute of a user, you can use the Fetch node. This allows you to retrieve only the required attribute instead of calling all user attributes on the client side.