Customers

The customer object and the allowed CRUD operations on the related resource endpoint

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.

Customer data anonymization

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:

1. Log in to your organization Dashboard and take note of your Provisioning API credentials.

2. Use those credentials to make a call to the /api/user endpoint of the Provisioning API and take note of your user ID.

3. Create a JWT assertion specifying the user ID above as the owner.

4. Get the access token using the JWT bearer flow with integration API credentials.

The correct JWT assertion should have the following structure:

{
  "https://commercelayer.io/claims": {
    "owner": {
      "type": "User",
      "id": "aqwDFvELOz"
    }
  },
  "iat": 1707238036,
  ...
}

The issued token's payload should have the following structure:

{
  "organization": {
    "id": "hjTghEJUt8",
    "slug": "your-org-slug",
    "enterprise": true,
    "region": "eu-west-1"
  },
  "application": {
    "id": "lpEsdeBsNK",
    "client_id": "cL13nT1Df7f7619d235e4d94b9ab",
    "kind": "integration",
    "public": false
  },
  "owner": {
    "id": "aqwDFvELOz",
    "type": "User"
  },
  "scope": "market:all",
  "exp": 1708098399,
  "test": true,
  "rand": 0.3594449293000671,
  "iat": 1707493599,
  "iss": "https://auth.commercelayer.io"
}