Handle privacy requests

A newsroom privacy request records an email address's request to export, correct, delete, or discuss contact data. It starts unconfirmed. Confirmation creates pending work for matching CRM contacts in the newsroom's account; it does not perform the requested export, correction, or deletion.

Use Subscriptions and preferences when someone only wants to stop receiving updates. Unsubscribing, deleting a CRM contact, and submitting a privacy request are different workflows.

Keep the integration boundary explicitCopy Anchor Link

These endpoints require an integration API key. Personal API tokens are unsupported, regardless of their scopes. Arrange the key and newsroom access using Authentication, then load it into PREZLY_API_TOKEN on your server.

For a custom public form, use a dedicated server handler. Fix the destination newsroom, validate the request type and fields, limit abuse, and keep the key private. Return only the form acknowledgement your client needs. The response includes an email address and a request UUID used for confirmation; keep those in your server-side workflow rather than exposing them as a general status or contact-lookup service.

Choose the request typeCopy Anchor Link

Every request requires a valid email and one of these type values:

Each message field is limited to 3,000 characters and trimmed. For correction requests, use the two fields to describe the existing issue and the desired correction.

The API accepts an optional locale; omitting it selects the newsroom's default culture. For a public form, allow only locales you intend to support. The API captures the IP address and user agent it receives; browser-supplied JSON cannot override those values. A server proxy's metadata is not automatically the visitor's metadata.

Record an unconfirmed requestCopy Anchor Link

Save this as privacy-request.json, replacing the illustrative address and messages with the requester's actual submission:

{
  "email": "reader@example.test",
  "type": "correct",
  "locale": "en",
  "message": "My organization is listed incorrectly.",
  "extra_message": "Please change my organization to Acme."
}

Replace YOUR_NEWSROOM_UUID:

curl --fail-with-body --silent --show-error --request POST 'https://api.prezly.com/v2/newsrooms/YOUR_NEWSROOM_UUID/privacy-requests' \
  --header "Authorization: Bearer $PREZLY_API_TOKEN" \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json' \
  --data-binary @privacy-request.json

The response is 200 OK, not 201:

{
  "privacy_request": {
    "id": "22222222-2222-4222-8222-222222222222",
    "status": "unconfirmed",
    "email": "reader@example.test"
  }
}

Store that UUID with the newsroom, submitted email, and your own verification state. The response does not contain the original messages or a confirmation URL. Creation is not an upsert; repeated requests create separate records. Retain the first response in your server workflow and avoid blind retries after an unknown outcome. These two public endpoints provide no list or status-read operation to reconcile a lost creation response.

This API call does not send a confirmation email. The Prezly-hosted form has a separate email step; creating the API record alone does not reproduce it. A custom integration must supply a reviewed identity-verification flow before confirmation. Do not tell the visitor to check their inbox unless your integration actually arranged that message. Do not automatically call confirm immediately after create.

Create privacy request →

Confirm only after verifying the requesterCopy Anchor Link

Bind your verification result to the stored request UUID, newsroom, and submitted email. Do not accept an arbitrary UUID from a public client as proof that the email owner approved the request. Confirmation itself does not validate an email code or ownership challenge.

After your verification step succeeds, replace YOUR_PRIVACY_REQUEST_ID with the stored UUID:

curl --fail-with-body --silent --show-error --request POST 'https://api.prezly.com/v2/newsrooms/YOUR_NEWSROOM_UUID/privacy-requests/YOUR_PRIVACY_REQUEST_ID/confirm' \
  --header "Authorization: Bearer $PREZLY_API_TOKEN" \
  --header 'Accept: application/json'

The response is 200 OK with privacy_request, containing the same id and email with status: "confirmed". The UUID must belong to this newsroom; the same UUID under another newsroom is not found.

Confirmation finds non-deleted CRM contacts with that email across the newsroom's account, including person and organization contacts. For each matching contact it creates a pending contact-data request and a pinned activity, then triggers account notifications. Confirmed status does not establish that matching contacts existed or that any data was returned, corrected, or removed.

Repeating confirmation for an already confirmed request returns its current state without creating the pending work again. After a lost confirmation response, repeat only the same stored request for which verification already succeeded; do not create and confirm a replacement as a retry strategy. See Handling errors for HTTP failures.

Confirm privacy request →

Hand the request over for completionCopy Anchor Link

Tell the visitor that their verified request was received, then follow the account team's process to handle it. The response model has only unconfirmed and confirmed; neither is a fulfillment status. These endpoints do not return a downloadable data export or a completion callback. Keep your own workflow state for review and completion, and avoid logging full messages, request UUIDs, or email addresses unnecessarily.