Skip to main content

Compliance integration recipes

Your compliance evidence lives in three systems: Orbit, your CRM (the source of consent), and your data warehouse (retention). Orbit exposes the controls you need to keep them in agreement as ordinary REST endpoints under https://api.orbit.devotel.io/api/v1, authenticated with Authorization: Bearer <API_KEY> (create keys under Settings → API keys; see Authentication). The public DSAR intake endpoints are the one unauthenticated surface, by design, because the requester is your customer, not your backend. Orbit does not mandate how you run your compliance program. Every control below is tenant-owned: you decide which ones to wire up and which stay manual. These recipes show the four integrations teams build most often.

Use case A: DSAR intake pipeline

Route your privacy webform through the public DSAR flow so access and erasure requests land in the same queue your team already works, with the identity proofing handled for you. The flow is six calls: begin, verify-email, submit on the requester side; then list, watch SLA, and issue the certificate on your side. Requester side (unauthenticated):
Your side (authenticated, owner or admin):
Handling inbound erasure end to end, including verification and regulator presentation of the certificate, is covered in the Proof-of-Deletion Certificate Runbook. The DSAR reference covers the console flow. Verify it works: the begin call returns HTTP 202 with a claim_id, and GET /api/v1/compliance/dsar lists the submitted request. Common errors (see also the compliance gate error codes FAQ): Your warehouse should hold the same suppression and consent truth Orbit enforces at send time. Three exports cover it: the suppression ledger (proof of who was STOP-suppressed and when), the consent proof-of-record, and the tamper-evident audit trail. Run all three on a cron and you can re-answer an audit from your own storage. For continuous delivery instead of cron pulls, register a SIEM sink (Splunk HEC, Datadog, S3, or an HTTPS log drain). A new sink, or one whose endpoint changed, starts pending and must be activated:
The cron exports:
Reference pages: SIEM sinks, audit export, suppression ledger export, and bulk opt-out import for the write path your CRM sync feeds. Verify it works: GET /api/v1/compliance/siem-sinks shows your sink with state: "active", and a day-old cron run leaves one CSV per export in your bucket. Common errors:

Use case C: 10DLC lifecycle automation

Registration, rejection, and re-vet are all API-callable, so the whole lifecycle fits in a loop: create the brand, create the campaign under it, poll status until a terminal verdict (APPROVED or FAILED), and on failure decode the rejection into a fix card before resubmitting or re-vetting.
On FAILED, decode the raw TCR or carrier code into a fix card. The response’s resubmit_allowed tells you whether to amend and resubmit the same record or start a fresh registration:
Reference pages: 10DLC registration, rejections and re-vet, brand and campaign profiles. Verify it works: GET /api/v1/compliance/10dlc/status reports your brand and campaign with status: "APPROVED" and an overall readiness verdict of ready. Common errors:

Use case D: pre-send posture check with quiet-hours preview

Before your send path hands a message to Orbit, ask whether the send would pass the quiet-hours gate right now for that recipient and channel. The preview is read-only; it never sends. On a blocked result, next_allowed_at is the DST-safe ISO timestamp when the gate next opens, so your scheduler can queue until then instead of dropping the send.
If your CRM already stores the recipient’s timezone, pass timezone_override=America/New_York to skip area-code resolution. See quiet hours FAQ for the per-channel windows. Verify it works: call the preview once for a recipient inside their window and once outside it; allowed_now flips and the blocked call carries next_allowed_at. Common errors:

Sample code: one Node script that wires all four

The skeleton below runs every recipe against a live org using only Node 18+ built-ins. Store it as index.js and run ORBIT_API_KEY=dv_live_... node index.js. The DSAR half pauses for the emailed code, because a human holds it; everything else runs unattended, exactly as your cron would.
Each function mirrors one section above, so you can lift them into your own service one at a time. Keep credentials in your secret manager and pass credential_ref values to the SIEM sink, never raw secrets.

Where to go next