​

Configure per-domain retention windows

​

Where the console lives

1. Retention policy — the per-channel media windows (voice recordings, SMS/MMS media, email attachments, WhatsApp, RCS, and Viber media), each of which governs the actual file Orbit stored for that channel, plus the scheduled message-body redaction window, the unified recordings window, the video-room session history window, a hard-delete toggle, and the webhook-delivery grace hours.
2. Data retention policy — the per-domain privacy posture: message-body redaction, closed-conversation hard-delete, and audit-log purge, each with its own enable switch and window.

​

The per-domain windows you can set

• The media sweep and each channel window are clamped to 7–3650 days; the 7-day floor guarantees post-event dispute lookback.
• The recordings window cannot exceed the object-storage bucket lifecycle safety net: media is hard-purged at 365 days no matter which window you set.
• The video-room session history window is a separate knob (default 90 days) and does not inherit from the recordings window.

​

Console vs. concept: which page does what

• This page (the console) is where you act: enable a domain, pick a window, and read the resolved policy back. It is operational — it answers “how do I set retention for my workspace.” Writes are merge-on-write, audit-logged, and enforcement is purely sweep-based.
• Retention windows and deletion is the model: the cross-store map of every data class, its default window, what flips at expiry, and how preservation (legal hold, WORM export) and erasure (DSAR) cut across the age-based machinery. It answers “what does retention on Orbit consist of.” You configure nothing there.
• Per-Domain Data Retention Policy is the API reference for the same three domains — the endpoint contract, bounds, and merge-on-write rules for when you automate the policy over the API instead of clicking the console.

​

The worked loop

​

1. Read the current windows

​

2. Adjust one window

1. In Data retention policy, enable Closed conversations and set the window to 120.
2. Save. The write is merge-on-write, and the dashboard submits only the fields you actually changed, so untouched domains keep their stored values — adjusting the conversation window never re-affirms the message or audit domains behind your back.
3. Watch for a conflict gate: when a shortened recordings window would purge recording media earlier than the voice recordings metadata window implies, Save stays disabled until you explicitly acknowledge the earlier deletion date. The acknowledgment is deliberate — it makes a blind contradictory save impossible, and changing either window resets it.

​

3. Verify propagation

• In the console. Re-open the Retention tab and confirm the editor shows the new resolved value — for the example above, closed conversations now read 120 days.
• Over the API. Read the resolved policy the same way your automation would:

curl https://api.orbit.devotel.io/api/v1/compliance/data-retention \
  -H "X-API-Key: dv_live_sk_..."

{
  "data": {
    "messages": { "redact_body_after_days": 0 },
    "conversations": { "enabled": true, "delete_closed_after_days": 120 },
    "audit_logs": { "enabled": false, "delete_after_days": 2190 }
  }
}

• The enforcement clock. The endpoint records policy only. A tightened window queues the newly over-window records for the next scheduled sweep — nothing is redacted or deleted at the instant you save, and nothing already swept is restored if you relax the window. Plan your runbook on the sweep cadence, not on the save.

​

4. Export the evidence

1. Open Settings → Compliance → Audit & Evidence and export the audit log for the period — the retention-policy writes are the change trail for the posture itself.
2. Attach the read-back from step 3 above (the resolved GET response) to show the policy that was in force alongside the change trail.

​

Common gotchas

• Legal holds outrank the windows. A legal hold on a conversation or recording exempts it from every retention sweep for as long as the hold stands — the sweep skips it. Retention defines normal operation; the hold defines litigation preservation, and the hold wins. If the closed-conversation sweep looks like it missed a thread, check for a hold before you suspect the sweep.
• The 30-day conversation floor. The closed-conversation window cannot go below 30 days — a thread that closed hours ago can never be swept. Choose at or above the floor.
• The 365-day audit floor is regulatory, not a cap. Audit entries cannot be purged younger than one year, protecting the SOC 2 examination window. It limits how aggressively you can purge evidence, not how conservative the rest of your posture can be.
• Sweeps are asynchronous. Saving a window changes policy, not data. A record crossing its window becomes eligible and is redacted or deleted on the next sweep run; relaxed or disabled windows stop future sweeps only — swept records are never restored.
• Redaction is not deletion. Message retention replaces the body and identifiers with a marker and keeps status, receipt, and pricing metadata; the closed-conversation sweep removes only the thread row and leaves message rows. Billing and dispute lookback keep working on every swept record.
• DSAR erasure is a separate machine. A data-subject erasure request is contact-scoped and runs its own workflow independent of these org-wide windows — the windows do not fulfill an open erasure, and an erasure does not wait for a window. Reconcile the two in your DSAR process.
• Recordings stop at 365 days no matter what. The object-storage bucket lifecycle is a platform safety net above every recordings window. If your obligation is longer, export to your own archive first.
• Every save is merge-on-write. Domains you do not touch keep their stored values — a save can never silently reset a sibling domain, and an out-of-range field fails the whole write with a 422, never a partial apply.

​

Related