Customers
The customer object and the allowed CRUD operations on the related resource endpoint
Last updated
The customer object and the allowed CRUD operations on the related resource endpoint
Last updated
Customers must contain an email address and, optionally, a password. Registered customers can get an access token through the password flow to manage their data.
For each newly created customer a shopper_reference
is automatically generated. It is sent to the payment gateways and identifies the shopper during the payment sessions. As long as you stay within the number of characters allowed (min 3, max 128) it can be updated at your leisure in case you need a specific format — e.g. platform mirgration.
Customer status can be one of:
prospect
— with no orders
acquired
— with one order
repeat
— with two or more orders
Customers can be associated with groups to get access to the related private markets.
In compliance with data privacy regulations (like GDPR, CCPA, etc.) and in order to reduce the risk of data breaches or misuse, you can request some customers' data to be anonymized. To manage customer data anonymization you can leverage two dedicated trigger attributes:
_request_anonymization
— send it to submit a data anonymization request for the customer.
_cancel_anonymization
— send it to revoke an ongoing (not yet completed) anonymization request for the customer.
You can then check the status and other info about an anonymization request by inspecting the anonymization_status
and anonymization_info
objects respectively.
For security reasons, the request must be submitted by a user belonging to the same organization as the customer whose data needs to be anonymized. That's why the API calls to pass the two triggers above must be authenticated by an integration token with specific permissions that you can get by following the steps below:
Log in to your organization Dashboard and take note of your .
Use those credentials to to the /api/user
endpoint of the Provisioning API and take note of your user ID.
specifying the user ID above as the owner.
Get the access token using the with integration API credentials.
The correct JWT assertion should have the following structure:
The issued token's payload should have the following structure: