# About the Real Time Personalization API

The Personalization API is a collection of endpoints that configure the personalization service, enabling it to return a personalized response based on the activity of your users. Currently, the configuration endpoints are "Treasure Data internal use only" and are used by TD Customer Success teams to set up your personalization environment. (In the future, the functionality of these APIs may be added to the TD Console user interface.) After personalization has been configured for your account, the API you call to update your customer information in TD—so the personalization service can act upon it—is simply

`{{personalizationBaseUrl}}/:database/:table`

To determine baseURLs for the personalization API in your region see [Treasure Data API baseURLs](https://api-docs.treasuredata.com/en/overview/aboutendpoints/#treasure-data-api-baseurls).

Here is a breakdown of how the Real-time Personalization API is used to configure your account and upload or update new customer data.

## Phase 1. Establish personalization routing

- **API availability:** Internal use only (handled by Treasure Data)
- **What happens:** A routing API call registers the database tables that the personalization service should monitor.
- **Example payload**



```json
"add": {
  "destinations": [
    {
      "database": "reactor",
      "table": "page_views"
    }
  ]
}
```

## Phase 2. Define and upload the personalization configuration

- **API availability:** Internal use only (handled by Treasure Data)
- **What happens:** A YAML configuration is prepared and uploaded through a provisioning API. The file defines keys, events, attributes, offers, activations, and tokens. See [configuration file section descriptions](/products/customer-data-platform/real-time/about-the-real-time-personalization-api#contentsYAMLfile) for details.
- **Token guidance:** Generate one or more authentication tokens (for example, a UUID v4 with dashes removed) and share them with Treasure Data so they can be embedded in the configuration before it is provisioned. The token shown in the Phase 3 example derives from the UUID `e65d8a9d-f209-4f02-b84c-d660efff6f27`.


## Phase 3. Send events to the personalization endpoint

- **Endpoint:** `{{personalizationBaseUrl}}/:database/:table`
- **Example request**



```bash
curl -i --header 'Content-Type: application/vnd.treasuredata.v1+json' \
--header 'wp13n-token: 1/8/e65d8a9df2094f02b84cd660efff6f27' \
--header 'Authorization: TD1 1/abcdef•••••••••••••••••••••••0123456789' \
-X POST \
-d '{"td_client_id":"202", "some_key":"some other data"}' \
--location https://eu01.p13n.in.treasuredata.com/your_database/pageviews
```

Events sent to the personalization endpoint are ingested into Plazma just like other Treasure Data events. In addition, the personalization service may return a response tailored to the profile that submitted the event.

## Phase 4. Personalization response processing

- **API availability:** Internal use only (handled by Treasure Data)
- **What happens:** After the event is committed to the monitored table, the personalization engine evaluates the configuration (for example, the offers section) and decides whether to take an action.
- **Configuration example:** The following snippet shows an offer that triggers when a profile already has preferences stored.



```yaml
offers:
- name: "preferences_known"
  set:
    - event: "pageview"
      if: PROFILE.preferences.length > 0
  data:
    td_client_id: ${PROFILE.td_client_id}
    preferences: ${PROFILE.preferences.slice(-1)[0].value}
```