​

The export families model

Four different surfaces in Orbit move data out of your workspace: ad-hoc audience exports, conversation exports, CDP reverse-ETL pushes, and the WORM archival export. Each exists for a different audience and lifecycle, and picking the wrong one wastes a time-bounded bundle or holds up a compliance process. This page is the map.

​

1. The four families, and when each is the right move

​

2. What the format guarantees

• Ad-hoc CSV is point-in-time and non-restartable. The filter resolves against your live contacts the moment you call it, up to a 50,000-row ceiling (500,000 on the saved-export path). The X-Export-Truncated header tells you whether the window cut off. Re-run the request to re-export after membership changes; nothing persists between runs. Per-record PII masking matches the caller’s reveal context.
• vCon captures conversation state. Parties, dialog, attachments, and analysis sections, signed at export time so the recipient can prove it was not altered. The container mints a fresh uuid per export rather than exposing the internal conversation id.
• Reverse-ETL is a scheduled push into the destination profile catalog. BigQuery, Snowflake, Redshift, and Postgres resolve profile traits as first-class columns (native); Databricks and ClickHouse carry the same raw export and traits resolve through SQL over the exported data (organic); unconfigured destinations report not_configured. The read model projecting this verdict onto your computed-trait catalog lives at GET /api/v1/cdp/reverse-etl/profile-exports.
• WORM is tamper-evident signing plus a hash chain. Every export returns a removable bundle containing a signed manifest, a per-file SHA-256 checksum table, and verification instructions. Optionally encrypted under a one-time passphrase Orbit never stores. The lock promise (window, basis, version) is stamped into the export manifest so an auditor can check the policy was still in force when records were captured.

​

3. Common denominators

These four families differ in format and lifecycle, but they share a core safety model:

• Tenant-scoped. Every export runs against documents in your own tenant schema. A cross-tenant export is not a thing the API can do.
• Per-record ownership checks. The request authorizes as the workspace it claims to belong to; a record outside that workspace never enters the export.
• Time-bounded URIs. vCon responses, archival download URLs, and streaming export payloads generated to a signed URL are time-bounded — pick up the artifact while the URL is valid, then mirror it into your own store. Re-run the export to revive an expired URL.
• Signed URLs where applicable. Archival exports are the canonical example: a signed URL (7-day expiry on archival bundles) plus the checksum block let your mirroring job prove the artifact it fetched matches what Orbit produced.

​

4. Failure semantics

• WORM hash mismatch. Your mirroring flow treats the archive as evidence to verify, not just fetch. The export response returns bundleSha256 and a manifest signature; the bundled VERIFY.txt documents how to replay the per-file checksums in your own environment. On audit-log exports, GET /api/v1/compliance/audit-export/:jobId/verify replays the hash chain and returns a replay-status verdict (prev_hash_mismatch or current_hash_mismatch flag the broken link). Either way, a mismatch is loud rather than silent — the bundle never lands in your archive.
• Reverse-ETL retries. Scheduled pushes persist per-destination run-status (last_run_at, last_run_status, last_run_rows_contacts, last_run_rows_events, last_error). Read GET /api/v1/cdp/reverse-etl/sync-runs for per-destination health — failing destinations surface the last error rather than fail silent, and stale flags runs older than the expected cadence.

​

5. Where the per-family guides live