Skip to main content

​
Per-Domain Data Retention Policy

The data-retention policy decides how long three classes of records stay intact in your workspace before scheduled sweeps redact or delete them. It is three independent domains behind one endpoint pair — message-body redaction, closed-conversation hard-delete, and audit-log purge — each with its own window and its own minimum and maximum allowed values. All three domains are disabled by default: a workspace that never touches this surface has no automatic retention behavior.
This page describes Orbit’s platform controls. It is not legal advice. How long you may or must keep messages, conversations, and audit evidence depends on your regulators, your contracts, and your counsel’s reading of them. Confirm the specifics with qualified counsel.

​
The three domains

Each domain answers one storage-limitation question, and you can enable any combination of them.

​
Message-body redaction (messages)

After the number of days you configure, a scheduled sweep replaces the message body and the recipient/sender identifiers with a redacted marker. Billing-grade metadata — status, segment count, price, carrier error — and the delivery-receipt and audit trail survive intact, so finance and dispute lookback still work on redacted rows. Set the window to 0 to disable the sweep; any enabled value must sit within the allowed bounds.
  • Allowed window: 7 to 3650 days (or 0 to disable).

​
Closed-conversation hard-delete (conversations)

When enabled, a scheduled sweep hard-deletes a conversation row once it has been closed longer than your window. The message rows attached to the conversation are not deleted with it, so billing and audit metadata survive the purge. Only closed conversations are eligible; an open thread is never swept.
  • Allowed window: 30 to 3650 days. The 30-day floor prevents a purge of a conversation that closed only hours ago.
  • If you enable this domain without a window, the platform default of 180 days applies.

​
Audit-log purge (audit_logs)

When enabled, a scheduled sweep hard-deletes audit log entries older than your window. Audit logs are the evidence trail for every configuration change in your workspace, so this domain carries a regulatory floor.
  • Allowed window: 365 to 3650 days. The 365-day floor protects the SOC 2 examination window — you can never purge audit evidence younger than one year.
  • If you enable this domain without a window, the platform default of 2190 days (six years) applies, targeting HIPAA’s retention expectation.
DSAR erasure is separate from this age-based policy. A data-subject request scoped to a contact runs its own workflow independently of these org-wide windows — see Data Subject Requests.

​
Read the resolved policy

The response always returns the resolved value for every domain, plus a bounds object carrying the allowed min/max window for each — the same values the dashboard uses to clamp inputs. Read is any authenticated role; a fresh workspace returns the defaults above with all three domains disabled.

​
Write the policy

Writes require an owner or admin API key or dashboard role — retention is a regulatory control, so the gate mirrors the rest of the compliance write surface. Any other role receives 403. The write is merge-on-write: each domain block is optional, and a block you omit keeps its stored value. Send only the domains you intend to change.
Rules to build against:
  • Provide at least one domain — an empty body returns 422 VALIDATION_ERROR.
  • In-range values are validated strictly. A redact_body_after_days enabled value outside the bounds, or a window outside its min/max, returns 422 with a per-field error.
  • Resolution is permissive on enable-without-window. For conversations and audit_logs, sending enabled: true without a window resolves to the platform default (180 and 2190 days respectively); the resolved values are what the sweeps use, and the response of a write is the same resolved view as GET.
  • Every change is recorded. Each write lands in your audit log with the domains changed and the actor, preserving the governance trail for the policy itself.

​
Execution model: sweeps, not immediate deletion

The endpoint records policy only. Writing a 90-day window does not redact anything at the moment you save it — enforcement runs in scheduled background sweeps that apply your resolved policy on their own cadence. Plan your runbook accordingly:
  • A record older than its window becomes eligible for the sweep, and is redacted or deleted on the next sweep run — not at the instant it crosses the window.
  • Tightening a window (for example, 365 days to 90 days) queues the newly over-window records for the next sweep. It is not a synchronous purge.
  • Relaxing or disabling a window stops future sweeps from redacting or deleting beyond what the new policy allows; records already redacted or deleted are not restored.
Read the policy back with GET to confirm the resolved values before you rely on them in an internal procedure.

​
GDPR Art. 5(1)(e): why the policy exists

Article 5(1)(e) of the GDPR frames storage limitation: personal data must be kept in a form that permits identification of data subjects for no longer than is necessary for the purposes it was collected for. For a CPaaS operator, the records that attract this principle are exactly the three domains on this page — message bodies carry customer content, conversations carry the thread history, and audit logs carry the workspace trail. The per-domain policy exists so you can express a storage-limitation posture as configuration: short windows where minimization matters (message bodies), longer windows where a regulatory floor argues otherwise (audit logs), and each domain reached independently because a single global TTL never fits all three. The 365-day audit floor is an example of the platform holding a regulatory minimum for you — it stops a mis-set window from destroying SOC 2 evidence, not a limit on how aggressive your posture can be elsewhere. Your counsel decides the windows. The platform enforces them and records every change to the policy itself.
Retention sweeps are deletion machinery, so they share space with two preservation controls:
  • Legal holds. A hold on a conversation exempts that thread from the retention machinery for as long as the hold stands — the sweep skips it. A hold is the litigation-preservation posture; the retention policy is the normal-operation posture, and the hold wins while it stands. Set the policy for the workspace default and use holds for the exceptions.
  • Immutable archival export. Archival copies messages and call recordings into a tamper-evident bundle in your own WORM or S3 store. If your obligations outlive your retention windows, archive before the sweeps start deleting — retention answers “how long does Orbit hold this,” archival answers “how do I hold my own copy.”
  • Erasure requests. DSAR erasure runs contact-scoped and independently of this age-based policy; reconcile open erasure requests against holds as part of your DSAR process rather than expecting the retention windows to fulfil them.

​
Your retention posture stays yours

The per-domain retention policy is a tenant-owned control: Orbit provides the windows, the sweeps, and the audit trail — what the windows are, and which domains apply to your posture, are your decisions. All three domains stay disabled until you enable them, and every enable, change, and disable is a decision your owners and admins made, recorded in your audit log. For the wider assembly — consent records, DSAR intake, the register, the evidence binder — walk the GDPR posture guide.

Legal Holds

Exempt a conversation from retention sweeps for litigation preservation.

Immutable Archival Export

Copy records into a tamper-evident bundle before the sweeps delete them.

GDPR Posture Guide

Assemble the full GDPR posture — consent, DSAR, the register, and the binder.

Data Subject Requests

Contact-scoped access and erasure, and how to reconcile them with holds.