Skip to main content

​
DSAR Self-Service Portal End-to-End

Devotel Orbit accepts data-subject requests through two intake paths: your operators filing on a subject’s behalf, and a public portal the data subject files through themselves. One queue feeds both. This guide walks the portal path from link publication to fulfilment, and shows how it combines with operator filing. The DSAR reference documents the endpoint surface and the public e-mail/phone-claim state machine; this page is the runbook you operate from.
Every control here is tenant-owned: you publish the link, you run the queue, you decide and fulfil. Orbit hosts the portal, proves identity with a two-factor OTP, and tracks the statutory clocks — the legal duty to respond stays with you, the controller. Confirm your obligations with counsel.

​
1. Two intake paths, one queue

Operator-filed. Your team files a request with POST /compliance/dsar or the Create DSAR dialog in Settings → Compliance → DSAR. A request filed this way starts as verification_status: pending — no export or erasure worker touches it until an operator approves or rejects the identity review. This path currently fits: subjects you already know (a logged-in customer, a contact already in your workspace), and the rights the public form cannot carry (correct, limit-sensitive-PI, non-discrimination). Public self-service portal. The data subject files their own request through the hosted public page — no account, no API key, no session. The page verifies their identity with a two-factor email + SMS OTP before anything enters your queue, so a portal filing arrives pre-verified and the export or erasure worker starts immediately. Run both. The portal carries consumer volume to zero ops touches; operator filing covers the edge cases the portal cannot. Every request from either path lands in the same Settings → Compliance → DSAR list and the same GET /compliance/dsar response — one queue, one SLA banner, one audit chain.

​
2. Portal walkthrough

Host the portal as the “Submit a privacy request” link in your privacy policy, website footer, or in-product privacy center:
<locale> is the same locale prefix every Orbit web page carries (en, fr, de, …). The page renders a two-step identifier form behind a Cloudflare Turnstile bot check: the subject enters their email and phone (E.164), picks a request type, and the identity proof begins.

​
The sender-email prerequisite

Decide which addresses the portal’s verification codes send from before the link goes live — an unset sender leaves the portal failing closed in public. Two platform-level senders are configured once in your API environment: With no SMS sender and no platform fallback, the phone step returns 503 and the portal shows a “temporarily unavailable” message; with no email delivery key, the email step fails the same way. In production the first step also needs a Turnstile token — set DEVOTEL_TURNSTILE_SECRET_KEY on the API and NEXT_PUBLIC_DEVOTEL_TURNSTILE_SITE_KEY on the web deployment, from the Cloudflare dashboard (Turnstile → Add site). SMS verification codes ride the Devotel softswitch as platform OTPs — not tenant-billable traffic.

​
What the data subject sees

The subject completes a five-step claim; nothing is queued until both proofs are on file:
  1. Begin — email, phone (E.164), request type. An email OTP sends immediately.
  2. Verify email — a 6-digit email code (10-minute TTL, 3 attempts, 60-second resend cooldown).
  3. Send phone code — an SMS OTP to the same phone (60-second cooldown between sends).
  4. Verify phone — a 6-digit SMS code.
  5. Submit — the request enters your queue only with both proofs. The whole claim has a 30-minute end-to-end TTL.
The friendly request types the subject picks map onto the operator enum: If the identifiers match no contact in your workspace, the submit step still answers the same way — the portal never reveals whether a contact exists — and the audit row is written at platform scope so the forensic trail survives the no-match case.

​
Jurisdiction maps to the SLA clock

The subject picks the jurisdiction their request falls under, and that choice decides both the statutory clock the row carries and which request_type values the queue may hold: Getting the pairing right matters: opt_out_sale and limit_sensitive_pi have no GDPR equivalent, and the operator default jurisdiction is gdpr — set it expressly on California consumers. A portal filing of opt_out defaults jurisdiction to CCPA/CPRA precisely because the GDPR default would otherwise be invalid. A subject’s mis-selection is fixable: reclassify the jurisdiction from the queue and the SLA badge re-anchors.

​
3. What operators see after a filing

A portal filing that matches a contact lands in Settings → Compliance → DSAR alongside operator-filed requests. Because the OTP already proved identity, it arrives verification_status: verified — no approve/reject gate blocks it.
  • Status and deadline. The row carries the usual lifecycle status and a Day X of N SLA badge anchored to the jurisdiction’s window; any breach raises the workspace-level SLA banner. GET /compliance/dsar/sla gives the same picture over the API.
  • Erasure-class filings. A subject who picked “delete” appears in the Erasure requests (Art. 17) tab’s portal section, SLA badge beside it, ahead of the 7-day cooling-off default.
  • Fulfilment. An access or portability filing runs to Completed with a signed export_url; the Download decrypted action builds the plaintext export for an operator. An erasure, once executed, offers the Proof of deletion certificate and Propagate to your connected destinations.
  • Audit chain. Begin, both verifications, and submit write rows with hashed (never raw) identifiers, source IP, and user agent — the record your evidence binder pulls from when a regulator asks how identity was established.

​
4. What Orbit does not do

The portal is machinery for intake and identity proof; the legal decisions stay with you:
  • Orbit never decides validity. It never accepts or rejects a request on legal grounds. Verification pending rows wait on your approve/reject call; verified rows fulfil because you let them, not because the platform judged the claim.
  • Orbit never auto-fulfil an operator verdict. For an operator-filed request, no export is produced and nothing is erased while verification_status: pending. A portal filing skips the gate only because its OTP already proved identity.
  • Erasure honours your cooling-off posture. The 7-day default (overridable per tenant) gives you the window to reject, hold, or exempt before destruction.
  • Telling you which law applies is still your counsel’s job. Orbit anchors the SLA clock to whatever jurisdiction the subject picked and you confirmed.
  • The portal surfaces the consumer-friendly rights subset — a subject who needs an operator-only right (correct, limit-sensitive-PI, non-discrimination) files through your team.

​
5. Worked example — a GDPR access request end to end

A customer in Berlin opens your privacy policy, taps the portal link, and asks for everything you hold. The sequence:
  1. Begin. She enters her email, her phone in E.164 (+4915…), picks access, and clears the Turnstile check. The portal returns a claim id; the email OTP is already on its way.
  2. Verify email. She reads the 6-digit code (10-minute TTL, up to 3 attempts) and passes the first factor.
  3. Send phone code, verify phone. The second factor repeats over SMS — a 60-second cooldown apart between sends — and both proofs are now on file.
  4. Submit. The portal files the request. Because her email and phone match a contact in your workspace, the row queues as know under gdpr and returns a dsar_pub_… reference.
  5. In your queue. The row shows Day 1 of 30 — verification_status: verified — and the export worker already has it. Nobody on your team touches triage.
  6. Fulfil. The worker compiles the export and marks the row Completed with export_url and tables_exported. An operator delivers the download link (an operator-only plaintext copy is one Download decrypted click away).
  7. Over the SLA line. If the row is still open when the 30-day GDPR window elapses, the workspace SLA banner flags it — and had she mis-picked a jurisdiction at intake, your queue reclassification fixes the clock retroactively.
Time from subject’s first form submission to queued request: the two OTP prompt round-trips. Operator touches: zero.