Skip to main content

Privacy Requests

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 Partnerships API exposes two privacy request surfaces. They are separate because they act on different subjects and use different downstream systems.

Use caseEndpointSubjectIdempotency
Network opt-out or network data deletionPOST /v1/partnership/network-privacy-requestsAn end user of the Rokt network, identified by email, phone, or hashed emailNo Idempotency-Key; retry only after backoff
Account-level data deletionPOST /v1/partnership/accounts/{account_id}/data-deletion-requestsA managed merchant account owned by your parent accountRequires Idempotency-Key; safe to retry with the same key
Choose the surface by subject

Use network-privacy-requests for a consumer asking to opt out of Rokt Ads or delete Rokt network data tied to their identifier. Use accounts/{account_id}/data-deletion-requests for deleting data tied to a merchant account that your platform manages.

Network privacy requestsDirect link to Network privacy requests

Submit network opt-out and network data deletion requests with your API token and your parent account ID:

curl -X POST "https://accounts.rokt.com/v1/partnership/network-privacy-requests?parent_account_id=$PARENT_ACCOUNT_ID" \
-H "Authorization: Bearer $ROKT_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"requestType": "NETWORK_OPT_OUT",
"email": "consumer@example.com"
}'

The endpoint returns 202 Accepted after Rokt submits the request downstream. It does not create a partnership operation and does not return the standard response envelope.

X-Network-Privacy-Request-Iduuid

Rokt-generated privacy request ID for support and audit correlation.

requestIduuid

Same request ID in the response body.

statusstring

Current lifecycle state. Today the submitted state is submitted.

Identifier rulesDirect link to Identifier rules

requestTypeAccepted identifiersRejected identifiersDownstream action
NETWORK_OPT_OUTExactly one of email or phonesha256Email; sending both email and phoneSubmits an OPT_OUT to Rokt's privacy/consent service
NETWORK_DATA_DELETIONExactly one of email or sha256Emailphone; sending both email and sha256EmailSends the same network suppression action Rokt uses for deleted network user data

sha256Email must be a base64-encoded SHA256 digest, not a hex string.

curl -X POST "https://accounts.rokt.com/v1/partnership/network-privacy-requests?parent_account_id=$PARENT_ACCOUNT_ID" \
-H "Authorization: Bearer $ROKT_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"requestType": "NETWORK_DATA_DELETION",
"sha256Email": "kJbnntuJYvQBhPiiHQcz6OSn0EyvzVeOBmtsG2sWkyU="
}'

If a consumer asks for both deletion and opt-out for the same email, one network deletion submission is enough. Rokt treats deleted network user data as suppressed from future ads eligibility.

Account-level data deletionDirect link to Account-level data deletion

Submit account-level deletion for a managed merchant account by passing the managed account_id, your parent account header, and an idempotency key:

curl -X POST "https://accounts.rokt.com/v1/partnership/accounts/$ACCOUNT_ID/data-deletion-requests" \
-H "Authorization: Bearer $ROKT_TOKEN" \
-H "X-Platform-Parent-Account-Id: $PARENT_ACCOUNT_ID" \
-H "Idempotency-Key: $(uuidgen)"

Rokt validates that the parent account owns the managed account before submitting the request to the Data Deletion account API. The request body is empty; the target account is taken from the path.

The response uses the standard partnership envelope and returns 202 Accepted:

{
"status": 202,
"error": null,
"message": "accepted",
"request_id": "0e3a1b9c-1234-4abc-9def-aaaabbbbcccc",
"data": {
"requestId": "dad24980-de21-43e5-839b-cf66f840d9d1",
"accountId": "<your-account-id>",
"status": "submitted",
"downstreamRequestId": "delete-account-1",
"message": "Partnership account data deletion request submitted to the Data Deletion API."
}
}

Capture both response headers:

X-Operation-Iduuid

Partnership operation ID. Poll GET /v1/partnership/operations/{operation_id} if your client loses the response or needs to confirm completion.

X-Partnership-Account-Data-Deletion-Request-Iduuid

Rokt-generated account data deletion request ID.

Dry-runDirect link to Dry-run

Add ?dry_run=true to validate auth, ownership, idempotency, and request routing without submitting to the downstream deletion service:

curl -X POST "https://accounts.rokt.com/v1/partnership/accounts/$ACCOUNT_ID/data-deletion-requests?dry_run=true" \
-H "Authorization: Bearer $ROKT_TOKEN" \
-H "X-Platform-Parent-Account-Id: $PARENT_ACCOUNT_ID" \
-H "Idempotency-Key: $(uuidgen)"

Dry-run responses include dry_run: true, omit downstreamRequestId, and do not carry X-Operation-Id because no operation is persisted. Dry-runs burn idempotency keys, so use a fresh key for the real deletion request.

Data handlingDirect link to Data handling

The Accounts API acts as an authenticated ingress layer. It does not persist raw consumer identifiers for network privacy requests, and it does not persist downstream response bodies from the privacy downstreams.

Was this article helpful?