---
title: Rokt Conversions API
slug: rokt-conversions-api
docTags: 
createdAt: 2026-10-06T19:56:10.346Z
---

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](https://rokt-pixel.md). The two can run together — see **Using Alongside the Rokt Pixel** below.

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**.

Three settings are optional:

- **Custom Event Mapping** — route an additional Chord event onto a Rokt conversion type. See **Event Mapping** below.
- **Send Page View Events** — on by default, sending page views as `screen_view` conversions for retargeting audiences. Turn it off if you only want purchase, signup and subscription conversions; page views are high volume.
- **API URL** — only if Rokt has provisioned your account in a region other than the default.

# Connecting to the Rokt Events API CDP Destination

:::BlockQuote
**Warning:** Before connecting destinations in the Chord CDP, please verify with all Destination owners that all **non-Chord CDP** configured destinations are **disabled**. Running external destinations alongside configured Chord CDP destinations **can result in duplicate events downstream.**
:::

1. Log into the Chord data platform.
2. Navigate to the CDP.
3. Click the **"Add"** button next to Destinations.
4. Select **Rokt Events API** from the destination catalog.
5. Enter the destination name, your **API Key** and your **API Secret**.
6. Click **"Create"** to connect.
7. Connect it to your event sources.

# 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 `conversiontype` |
| --------------------------- | --------------------- |
| `Order Completed`           | `purchase`            |
| `Signed Up`, `User Created` | `signup`              |
| `Subscription Created`      | `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.

:::BlockQuote
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.
:::

# 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`. Chord sends your order ID there for purchases, and for conversions with no order — a signup, say — it sends the event's `messageId` instead, so every conversion carries a stable reference.

That is also what makes it safe to run this destination alongside the Rokt Pixel: both derive `confirmationref` the same way, so Rokt sees one conversion rather than two. If you push conversions into the same Rokt account from another system, `confirmationref` is the value to deduplicate against.

# Using Alongside the Rokt Pixel

Both destinations report to the same Rokt account and deduplicate on the same key, so running both is supported and is the more reliable setup:

- **This destination** survives ad blockers and browser tracking restrictions, and reports conversions that never touch a browser — a subscription renewal, or an order placed by support.
- **The&#x20;**[Rokt Pixel](https://rokt-pixel.md) establishes the browser session Rokt uses for retargeting, and captures the Rokt Click ID itself.

Use the same **Custom Event Mapping** on both. That is the one setting where a difference between them changes what Rokt records.

# 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.
