Flat-file delivery
Governed bulk exports by pull, push, or both—with immutable manifests and repeatable deltas
Use flat-file delivery when an API page is not the right unit of work: initial warehouse loads, scheduled deltas, governed data shares, and large analytical workloads. Every delivery is entitlement-filtered before shaping and carries an immutable manifest that identifies its schema, profile, checkpoint, parts, and checksums.
Pull deliveries
Download short-lived parts from a manifest-driven API workflow.
Push to your S3 bucket
Onboard a cross-account destination and receive atomic publications.
API authentication
The same customer API key and entitlement boundary applies.
Choose a delivery model
Pull · Customer downloads
Best default. Read the manifest, request a short-lived URL for each part, verify it, then acknowledge consumption.
Push · Platform writes to S3
For AWS-native pipelines that require delivery into a customer-controlled bucket. Requires destination onboarding and the file-push capability.
Both · Push with pull fallback
Publishes to the verified S3 destination and retains the governed pull workflow for recovery or independent verification.
Push is capability-gated
Pull is the recommended default and does not require a customer-managed
destination. push and both are optional, customer-specific capabilities:
they additionally require the global push service to be active, a customer
file_export_push capability, and an active verified destination.
One-off or recurring
Create a complete snapshot for backfills, evaluation, or a controlled
reload. idempotencyKey must be stable across retries.
POST /v1/file-exports
Content-Type: application/json
x-api-key: YOUR_API_KEY
{
"domain": "listing",
"deliveryMode": "pull",
"idempotencyKey": "warehouse-backfill-2026-07-22"
}A subscription begins with generation 1, sequence 0 (the seed), then publishes ordered deltas over checkpoint windows.
POST /v1/file-export-subscriptions
Content-Type: application/json
x-api-key: YOUR_API_KEY
{
"name": "Nightly listing warehouse feed",
"domain": "listing",
"deliveryMode": "pull",
"cadenceSeconds": 86400,
"preferredMinuteOfDay": 300,
"emptyDeliveryBehavior": "manifest_only"
}Delivery lifecycle
Request or subscribe
Create a one-off export, or establish a recurring subscription with an explicit cadence and delivery mode.
Wait for complete
Poll GET /v1/file-exports/{id}. Never infer readiness from an object that
happens to exist; the delivery ledger is authoritative.
Read and validate the manifest
Fetch /manifest, verify meta.manifest_sha256, pin the schema/profile and
entitlement versions, and process parts in manifest order.
Load idempotently
Stage parts, verify every SHA-256, then commit the full sequence in one warehouse transaction or atomic partition swap.
Record consumption
Acknowledge a recurring delivery after the load commits. An acknowledgement is evidence; it does not advance or mutate the canonical export cursor.
Formats and data products
| Capability | Contract |
|---|---|
| Domains | property, listing, public_record, market_report |
| Formats | CSV, JSONL, or Parquet according to the assigned output profile |
| Compression | Deterministic gzip for text profiles; ZSTD for Parquet; none only where the profile permits it |
| Listing bundle | Manifest v2 can include listing, listing_media, and media_assets datasets |
| Empty delta | A valid manifest with noChange: true, zero rows, and zero parts |
| Removals | Tombstones carry the customer-facing ID and the profile-defined removal reason when configured |