---
title: "Customers"
canonical: "https://red-ant-documentation.refined.site/space/RDD/644087821/Customers"
format: markdown
---
> Macro (toc)

## Summary

The Customer API behaves as a basic resource, with some additional actions to support more complex functionality such as customer data anonymization.

## API Reference

[https://digital-store-api-qa.redant.cloud/v2/docs/#/Customers](https://digital-store-api-qa.redant.cloud/v2/docs/#/Customers) 

## Unique Endpoints

### Anonymize a customer

***URL:*** `POST /v2/customers/{id}/anonymize`

***Summary:*** Anonymizes a customer's information. This will convert all of the saved data relating to the string 'Anonymised'. Used primarily to comply with the GDPR [Right to Erasure](https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-erasure/).

***Reference and examples: ***[https://digital-store-api-qa.redant.cloud/v2/docs/#/Customers/post_customers__id__anonymize](https://digital-store-api-qa.redant.cloud/v2/docs/#/Customers/post_customers__id__anonymize) 

### Updating Customer Wishlists

Customer wishlists have no dedicated endpoint, but are instead accessed through the `details.wishlist` field.

The wishlist field is an array of [Product](https://redantdigital.atlassian.net/wiki/spaces/RDD/pages/717520906) objects

To update a wishlist, you can set the `details.wishlist` value in `POST`, `PUT` and `PATCH` requests. You will need to provide the full product information in the wishlist payload; RetailOS does not currently match the IDs you send, however, ensuring the `id` field matches an existing product `id` or `externalProductId` will mean end-users will be able to interact with that product within in the RetailOS app.

> ⚠️ The full wishlist must be sent in every request. There is no wishlist merge functionality.

**Example URL:** `PATCH /v2/customers/{id}`

**Example Payload: **

In this example, `id` is set to an internal RetailOS id (if you know it). But this value could also be the same as `externalProductId`

```
{
    "details": {
        "wishlist": [
            {
                "id": "24b255c3-e0e2-4b5d-b8b9-3b29a643eecf",
                "link": "",
                "name": "Small Travel Bag",
                "type": "product",
                "brand": "Rouge",
                "price": {
                    "code": "GBP",
                    "value": "300"
                },
                "images": [
                    "https://placehold.co/600x400/EEE/31343C"
                ],
                "externalProductId": "1202441"
            }
        ]
    },
    "updateSource": "RetailOS"
}
```

## Error Codes

### CUSTOMER_INVALID

**HTTP status** 422 Unprocessable Entity

**Summary** When performing CRUD or other actions on the customer resource, RetailOS may respond with an error code of `CUSTOMER_INVALID`. This is because the request payload contains references to resource entities that do not exist.

**Example**

```
{
  "error": {
    "code": "CUSTOMER_INVALID",
    "message": "Customer payload is invalid.",
    "details": {
      "errors": [
        "Key (territoryId)=(84adf7d1-8293-4302-9d21-584dd111d3e1) is not present in resource \"territories\"."
      ]
    }
  },
  "result": null
}Copy to clipboardErrorCopied
```

**Explanation**

This response indicates that the API failed to create the customer because the payload has a reference to an entity that does not exist. In this example, the payload contains a territoryId which does not exist.

**Solving the issue**

Issuing a request to GET /territories will return a list of territories with their IDs which will be valid to use as a territoryId.

### CUSTOMER_NOT_FOUND

**HTTP status** 404 Not Found

**Summary** When fetching, updating, or performing an action on a customer, RetailOS may respond with an error code of `CUSTOMER_NOT_FOUND`. This is because the requested entity could not be found.

**Example**

```
{
  "error": {
    "code": "CUSTOMER_NOT_FOUND",
    "message": "Customer not found.",
    "details": {}
  },
  "result": null
}Copy to clipboardErrorCopied
```

**Explanation**

This response indicates that the API failed to fetch the customer because the id in the URL did not match any entities under the resource.

**Solving the issue**

Issuing a request to GET /customers will return a list of customers with their IDs which will be valid to use as an id in the URL.

### VALIDATION_ERROR

**HTTP status** 400 Bad Request

**Summary** When performing CRUD or other actions on the order resource, RetailOS may respond with an error code of `VALIDATION_ERROR`. This is because the request sent to the endpoint does not meet the validation constraints required for a successful request.

**Example**

```
{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Request failed validation",
    "details": {
      "errors": [
        "\"title\" is required"
      ]
    }
  },
  "result": null
}Copy to clipboardErrorCopied
```

**Explanation**

This response indicates that the API failed validation for the request body. In the above example, the field "title" was missing.

**Solving the issue**

Please check the Customer swagger model definition [here](https://digital-store-api-qa.redant.cloud/v2/docs/#/Customers/post_customers) and ensure the request payload matches the schema definition.

## Troubleshooting

**Phone Numbers**

One common issue that may occur with international implementation is the handling of phone numbers and country codes. RetailOS can support customer phone numbers with or without a country code included. However a combination of both can result in messages failing to be sent.

If your implementation relies on international customer phone numbers, it is important to ensure your implementation of the `telephone` field is consistent - either all customers should include a country code, or none are included and this value is determined from another field.

**Date of Birth**

Customer date of birth must always be provided in the format `DD/MM/YYYY`.