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. The two can run together — see Using Alongside the Rokt Pixel below.

This replaces Rokt's deprecated Conversions API.

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:

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

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.

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.

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.

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.

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:

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

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.