Quick answer: A Data Subject Access Request (DSAR) is the formal mechanism a person uses to exercise their rights over personal data — access, deletion, correction, portability, or opting out of sale. Orbit ships a public, self-service DSAR intake portal alongside the operator-filed API: the data subject files their own request through a five-step flow that proves identity with a two-factor email + SMS one-time passcode before anything is queued, and the landing zone is your operator queue rather than a shared mailbox. Identity-proofed intake is the difference between a defensible statutory clock and an inbox full of unread privacy requests.
The full reference is the DSAR docs page; this post walks the portal end to end so you know what to show a buyer when procurement asks how you receive privacy requests.
What a DSAR is, and which jurisdictions it covers
A DSAR starts a statutory clock. The moment one lands, you have a fixed number of days to respond — and the failure mode for most companies is procedural, not technical: the request came in through a channel nobody triages, the identity check is ad hoc, and the deadline is discovered after it has passed. The governing laws differ in their verbs and their clocks, but they share the same intake problem.
Orbit's SLA tracker applies the statutory deadline based on the applicable_jurisdiction set on each request:
| Jurisdiction | Code | Response deadline |
|---|---|---|
| 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 map the same way — the operator-facing verb set (know, delete, correct, portability, opt_out_sale, limit_sensitive_pi) covers the full GDPR and CCPA/CPRA surface, while the public portal exposes a friendlier subset (access, delete, portability, opt_out) that maps onto the same underlying rights. A procurement reviewer asking "which laws does the intake flow cover?" gets this table, verbatim, in your answer.
Why self-service beats the shared mailbox
DSAR intake by email fails in predictable ways, and none of them look like failures until the deadline passes.
A shared privacy@ mailbox has no SLA tracking. The countdown to amber and red exists in nobody's head, and the breach email arrives weeks after the actual breach. There is no verification audit: an mailbox intake produces an email thread, which is not evidence of identity-proofing — it is an attacker-visible endpoint, and a malicious deletion request sent to one address with a spoofed From header can be enacted without anyone noticing there was no check. The intake path also blocks on your team's availability; a subject who files at 02:00 UTC waits for your timezone. And the mailbox answer does not survive procurement: "we receive privacy requests by email" is the kind of sentence that ends a security review.
Self-service flips each of those. The SLA clock starts at submission, not at the moment a human reads an email. Identity is proven by a two-factor OTP with an audit row, and the verification record travels with the request. The portal is always open, so the queue is a workflow instead of an inbox. And when procurement asks where requests land, the answer is a route — orbit.devotel.io/dsar — not a mailbox name.
The two intake paths Orbit ships
One fulfilment pipeline, two front doors.
Operator-filed. Support or compliance staff file a request on a customer's behalf through the authenticated API — a POST /compliance/dsar call that requires an admin API key and at least one subject identifier. Use it for assisted intake: a phone call from a subject, a regional partner filing on behalf, a contact lookup where you already hold the identity.
Public self-service portal. The data subject files their own request through an unauthenticated flow whose only job is proving identity before anything else happens. Requests that arrive this way are pre-marked verification_status: verified by the OTP, so they enter the operator queue ready to fulfil rather than pending a manual check.
Both land in the same queue and the same SLA tracker; the SLA dashboard reads them side by side. The portal URL sits under your privacy policy as the "Submit a privacy request" link, so a subject who reads your policy has exactly one obvious way to exercise their rights.
Walking the public portal end to end
The portal lives at orbit.devotel.io/dsar. Here is the exact sequence a data subject walks — five steps, and a request does not queue until both identity factors clear.
- Identify. The subject enters their email, phone number, and the request verb (
access,delete,portability, oropt_out), with a Cloudflare Turnstile token attached. The service responds with an opaqueclaim_idand an expiry; the email OTP is sent at this point. - Verify email. The subject enters the 6-digit code mailed to them. Codes expire after ten minutes, and resending is throttled to one per sixty seconds.
- Send phone code. An SMS OTP fires to the phone number given in step one, with the same sixty-second cooldown between sends.
- Verify phone. The subject enters the SMS code. The claim now carries both factors verified.
- Submit. The portal posts the claim. Only if the verified email + phone pair actually matches a contact in your tenant does a real DSAR queue — a privacy-preserving design that never reveals, to a stranger, whether the identifiers exist in your database. The subject gets a reference ID regardless; either way, the response looks the same.
The whole flow has a hard end-to-end TTL of thirty minutes, so a half-attempted claim cannot be resurrected later. The SMS side rides the platform's own OTP path, not tenant-billable traffic — the second factor is infrastructure, not a cost your tenant absorbs.
Two operational notes before you publish the link. First, the two OTP senders (the From-address on the email and the sender on the SMS) are platform-level environment variables; if the SMS side is unconfigured, the phone step fails closed with a 503 and a metric that surfaces in your dashboards, rather than silently skipping the second factor. Second, Turnstile is fail-open when its secret is unset — enable it in production, or step one accepts tokenless requests. Both configuration hooks are documented on the DSAR docs page; set them before the link goes live.
Abuse defenses on an open endpoint
An unauthenticated endpoint can't just be a form — it has to survive being public. The portal layers the defenses:
| Control | Limit |
|---|---|
| Cloudflare Turnstile | Required on begin in production (fail-closed) |
| Per-IP begin attempts | 3 per hour |
| Per-email cooldown | 1 per 60 seconds |
| Per-phone SMS cooldown | 1 per 60 seconds |
| Per-IP request gate | 30 requests per minute, per endpoint |
| OTP TTL / attempts | 10 minutes per code, max 3 attempts |
| Claim TTL | 30 minutes end to end |
The response shape is identical whether or not the identifiers match a real contact, so probing the portal yields no enumeration signal. When the rate-limit store is unavailable the gates fail open — the portal prefers availability over false rejection, which is the right trade for a rights-exercise endpoint someone is entitled to reach.
How the portal fits a GDPR evidence binder
The intake problem and the evidence problem are the same problem. "Where do DSARs land?" is the intake question; "show me your DSAR history" is the evidence question. The portal answers the first; the evidence binder answers the second, exporting your DSAR history, breach counts, consent records, and retention posture as a signed, checksummed pack mapped to the GDPR control structure.
Filed-through-the-portal requests are identity-proofed by construction, which is what makes the binder's DSAR history defensible rather than aspirational. We covered the binder workflow in Inside the Evidence Binder — this post is the intake half of that pair.
The compliance-sensitive disclaimer
Everything above is a platform control, not legal advice. Orbit receives, verifies, tracks, and fulfils privacy requests; it does not decide which laws apply to you, what you must disclose, or whether your response is compliant. Those are your obligations, with your counsel. The tenant owns the control surface — the portal is instrumentation, and instrumentation is what you can put in front of a regulator when the question arrives.
Frequently asked questions
Which jurisdictions does the portal cover?
GDPR, CCPA, CPRA, LGPD, PDPA, PIPEDA, and DPDP — the full list, with their statutory deadlines, is enumerated on the DSAR docs page, and the same table drives the SLA tracker each request lands in.
Does the public portal reveal whether someone is in our database?
No. The response shape is identical whether or not the verified email and phone match a contact — the portal cannot be used to enumerate your customers, and a stranger learns nothing from probing it.
Which request types can a subject file through the portal?
Access, delete, portability, and opt-out of sale. The operator verb set additionally includes correct, limit-sensitive, and non-discrimination requests, which are filed through the authenticated operator API.
What does the OTP verification cost our tenant?
Nothing. The SMS and email OTPs are platform-level identity-proof traffic, not tenant-billable sends — the second factor is infrastructure you configure once, not a per-request cost.
What happens if a portal DSAR's identifiers don't match a contact?
The claim is audited and the subject gets a reference ID, but no request queues into your operator workflow — the queue only fills with requests whose verified email and phone pair actually matches a contact in your tenant.
Is self-service intake a replacement for legal review?
No. The portal proves identity and starts the statutory clock; it is not a legal determination of what you owe. Your obligations are still yours to determine with counsel, and Orbit's role is to make sure the request is received, verified, and visible before the deadline becomes a problem.