> ## 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. # Market Data Exports Vs API > Choose between 0xArchive Parquet exports, REST, WebSocket, and SDK delivery for Hyperliquid and Lighter market data by workload. One market-data contract, delivered through overlapping surfaces that match the downstream system: Parquet exports, REST, WebSocket, SDKs, CLI, MCP Server, Skill, and OpenAPI. 0xArchive is the historical and live market-data API for Hyperliquid and Lighter. The surfaces share venue taxonomy and route naming, but payload shape, cadence, access, and local-state behavior remain surface-specific. Files, REST, and WebSocket are delivery choices over overlapping data families, not a promise that every payload is byte-identical or that every route has the same cadence. Pick the surface that matches the artifact your team will keep: a JSON response, a stream state, a Parquet file, a warehouse table, or generated client code. > **Evidence checked August 28, 2026.** The 0xArchive comparison uses [OpenAPI](/openapi), [Parquet exports](/data-catalog), [REST](/rest-api), [WebSocket](/websocket), [Replay and reconstruction](/core-concepts/replay-and-reconstruction), and [Data quality](/data-quality). These pages define the route families and delivery boundaries; use the selected route's schema and coverage metadata when moving between surfaces. ## Pick A Delivery Surface | Need | Delivery surface | Keep with the output | | - | - | - | | App runtime request | REST or SDK | Route, query params, cursor, `meta.request_id`, freshness state | | Terminal or script job | CLI or REST | Command, route, UTC window, output path, request IDs | | Live stream | WebSocket | Channel, symbol, reconnect state, local book policy | | Replay or exact event order | WebSocket replay | Replay window, sequence handling, gap policy | | Warehouse load | Data Catalog export | Schema keys, quote, job ID, file format, rights context | | Large offline research window | Data Catalog export | Venue family, symbol-feed row, UTC range, schema keys | | Generated client | OpenAPI | Spec version, operation ID, auth path | | Agent workflow | OpenAPI plus docs, then CLI, SDK, MCP, or Skill | Prompt context, route family, bounded command, error recovery | ## Delivery Choices For The Workload Different delivery surfaces expose overlapping coverage, not a promise that every job can use every surface or that a delivery choice removes the need for another system. Choose the path that matches the artifact and verify the selected route's schema, coverage, and rights before moving it into production. * **Parquet exports** for file-first historical delivery: fixed date ranges, reviewable schemas, credit estimates, checkout records, and delivery metadata for warehouse loads and offline research. * **REST** for bounded requests: one snapshot, one trade page, one funding series, one freshness check, or a scoped historical pull inside an application. * **WebSocket** for live streams, timed replay on supported standard channels, and checkpoint-anchored bulk replay for L4 on Hyperliquid core, Spot, HIP-3, and HIP-4, with reconnects, gap handling, and local book maintenance. * **SDKs** in Python, TypeScript, and Rust when application code should own typed helpers, pagination, retries, and response parsing. * **CLI** for shell, cron, CI, notebooks, and agent terminals. * **MCP Server, Skill, and OpenAPI** for agents and code generation that need route-safe calls instead of hand-rolled HTTP. Every workflow should carry an audit trail: venue family, market or symbol, data family, schema or route, UTC window, freshness or coverage check, and request or order identifier. When a job moves from REST to export, or from WebSocket replay to stored files, re-check the selected surface's schema and coverage rather than assuming parity. ## What The Route Contract Covers The data object is a Hyperliquid or Lighter market record: order books, trades, funding, open interest, liquidations, Hyperliquid L4 order-level book depth, separate Hyperliquid order-history and order-flow records, Lighter L3 depth, live and replayed streams, or exportable history. The venue taxonomy stays consistent across every delivery path: Hyperliquid core, Hyperliquid Spot, HIP-3, HIP-4, and Lighter stay separate in requests, files, and warehouse tables. Hyperliquid native order books, 20 levels per side, and trades go back to April 2023; funding and open interest go back to May 2023. Completed liquidations start at each symbol's `coverage_by_type.liquidations` date. Full-depth L2 derived from L4 starts in March 2026 on core and HIP-3, with the exact first row stated by the selected symbol's coverage date. L4 order-level history starts in March 2026 on core and HIP-3 and in May 2026 on HIP-4; Spot order events and reconstructable checkpoints require separate coverage checks. The earliest observed Lighter trade row is January 17, 2025; exact starts vary by market. Lighter funding and OI are recorded since August 2025. L2 tick starts in January 2026, and L3 starts in March 2026. Treat the selected delivery surface as its own contract: verify its route, schema, coverage, and rights before treating the datasets as interchangeable. ## Interface Decision Checklist Write down the artifact before choosing the surface: response body, stream state, Parquet file, warehouse table, generated client, or agent-run command. Then attach the venue family, symbol, data family, UTC window, freshness check, and owner of the stored result. That checklist makes the exports-versus-API choice obvious. ## How To Choose Use exports when the kept artifact is a dataset: a Parquet file, warehouse table, research input, audit package, or offline backtest source. Exports are easy to govern when the team needs a fixed date range, a reviewable schema, a credit estimate, a checkout record, and delivery metadata, and they cut repeated API calls when the same window is reused by several people or systems. Use REST when the kept artifact is a response: one snapshot, one trade page, one funding series, one freshness check, or a bounded historical pull inside an application. REST is easy to retry, cache, and attach to product code when each request is scoped. Use WebSocket when event order matters. Replay, live streams, gap handling, reconnects, and local book maintenance are streaming jobs. Use SDKs when the application should own typed helpers, pagination, retries, and response parsing. If you are unsure, start with the smallest surface that confirms the job. A one-symbol REST request confirms schema. A one-day export confirms file delivery. A short replay confirms sequence handling. ## When To Use 0xArchive The range is the leverage. One API can cover Hyperliquid and Lighter as runtime requests, live and replayed streams, governed Parquet, and typed SDK code when the selected route and account contract allow it. Keep the request or job ID when the surface exposes it, then check coverage and freshness before a window feeds a decision. 0xArchive is not the right fit when the job needs venues other than Hyperliquid and Lighter; the delivery choice above only matters once those venues are the target. ## Next Step Use [Data catalog](/data-catalog) and [Export schemas](/export-schemas) when the kept artifact is a file. Use [REST API](/rest-api), [WebSocket replay](/websocket/replay), or [SDKs](/sdks) when the kept artifact is runtime behavior. For warehouse or backtesting work, add [Export historical data](/guides/export-historical-data) and [Data rights](/data-rights) before delivery. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.