Overview

Audience

This API surface is for integration partners building on top of the Rokt network. Rokt ecommerce partners integrating placements on their own checkout should use the Rokt Ecommerce developer docs instead.

The Rokt Partnerships API is a REST API for partner platforms that onboard and manage merchants on the Rokt network. Use it to register merchants, configure marketplace controls, manage placement status, and start payout onboarding without using the Rokt UI.

Preview — subject to change

This API surface is in active development. Payloads, endpoints, and behavior may shift. Rokt will notify you of any breaking change.

Key concepts

Your platform is represented as a manager account. The merchants you onboard are managed accounts. Rokt authorizes every request using your API token and the target {account_id} in the request path — the target account must be managed by your manager account, and requests for unrelated accounts are rejected server-side.

your platform (manager)
       │
       ├── merchant A  (managed account)
       ├── merchant B  (managed account)
       └── merchant C  (managed account)

These four concepts are required to integrate safely. Read these before writing any code.

Manager & managed accounts

How Rokt derives caller context from your API token and authorizes against the target account_id.

Idempotency keys

Every write call requires an Idempotency-Key. Sending the same key twice returns the cached response — safe to retry.

SET semantics

PUT replaces the full list. Controls endpoints (MCL, status) have no PATCH or merge — send the complete desired state every time. The layout-edit endpoint is the one PATCH surface in V1 — it accepts sparse updates of the five theme tokens.

Dry-run mode

dry_run=true runs the full validation and returns the would-be response without persisting state. Use it to validate payloads before going live.

What you can do

• Register a merchant — POST /v1/accounts/register/partnership. Idempotent on external_account_id (your stable identifier for the merchant; keep it non-sensitive — see Idempotency for the uniqueness scope).
• List managed accounts — GET /v1/partnership/accounts?parent_account_id=<your-parent>. A single-account detail endpoint is not yet exposed; use the per-resource reads below to inspect an individual managed account.
• Read & update marketplace controls — GET / PUT /v1/partnership/accounts/{account_id}/marketplacecontrolslists. Block verticals in your partner taxonomy; Rokt translates server-side.
• Pause or resume placements — PUT /v1/partnership/accounts/{account_id}/status cascades active/paused across every non-archived page variant.
• Edit a merchant's theme — PATCH /v1/partnership/accounts/{account_id}/layouts/{layout_id} accepts a sparse update of the five theme tokens (primaryColor, backgroundColor, textColor, borderRadius, closeButtonColor). See Pages and Layouts.
• Add a surface post-launch — POST /v1/partnership/accounts/{account_id}/pages attaches another surface (confirmation, tracking, returns) to an already-onboarded merchant without re-registering. See Pages and Layouts.
• Start Stripe Connect payout onboarding — POST /v1/partnership/accounts/{account_id}/payout-setup.
• Submit consumer network privacy requests — POST /v1/partnership/network-privacy-requests handles network opt-out and network data deletion by consumer identifier. See Privacy Requests.
• Submit managed-account data deletion — POST /v1/partnership/accounts/{account_id}/data-deletion-requests requests account-level deletion for a merchant your platform manages. See Privacy Requests.
• Poll long-running operations — every write returns X-Operation-Id. GET /v1/partnership/operations/{operation_id} recovers from network timeouts without re-issuing the write. Operation IDs are opaque and only readable by the authorized manager — polling cannot expose status for unrelated accounts.

Next steps

Authentication

Get your API token and learn the header contract.

Quickstart

Zero to registered merchant in six curl calls.