Lexer provides its customers with a low-latency API for reading Profile data from within the Lexer CDP.
Although the uses of this API are open to the customer's imagination, we foresee most using this for:
- On-site personalisation: integrated with OSP platforms such as Optimizley, Adobe Experience Manager, etc
- In-Site, App, or Platform via custom integration to change the user experience of your digital platforms
- Real-time ad personalisation or bidding
However, this API is not intended to be used as a method of large scale extraction of data - such as exporting large segments of profile data. We provide customers with other, more scalable platforms, to deliver to those use cases.
Access to the Profile Read API requires configuration with the Lexer team as security is of the utmost importance.
Securing the Profile Data API is a primary concern and needs to be designed in collaboration with the owner of the platforms consuming this API.
The caution here is that light security could result in unwanted figures being able to request profile data - essentially being able to access all the profile data held within the Lexer CDP.
To overcome this, we work with the Customer and platform owner to implement a series of authentication and security controls specific to the use case. These may include:
- Whitelisted IP addresses for server-to-server communication
- API keys with limited scope for data extraction
- CORS for server-to-browser/app communication
- The setup of a customer-owned proxy to prevent public access without internal authentication
Regardless of the solution determined, Lexer also rate limits and has alerting built into the API to ensure outlier requests are handled with the utmost caution.
To prevent misuse of the Profile Data API, the API is rate limited within boundaries agreed with the Customer upon setup.
This is defined as the number of requests per minute permitted before returning a
429 Too Many Requests response code to the requester.
Lexer monitors the number of requests for billing and security purposes, these reports can be provided to customers to help alter rate limiting rules to ensure platform performance and cost management.
The Profile Read API accepts
POST requests only, and returns JSON upon return.
API requests are made by providing a known identifier of the profile you would like to load data of. Depending on your CDP data set and configuration, you will likely be able to look up via:
It is possible to customise the supported links for a customer in particular use cases, however, may require additional configuration of the CDP.
Profiles can only be accessed one at a time, as the use case for our PDaaS API is to power personalisation use cases, not exports or large transfers.
Lexer has other, more scalable methods, of transferring high volumes of profiles, contact us for more information.
Internally, Lexer attempts to find the profile with the link type matching the provided link value.
We respond with one of the following 4 HTTP codes:
In the scenario of a
200 response, the JSON payload will contain the Profile attributes configured to be exposed by the API...
The data exposed by the API is configured on an API by API basis.
Meaning each Customer can configure which data is exposed for specific API credentials - allowing one implementation to access more data than the next in an attempt to limit the inherit risk of such public-facing APIs.
Updated 14 days ago
For detail on the API request parameters, authentication, and responses, check out the API documentation: