> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# The export families model

> Orbit ships four export families — ad-hoc audience CSV, signed conversation vCon, reverse-ETL destination pushes, and WORM archival bundles. This page is the map: what each family is for, what its format guarantees, what all four share, how failures surface, and where the per-family guides live.

# 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

| Family                       | Data class                       | Surface                                                                                                                            | Right for                                                                                              | Wrong for                                                                      |
| ---------------------------- | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------ |
| **Ad-hoc audience CSV**      | Contacts / segments              | `POST /api/v1/segments/export.csv` (ad-hoc), `GET /api/v1/contacts/segments/:id/export.csv` (saved)                                | One-time audience pulls: compliance spot-checks, partner handoffs, exploratory filters                 | Anything recurring, campaigns, or scheduled refreshes — persist the segment    |
| **Conversation vCon**        | Individual conversations         | `GET /api/v1/conversations/:id/vcon`                                                                                               | Handing one thread to an AI system, a carrier, or a compliance archive with proof it was never altered | Bulk extraction of filtered result sets — use the bulk archive export for that |
| **Reverse-ETL destinations** | Contacts entity + profile traits | Configured under your CDP destinations panel (Snowflake, BigQuery, Redshift, Postgres, Databricks, and other supported warehouses) | Continuously replicating contacts and computed traits into your own warehouse on a schedule            | On-demand copies; the schedule is the point                                    |
| **WORM archival**            | Messages, recordings             | `POST /api/v1/compliance/archival/export`                                                                                          | Retention evidence you need to hold for years and prove has not changed                                | Day-to-day exports of messages or recordings                                   |

## 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

<CardGroup cols={2}>
  <Card title="Ad-hoc audience export" href="/guides/audience-export-adhoc">
    One-shot CSV pulls from a live filter, the saved-segment export trade-off, and when a segment is the right home.
  </Card>

  <Card title="Conversation vCon" href="/guides/conversation-export-vcon">
    The signed IETF container, masking preferences, and audit-log coverage of every export.
  </Card>

  <Card title="CDP segments" href="/guides/cdp-segments">
    Build and save segments, computed traits, and ad-network activation — the audience side of reverse-ETL.
  </Card>

  <Card title="WORM archival export" href="/compliance/archival-export">
    Policy, signed bundles, retention-lock semantics, and mirroring into your own WORM or S3 store.
  </Card>
</CardGroup>
