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

# Export historical data

> Choose market, schema, date range, credits, checkout, and delivery behavior for 0xArchive Data Catalog exports.

Historical file exports are for workflows where a bounded dataset is easier to govern, load, review, or procure than repeated API responses.

The Data Catalog export flow is a product surface for file-style delivery. It is related to REST and WebSocket docs, but it is not the same contract as the public market-data API.

## Export Workflow

<Steps>
  <Step title="Choose a market">
    Start from `/data`, `/data/catalog`, a category page, or a market page. Market slugs are generated, so preserve the venue family and market slug supplied by the UI instead of constructing one from a plain symbol.
  </Step>

  <Step title="Choose schemas">
    Select only the data families needed: L2, L3, L4, trades, funding, OI, liquidations, or order events.
  </Step>

  <Step title="Choose UTC dates">
    Keep the requested date range explicit. The browser presets are `30D`, `90D`, `1Y`, `All`, and `Custom`; coverage and settled-market end dates can constrain the window.
  </Step>

  <Step title="Review the estimate">
    Check estimated size, rows, credits, pricing unit, minimums, and any subscriber-credit context.
  </Step>

  <Step title="Place the order">
    Use the authenticated Data Catalog checkout flow. Build API clients against documented OpenAPI routes; do not depend on browser checkout calls unless they are published as public API routes.
  </Step>

  <Step title="Store metadata with files">
    Keep venue family, market, schema key, UTC range, quote context, and data-rights decision with the output.
  </Step>
</Steps>

## When To Export Instead Of Call The API

Use exports for warehouse loading, offline research, large historical windows, durable datasets, or workflows where Parquet files are easier to govern than many API calls.

Use REST for app-integrated bounded requests. Use WebSocket replay when event order is part of the product requirement.

## Validation Step

Before widening an order, run the smallest useful export: one market, one schema, and a short UTC window. Confirm the file schema, row timestamps, market identity, size estimate, and downstream loader behavior. Then scale the date range or schema set with the same metadata attached.

## Shareable Selection Parameters

Catalog URLs can preserve a configured selection, but those parameters describe browser state, not a public REST contract.

| Parameter                                   | Meaning                                                                                     |
| ------------------------------------------- | ------------------------------------------------------------------------------------------- |
| `selected`                                  | Legacy selection key in `exchange:symbol` form when a market route is not already selected. |
| `schemas`                                   | Comma-separated export schema keys, for example `l2_orderbook`, `trades`, and `oi`.         |
| `range`                                     | One of `30d`, `90d`, `1y`, `all`, or `custom`.                                              |
| `start` and `end`                           | Required only for `range=custom`; dates are clamped to coverage.                            |
| `hip4_event`, `hip4_contracts`, `hip4_side` | HIP-4 BTC daily outcome selection state.                                                    |

When a market route such as `/data/markets/hyperliquid/btc-uc0r/` is available, prefer that route over a `selected` query string. Keep the configured route, schema keys, and date range with the export checklist so another user can reproduce the order without reconstructing the browser flow.

## Export Order Checklist

Keep a compact order record with every export request and delivered file.

| Field              | Capture                                                                                                                                                                                             |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Market identity    | Venue family, market slug, symbol or pair, and any HIP-3 builder prefix or HIP-4 outcome context                                                                                                    |
| Schema set         | Selected schema keys such as `l2_orderbook`, `l3_orderbook`, `l4_orderbook`, `trades`, `funding`, `oi`, or `liquidations`                                                                           |
| Cart item identity | One cart item is keyed as `exchange:symbol:data_type`; `data_type` is the selected schema key, such as `trades`, `l2_orderbook`, or `oi`. Keep that identity with each selected market/schema pair. |
| Date range         | UTC start date, UTC end date, and any settled-market end constraint                                                                                                                                 |
| Estimate           | Size, rows, credits, pricing unit, minimums, and quote context shown before checkout                                                                                                                |
| Delivery           | File format, compression, job ID or dashboard reference, and link-expiration behavior                                                                                                               |
| Rights             | Internal use, derived use, redistribution review, and retention requirements                                                                                                                        |
| Loader check       | Row count, timestamp range, schema match, partitioning choice, and downstream destination                                                                                                           |

This checklist lets another engineer understand the file without replaying the browser flow. It also keeps Data Catalog exports separate from JSON API responses when files move into a warehouse or model pipeline.

## Related Pages

<CardGroup cols={2}>
  <Card title="Data catalog" icon="database" href="/data-catalog">
    Website route model and export product boundaries.
  </Card>

  <Card title="Export schemas" icon="table-properties" href="/export-schemas">
    Schema keys, coverage keys, rough columns, pricing units, and format.
  </Card>

  <Card title="Export checkout" icon="shopping-cart" href="/export-checkout">
    Credits, quote, checkout, authenticated return, and dashboard behavior.
  </Card>

  <Card title="Data rights" icon="shield-check" href="/data-rights">
    Internal use, derived use, and raw redistribution boundaries.
  </Card>
</CardGroup>