Data Subject Access Requests (DSAR)

A Data Subject Access Request (also called a privacy request or consumer rights request) is the formal mechanism a person uses to exercise their rights over the personal data you hold about them — the right to access, delete, correct, port, or opt out of the sale of that data. Most privacy laws give you a hard deadline to respond (30 days under GDPR, 45 under CCPA/CPRA). Orbit gives you three intake paths and one fulfilment pipeline:

Operator-filed DSAR — your support or compliance team files a request on a customer’s behalf through the authenticated API or dashboard.
Public self-service portal — the data subject files their own request through a public, unauthenticated flow that proves their identity with a two-factor email + SMS OTP before anything is queued.
WhatsApp user data requests — when a WhatsApp user taps Request my data or Delete my data in a conversation with your business, Meta forwards the request to your WABA and Orbit enqueues it into your DSAR queue — see the WhatsApp section below.

This page describes Orbit’s platform controls. It is not legal advice. Your obligations — which laws apply, what you must disclose, and how long you have — depend on where your data subjects live and what data you process. Confirm with qualified counsel.

All endpoints below are rooted at https://api.orbit.devotel.io/api/v1/compliance.

Supported jurisdictions and deadlines

The applicable_jurisdiction on a request controls which statutory clock Orbit’s SLA tracker applies. Operators can reclassify a request after intake.

Jurisdiction	Code	Response SLA
EU / EEA GDPR	`gdpr`	30 days
California CCPA	`ccpa`	45 days
California CPRA	`cpra`	45 days
Brazil LGPD	`lgpd`	15 days
Singapore / Thailand PDPA	`pdpa`	30 days
Canada PIPEDA	`pipeda`	30 days
India DPDP	`dpdp`	30 days

Request types

request_type describes what the subject is asking for. The full CCPA/CPRA verb set is available to operators; the public portal exposes a friendlier subset that maps onto it.

Operator `request_type`	Meaning	Public portal verb
`know`	Access — disclose the data held (GDPR Art 15, CCPA §1798.110)	`access`
`delete`	Erasure (GDPR Art 17, CCPA §1798.105)	`delete`
`correct`	Rectification (GDPR Art 16, CPRA §1798.106)	—
`portability`	Machine-readable export (GDPR Art 20)	`portability`
`opt_out_sale`	Opt out of sale/share (CCPA §1798.120)	`opt_out`
`limit_sensitive_pi`	Limit use of sensitive PI (CPRA §1798.121)	—
`non_discrimination`	Non-discrimination right (CCPA §1798.125)	—

For CCPA access requests you may also attach consumer_categories — the CCPA §1798.100(b) categories the subject is asking about: identifiers, customer_records, protected_classifications, commercial, biometric, internet_activity, geolocation, sensory, professional, education, inferences, sensitive_pi. The verb set above intentionally has no Art 18 verb. GDPR Article 18 — the right to have processing of your data restricted rather than erased — is valid, for example when the subject disputes accuracy, challenges legality, or needs data kept pending a legal claim. Because restriction means “keep the data but pause processing” — it does not map to know, delete, correct, or portability, and there is no hidden request_type value for it. When an Art 18 claim arrives, file it under the nearest existing verb and annotate the legal basis in requester_statement:

correct — Art 18(1)(a) disputes accuracy; rectification is the remedy the subject usually wants anyway.
limit_sensitive_pi — the CCPA/CPRA analog: filing it with applicable_jurisdiction: "cpra" narrows processing in a lawful, tracked way until counsel resolves the claim.
Outside the DSAR pipeline — treat the claim as a freeze through your internal legal-hold process instead of queueing it here at all.

Whichever route you take, record the Art 18 basis in requester_statement so the audit chain and the GET /compliance/dsar queue explain why the request is open. A worked example — the subject disputes the accuracy of their call-activity records and asks you to stop acting on them while counsel reviews. File the accuracy half as correct (GDPR), and narrow processing in parallel as limit_sensitive_pi (the CCPA/CPRA analog) so the restriction is enforced rather than merely noted:

curl -X POST https://api.orbit.devotel.io/api/v1/compliance/dsar \
  -H "X-API-Key: dv_live_sk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "subject_email": "jordan@example.com",
    "requester_email": "jordan@example.com",
    "applicable_jurisdiction": "gdpr",
    "request_type": "correct",
    "requester_statement": "GDPR Art 18(1)(a) restriction requested: subject disputes accuracy of call activity; pause processing pending review."
  }'

curl -X POST https://api.orbit.devotel.io/api/v1/compliance/dsar \
  -H "X-API-Key: dv_live_sk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "subject_email": "jordan@example.com",
    "requester_email": "jordan@example.com",
    "applicable_jurisdiction": "cpra",
    "request_type": "limit_sensitive_pi",
    "requester_statement": "Companion restriction for GDPR Art 18 claim on this subject; narrows processing until counsel resolves."
  }'

Deciding whether an Art 18 claim is valid — and which of the four Art 18(1) conditions applies — is a legal determination that stays with your counsel. Orbit gives you the request_type verb set, the requester_statement marker, and the SLA tracker; the judgement to accept, reject, or release the restriction is yours at the tenant level.

Operator-filed requests

Create a request

POST /compliance/dsar — requires an admin or owner API key. Provide at least one subject identifier (contact_id, subject_email, or subject_phone) plus the requester_email that should receive correspondence.

curl -X POST https://api.orbit.devotel.io/api/v1/compliance/dsar \
  -H "X-API-Key: dv_live_sk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "subject_email": "jordan@example.com",
    "requester_email": "jordan@example.com",
    "applicable_jurisdiction": "gdpr",
    "request_type": "know",
    "verification_method": "email_link"
  }'

Returns 202 Accepted:

{
  "id": "dsar_8x2k…",
  "status": "received",
  "applicable_jurisdiction": "gdpr",
  "request_type": "know",
  "verification_status": "pending",
  "message": "Request received and queued for verification."
}

Field	Type	Notes
`contact_id`	string	Optional. Links the request to a known contact.
`subject_email`	email	One of email / phone / contact_id is required.
`subject_phone`	string	E.164.
`requester_email`	email	Required. Where status updates are sent.
`applicable_jurisdiction`	enum	Default `gdpr`. Must be set explicitly to `ccpa` or `cpra` when `request_type` is `opt_out_sale` or `limit_sensitive_pi` (see note below).
`request_type`	enum	Default `know`.
`consumer_categories`	string[]	CCPA categories (access only).
`verification_method`	enum	`email_link`, `email_phone`, `document`, `manual_review`.
`requester_statement`	string	Free text, ≤ 4096 chars.
`authorized_agent`	object	`{ agent_name, agent_email, permission_document_id? }` when an agent files on the subject’s behalf.

Note — applicable_jurisdiction only defaults to gdpr for rights that exist under GDPR. The opt_out_sale and limit_sensitive_pi request types are CCPA/CPRA-only and have no GDPR equivalent, so you must set applicable_jurisdiction to ccpa or cpra explicitly for them. Omitting it (or leaving the gdpr default) is rejected with 422 VALIDATION_ERROR.

Status lifecycle

A request moves through: received → processing → completed with terminal branches failed, expired, and cancelled. The verification sub-state is tracked independently: pending → verified (worker proceeds) or rejected (worker halts). GDPR/admin-filed rows default to not_required.

Verify or reject identity

Higher-assurance requests (delete, opt-out, limit-sensitive) require an operator decision before fulfilment proceeds:

curl -X POST https://api.orbit.devotel.io/api/v1/compliance/dsar/dsar_8x2k…/verification \
  -H "X-API-Key: dv_live_sk_..." \
  -H "Content-Type: application/json" \
  -d '{ "decision": "verified", "notes": "Matched gov-ID upload." }'

decision is verified or rejected; notes is optional (≤ 2048 chars). Returns the new verification_status and verified_at.

Cancel a request

POST /compliance/dsar/{id}/cancel withdraws an in-flight request (GDPR Art 7(3)). Only works while the request is received or processing; a terminal request returns 409 Conflict.

curl -X POST https://api.orbit.devotel.io/api/v1/compliance/dsar/dsar_8x2k…/cancel \
  -H "X-API-Key: dv_live_sk_..." \
  -H "Content-Type: application/json" \
  -d '{ "reason": "Duplicate of dsar_7a1f…" }'

List and read requests

GET /compliance/dsar — paginated list. Query: page (≥ 1), page_size (≤ 100, default 25), and an optional status filter.
GET /compliance/dsar/{id} — fetch one request. The response includes the signed export_url (and its export_expires_at) once an access/portability export has been produced, plus tables_exported describing the per-table row counts.

Erasure requests

GDPR Art 17 erasures are tracked as their own resource so you can audit and intervene before data is destroyed:

GET /compliance/dsar/erasure-requests — list. Query: status (pending, cancelled, executing, executed, failed) and limit (≤ 500).
POST /compliance/dsar/erasure-requests/{id}/cancel — cancel a pending erasure before it executes. Optional reason (≤ 500 chars). Returns 409 if it is already executing or done.

Proof-of-deletion certificate

Once an erasure request lands executed, you can issue a signed proof-of-deletion certificate — the receipt a data subject or supervisory authority can hold as evidence the request was fulfilled. The certificate is built deterministically from the immutable executed request row and its audit-chain anchor, self-signed with a detached HMAC-SHA256 tag. It is not persisted — it is derived on demand, so re-issuing for the same request and issued_at timestamp always produces a byte-identical, re-verifiable artifact. For the full operational sequence around this artifact — trigger and finalize, reading and verifying the digest, presenting it as Art. 17 evidence, and handling erasures that did not complete cleanly — see the Proof-of-Deletion Certificate Runbook.

Issue the certificate

GET /compliance/dsar/erasure-requests/{id}/certificate — owner or admin API key. Only executed erasures can be certified; anything earlier returns 409 Conflict.

curl -X GET https://api.orbit.devotel.io/api/v1/compliance/dsar/erasure-requests/gdpr_4e2a…/certificate \
  -H "X-API-Key: dv_live_sk_..."

{
  "certificate": {
    "certificate_version": "1.1",
    "certificate_id": "erc_8f2c1a9d3b7e5f0a4c2d1e6b",
    "issuer": "Devotel Orbit CPaaS",
    "regulation": [
      "GDPR Article 17 (Right to erasure)",
      "CCPA §1798.105 / CPRA (Right to delete)"
    ],
    "statement": "This certifies that all personal data associated with the identified data subject has been permanently erased from Devotel Orbit CPaaS production systems and propagated as a suppression to downstream destinations, in fulfilment of the data subject's right to erasure. Integrity of this certificate can be verified against the detached HMAC-SHA256 signature.",
    "organization_id": "org_4cf2…",
    "tenant": "tenant_4cf2",
    "erasure_request_id": "gdpr_4e2a…",
    "data_subject_contact_id": "cnt_9b77…",
    "requested_by_user_id": "user_31cd…",
    "requested_at": "2026-08-30T09:12:44.000Z",
    "executed_at": "2026-09-06T09:12:44.000Z",
    "issued_at": "2026-09-18T10:04:31.000Z",
    "attempt_count": 1,
    "audit_log_id": "audit_e86d…",
    "records_erased": {
      "total": 43,
      "by_resource": {
        "contacts": 1,
        "messages": 21,
        "calls": 14,
        "conversations": 7
      }
    },
    "destination_propagation": {
      "total": 2,
      "dispatched": 2,
      "failed": 0,
      "skipped": 0,
      "destinations": [
        {
          "destination": "hubspot",
          "outcome": "dispatched",
          "mode": "delete",
          "action": "delete_contact",
          "lookup_key": "jordan@example.com",
          "error_code": null,
          "propagated_at": "2026-09-06T09:13:51.000Z"
        },
        {
          "destination": "salesforce",
          "outcome": "dispatched",
          "mode": "suppress",
          "action": "suppress_record",
          "lookup_key": "jordan@example.com",
          "error_code": null,
          "propagated_at": "2026-09-06T09:13:52.000Z"
        }
      ]
    }
  },
  "signature": {
    "algorithm": "HMAC-SHA256",
    "key_id": "devotel-orbit-erasure-v1",
    "value": "uYq4w1…base64url"
  }
}

Field	Meaning
`certificate_id`	Deterministic id derived from the request id and execution timestamp — re-issuing the same executed request always yields the same id.
`erasure_request_id`	The executed erasure request this certifies.
`issued_at`	Issuance timestamp. Part of the signed body, so a re-issue at a different instant produces a new (equally verifiable) signature.
`records_erased`	Per-resource deleted-row counts copied from the audit-chain anchor, plus their confirmed total. A `null` total means every purge ran but the count could not be confirmed.
`audit_log_id`	The tamper-evident audit-chain anchor this certificate resolves back to.
`destination_propagation`	Per-destination downstream outcomes (see the propagation fold below).
`signature`	Detached tag over the canonicalised `certificate` object. `key_id` names the platform signing key generation.

Re-verify a certificate

To confirm the artifact has not been altered:

Canonicalise the certificate object with RFC 8785 (JCS) — the builder uses the same canonical form other Orbit signed artifacts use: object keys sorted ascending, no insignificant whitespace.
Compute HMAC-SHA256 with the platform signing secret over the string orbit.dsar.erasure-certificate.v1.<canonical-json>.
Base64url-encode and compare against signature.value with a timing-safe equality check (e.g. crypto.timingSafeEqual in Node).

The domain-separated context string (orbit.dsar.erasure-certificate.v1) is mixed into every tag, so a certificate signature can never collide with any other platform-signed surface reusing the same secret. A mismatched or malformed tag verifies false; it never fails open.

What the certificate is — and is not

The certificate is a tenant-issued artifact: it is the signed receipt you hand to a data subject or supervisory authority to evidence that an erasure executed. Whether that evidence discharges a legal obligation stays with your counsel, consistent with Orbit’s tenant-owned compliance posture. The platform signs integrity of the artifact; the regulatory judgement is yours.

Propagation fold

When you run downstream erasure propagation (see CDP erasure propagation), the per-destination outcomes are folded into the certificate’s destination_propagation section — total, dispatched, failed, and skipped counts plus one entry per destination. Destinations are sorted by name and deduplicated (latest outcome wins) so re-issue stays byte-stable. An empty section is signed as total: 0 — an honest, verifiable “no external destinations were notified,” not silence.

SLA dashboard

GET /compliance/dsar/sla returns a combined export + erasure SLA snapshot so you never miss a statutory deadline:

{
  "items": [
    {
      "id": "dsar_8x2k…",
      "kind": "export",
      "status": "processing",
      "days_elapsed": 22,
      "days_remaining": 8,
      "severity": "amber",
      "sla_deadline_at": "2026-07-01T00:00:00.000Z",
      "approaching": true,
      "breach": false,
      "escalation_due": false
    }
  ],
  "alerts": {
    "breached": 0,
    "approaching": 1,
    "escalation_due": 0,
    "worst_severity": "amber",
    "has_alert": true
  },
  "sla_days": 30
}

Severity tiers scale proportionally with each jurisdiction’s SLA window — the day thresholds are anchored to the GDPR 30-day case and multiplied by the slaDays / 30 ratio, so a request always turns amber and red at the same fraction of its own deadline. escalation_due flips 5 days before the statutory deadline (slaDays − 5). For GDPR (sla_days: 30): green (< 20 days elapsed), amber (20–25), red (26–30), red + breach (> 30); escalation_due at day 25. For CCPA/CPRA (sla_days: 45) the same ratios give green (< 30), amber (30–38), red (39–45), red + breach (> 45); escalation_due at day 40. Always read the tier boundaries against the sla_days returned for that request, not the fixed 20/25/30 numbers.

Public self-service portal

The public flow lets a data subject file a request without an account. Identity is proven with a two-factor OTP — an email code and an SMS code — before any request is queued. The endpoints live under /compliance/public/dsar and are unauthenticated, but are defended by Cloudflare Turnstile, per-IP and per-identifier rate limits, and a privacy-preserving response shape that never reveals whether an email/phone pair matches a real contact.

SMS verification codes are delivered through the Devotel softswitch (the platform’s sole outbound SMS path). They are platform OTPs, not tenant-billable traffic, and carry no delivery-receipt persistence.

Flow overview

Begin

POST /compliance/public/dsar/begin with email, phone (E.164), request_type (access | delete | portability | opt_out), and a Cloudflare turnstile_token (required in production). Returns an opaque claim_id, email_sent: true, and expires_in: 600. An email OTP is sent immediately.

Verify email

POST /compliance/public/dsar/verify-email with claim_id and the 6-digit code. Returns state email_verified and next step phone_send. Codes expire after 10 minutes; max 3 attempts. POST …/resend-email (with claim_id + email) issues a new code, subject to a 60-second cooldown.

Send phone code

POST /compliance/public/dsar/send-phone with claim_id and the phone that matches the one given at begin. Sends an SMS OTP (expires_in: 600). A 60-second cooldown applies between sends; a too-soon retry returns 429 with Retry-After.

Verify phone

POST /compliance/public/dsar/verify-phone with claim_id and the 6-digit code. Returns state phone_verified and next step submit.

Submit

POST /compliance/public/dsar/submit with claim_id. Persists an audit row and — only if the verified email + phone match a contact in your tenant — queues a real DSAR (pre-marked verification_status: verified, since the OTP already proved identity). Returns a reference_id (e.g. dsar_pub_…) and a queued boolean.

Configure the identity-proof senders

The two OTPs are sent from platform-level senders you configure once in your API environment. Set them before publishing the portal — an unset SMS sender with no fallback makes the phone step fail closed.

Variable	Used for	Default / fallback
`DEVOTEL_DSAR_PROOF_FROM_EMAIL`	From-address on the email OTP.	`privacy@orbit.devotel.io`. Delivery also needs `DEVOTEL_RESEND_API_KEY`.
`DEVOTEL_DSAR_PROOF_SMS_FROM`	E.164 sender on the SMS OTP.	Falls back to `DEVOTEL_PLATFORM_DEFAULT_FROM`.

If DEVOTEL_DSAR_PROOF_SMS_FROM and DEVOTEL_PLATFORM_DEFAULT_FROM are both unset, the send-phone step fails closed with a 503 — the portal returns a “temporarily unavailable” message and the failure is emitted under the dsar.proof.sms_send_failed metric so it surfaces in your dashboards rather than silently skipping the second factor. Likewise, the email step returns 503 when DEVOTEL_RESEND_API_KEY is unset. Configure both senders before you link the portal publicly.

Abuse defenses

Control	Limit
Cloudflare Turnstile	Required on `begin` in production (fail-closed).
Per-IP `begin`	3 per hour.
Per-email cooldown	1 per 60 s.
Per-phone SMS cooldown	1 per 60 s.
Fastify per-IP gate	30 requests/min per IP, applied independently per endpoint.
OTP TTL / attempts	10 minutes, max 3 attempts per code.
Claim TTL	30 minutes end-to-end.

The response shape is identical whether or not the identifiers match a real contact — the portal never confirms or denies that someone is in your database. When Redis is unavailable the rate-limit gates fail open to preserve availability.

Enabling Turnstile protection

The Turnstile gate is configured with two environment variables.

Variable	When	Description
`DEVOTEL_TURNSTILE_SECRET_KEY`	API (server)	Cloudflare Turnstile secret. The `begin` endpoint verifies the submitted `turnstile_token` against Cloudflare when this is set.
`NEXT_PUBLIC_DEVOTEL_TURNSTILE_SITE_KEY`	Web (client)	Public Turnstile site key the portal renders the widget with.

The gate is fail-open when DEVOTEL_TURNSTILE_SECRET_KEY is unset: begin accepts requests without a token and logs a single warning. Set the secret in production, or the portal is unprotected by Turnstile even though every other abuse defense above still applies. Generate both keys in the Cloudflare dashboard (Turnstile → Add site) and set them on the API and web deployments respectively.

Hosting the portal link

Publish the public portal under your privacy policy as the “Submit a privacy request” link. Because the flow self-verifies via OTP, requests that arrive through it are already identity-proven — they land in your operator queue ready to fulfil, and appear in GET /compliance/dsar alongside operator-filed requests.

Inbound DSAR triggers from WhatsApp (Meta user data requests)

Beyond the two paths you file through directly, a third intake path requires nothing from you to switch on. WhatsApp gives every user a Request my data and a Delete my data action inside a conversation with a business. When one of your WhatsApp contacts taps either (the GDPR Article 15 and 17 rights, exercised against you as the data controller), Meta forwards the request to the webhook your WhatsApp Business Account already delivers to Orbit, and Orbit routes it into your DSAR queue so the usual fulfilment pipeline can run.

How Orbit routes these requests

Orbit identifies your organisation by the WABA the webhook arrived on — shared WABAs resolve to every organisation attached to them.
If the user’s phone number matches a contact in your tenant, that contact’s dsar_status is tagged and the Meta payload is attached to the contact record.
A dsar_requests row is queued in status received, with requester_statement noting the request came in from WhatsApp along with Meta’s original request_id where present.
From there nothing is special-cased: scheduler-dsar-export and scheduler-gdpr-erasure pick the row up exactly as they do operator-filed and portal requests, including downstream erasure propagation and the proof-of-deletion certificate.

How Meta verbs map to `request_type`

Meta signal	Orbit `request_type`	Right exercised
`data_request`	`portability`	GDPR Art 20 — machine-readable export
`data_delete`	`delete`	GDPR Art 17 — erasure

data_request asks you to hand over what you hold, so it queues as an export; data_delete asks you to erase, so it queues as an erasure.

What you see in your DSAR queue

A WhatsApp-originated row appears in GET /compliance/dsar and the dashboard queue alongside operator-filed and portal requests, with:

request_type set by the mapping above.
subject_phone set to the user’s WhatsApp number in E.164 — the one identifier Meta supplies.
requester_statement describing the WhatsApp origin, including the WABA the request arrived on and Meta’s request_id.
verification_status: verified. Because Meta signs these attestations on your behalf upstream, Orbit does not gate them behind a second identity check; it is a meta_dpo_webhook-originated row, and the queue groups it as such. Art 12(6) still leaves it to you to decide when the identity is sufficient — record your basis if you accept the Meta attestation as verification.

The contact-side view complements this: the affected contact carries dsar_status of export_requested or deletion_requested, plus the Meta metadata the webhook delivered — request_id, expires_at, and signed_request_present (whether Meta signed the request blob).

Duplicate deliveries enqueue once

Meta may deliver the same request_id more than once. Before Orbit inserts a queue row, it checks whether a row for that organisation already carries the same request_id in requester_statement, and skips the insert on a match — a redelivered webhook never piles a second row into your queue. The original row keeps the first requested_at, and with it the SLA clock.

You still own fulfilment

Orbit routes the upstream trigger into your queue; everything from verification onward is your call, exactly as with the other intake paths:

The Article 12 clock starts when Meta delivers the request to Orbit, not when your team first reviews the queue row. Meta also sends its own expires_at in the payload, visible on the contact — budget your review time inside both.
Verify that the matched contact really is the data subject before you export or erase, and reject the request through the normal verification flow (POST /compliance/dsar/{id}/verification) if it is not.
The 30-day GDPR window applies; the SLA dashboard escalation tiers track these rows like any other gdpr request.

Every intake path feeds the same queue and the same fulfilment pipeline: the operator-filed requests workflow above, the self-service portal guide, and the GDPR posture guide all describe the controls these rows flow through once queued.

CDP erasure propagation — the downstream destination fan-out whose per-destination rows fold into the certificate.
Self-service DSAR portal — the public, two-factor intake flow for operator-free filing.
Inbound DSAR triggers from WhatsApp — the Meta-forwarded third intake path.
Assembling a GDPR Posture End to End — where DSAR intake sits in the full sequence.
Consent Management — record and look up the consent state a DSAR may ask you to honour.
Opt-Out & Suppression Lists — how delete / opt_out outcomes flow into suppression.
Call Recording Consent — handling recordings referenced by an access request.
Upload and manage compliance documents — the document library that holds your privacy register artifacts and signed agreements.
API Reference → Compliance — full request/response schemas (regenerated from the live API).

​Data Subject Access Requests (DSAR)

​Supported jurisdictions and deadlines

​Request types

​Restriction of processing (GDPR Art 18)

​Operator-filed requests

​Create a request

​Status lifecycle

​Verify or reject identity

​Cancel a request

​List and read requests

​Erasure requests

​Proof-of-deletion certificate

​Issue the certificate

​Re-verify a certificate

​What the certificate is — and is not

​Propagation fold

​SLA dashboard

​Public self-service portal

​Flow overview

​Configure the identity-proof senders

​Abuse defenses

​Enabling Turnstile protection

​Hosting the portal link

​Inbound DSAR triggers from WhatsApp (Meta user data requests)

​How Orbit routes these requests

​How Meta verbs map to request_type

​What you see in your DSAR queue

​Duplicate deliveries enqueue once

​You still own fulfilment

​Related references

Data Subject Access Requests (DSAR)

Supported jurisdictions and deadlines

Request types

Restriction of processing (GDPR Art 18)

Operator-filed requests

Create a request

Status lifecycle

Verify or reject identity

Cancel a request

List and read requests

Erasure requests

Proof-of-deletion certificate

Issue the certificate

Re-verify a certificate

What the certificate is — and is not

Propagation fold

SLA dashboard

Public self-service portal

Flow overview

Configure the identity-proof senders

Abuse defenses

Enabling Turnstile protection

Hosting the portal link

Inbound DSAR triggers from WhatsApp (Meta user data requests)

How Orbit routes these requests

How Meta verbs map to `request_type`

What you see in your DSAR queue

Duplicate deliveries enqueue once

You still own fulfilment

Related references