> For the complete documentation index, see [llms.txt](https://docs.chord.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.chord.co/activate/event-streaming/destinations/advertising/rokt/rokt-events-api.md).

# Rokt Events API

Rokt is an advertising and offer-placement network. The Rokt Events API destination sends conversions and page views to Rokt from Chord's servers, so Rokt can attribute a purchase or signup back to the campaign that drove it and build retargeting audiences.

Because it runs server-side it is unaffected by ad blockers and browser tracking restrictions. For the browser equivalent, see [Rokt Pixel](/activate/event-streaming/destinations/advertising/rokt/rokt-pixel.md). The two can run together. See [Rokt](/activate/event-streaming/destinations/advertising/rokt.md) for how they work together.

This replaces Rokt's deprecated Conversions API.

## Getting started

You need an **API key and API secret** for Rokt's Events API. Rokt provisions these — contact your Rokt account manager if you do not have them. They are a different credential from the API key used by the Rokt Pixel destination, and the two are not interchangeable.

Note that Rokt's self-serve integration wizard only offers the browser snippet. The Events API is not self-serve, so the credentials come from your account manager rather than from **my.rokt.com**.

## Settings

* **Destination Name** (required): a name to tell this destination apart.
* **API Key** (required) and **API Secret** (required): your Rokt Events API credentials. Rokt provisions them. They are different from the credentials the Rokt Pixel destination uses.
* **Custom Event Mapping** (optional): routes an additional Chord event onto a Rokt conversion type (`purchase`, `signup`, `subscription` or `screen_view`). See [Event mapping](#event-mapping). Use the same mapping on the Rokt Pixel destination.
* **Send Page View Events** (optional): send page views to Rokt as `screen_view` conversions for retargeting audiences. On by default. Turn it off if you only want purchase, signup and subscription conversions, because page views are high volume.
* **API URL** (optional): an endpoint override. Set it only if Rokt provisioned your account in a region other than the default.
* **Consent Requirements** (optional): the consent categories a visitor must accept before Chord sends data to this destination. See [Consent](/activate/event-streaming/consent.md).

## Connect

Add **Rokt Events API** from the destination catalog, using the settings above. See [Connect a destination](/activate/event-streaming/connect-a-destination.md) for the full steps.

## Event mapping

Rokt records a conversion as a single event named `conversion`, with a `conversiontype` attribute saying what kind it was. Chord maps events like this:

| Chord event                                                                                                            | Rokt event     | Notes |
| ---------------------------------------------------------------------------------------------------------------------- | -------------- | ----- |
| [`Order Completed`](/collect-data/tracking-plan/order-completed.md)                                                    | `purchase`     |       |
| [`Signed Up`](/collect-data/tracking-plan/signed-up.md), [`User Created`](/collect-data/tracking-plan/user-created.md) | `signup`       |       |
| [`Subscription Created`](/collect-data/tracking-plan/subscription-created.md)                                          | `subscription` |       |
| Page and screen views                                                                                                  | `screen_view`  |       |

**Anything not in that table is skipped**, and the skip is logged so you can see it in Live Events. Use **Custom Event Mapping** to route an additional event onto one of the four conversion types — for example `Trial Started` → `subscription`. A mapping naming anything outside those four values is ignored.

If you also run the Rokt Pixel destination, **configure the same mapping on both**. Otherwise the same conversion is classified one way from the server and another way in the browser.

{% hint style="info" %}
Rokt's public documentation describes `conversiontype` as free text and lists further example values elsewhere, without publishing a definitive set. Chord sends only the four above until Rokt confirms which values their reporting acts on. If you need another one, ask your Rokt account manager to confirm it and we will add it to both destinations together.
{% endhint %}

## Identity and user attributes

Rokt matches a conversion to a campaign on the shopper's email address, so a conversion without one will not attribute. Chord sends the address both in plain text and as a SHA-256 hash, which is what Rokt's identity model expects, along with your internal user ID.

Alongside the email, Chord sends Rokt's recommended user attributes when your events carry them — first name, last name, mobile number, city, state and postal code — each with its SHA-256 counterpart where Rokt defines one. Rokt's own canonicalization rules are applied before hashing: lowercase and trim for email and names, digits only for the mobile number.

## The Rokt Click ID

Rokt appends a Click ID (`rtid`) to the landing page URL when a shopper arrives from a Rokt placement. Chord's JS SDK captures it and stores it for 30 days, so a purchase that happens several pages later still carries it, and passes it back to Rokt on the conversion.

You do not need to configure this — it works as long as Chord's SDK is installed on the storefront. It matters most for conversions that happen on a later page view than the click, which is nearly all of them.

## Deduplication

Rokt deduplicates on `confirmationref`, and both Rokt destinations send the same value. See [How they deduplicate](/activate/event-streaming/destinations/advertising/rokt.md#how-they-deduplicate).

## Errors and retries

Rokt acknowledges an accepted batch with `202`. Rate limits (`429`) and Rokt-side errors (`5xx`) are retried with backoff. A rejected payload or bad credentials (`400`, `401`, `403`) is not retried, because no retry would fix it — check the error in Live Events.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.chord.co/activate/event-streaming/destinations/advertising/rokt/rokt-events-api.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.