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 two 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.

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.

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.

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.

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.
API Reference → Compliance — full request/response schemas (regenerated from the live API).

Getting Started

Channels

AI Agents

Flows

Numbers & Verify

Concepts

Billing

Webhooks

Compliance

Legal

Changelog

Data Subject Access Requests (DSAR)

Data Subject Access Requests (DSAR)

Supported jurisdictions and deadlines

Request types

Operator-filed requests

Create a request

Status lifecycle

Verify or reject identity

Cancel a request

List and read requests

Erasure requests

SLA dashboard

Public self-service portal

Flow overview

Configure the identity-proof senders

Abuse defenses

Enabling Turnstile protection

Hosting the portal link

​Data Subject Access Requests (DSAR)

​Supported jurisdictions and deadlines

​Request types

​Operator-filed requests

​Create a request

​Status lifecycle

​Verify or reject identity

​Cancel a request

​List and read requests

​Erasure requests

​SLA dashboard

​Public self-service portal

​Flow overview

​Configure the identity-proof senders

​Abuse defenses

​Enabling Turnstile protection

​Hosting the portal link

​Related references

Data Subject Access Requests (DSAR)

Supported jurisdictions and deadlines

Request types

Operator-filed requests

Create a request

Status lifecycle

Verify or reject identity

Cancel a request

List and read requests

Erasure requests

SLA dashboard

Public self-service portal

Flow overview

Configure the identity-proof senders

Abuse defenses

Enabling Turnstile protection

Hosting the portal link

Related references