Migration from a native venue API should move only the jobs that fit 0xArchive: managed historical market data, replay, reconstruction, exports, data-quality checks, and agent-readable route contracts. The goal is not to replace every native call. Keep official venue control, execution-adjacent behavior, and account operations on the native side. Move historical retrieval, replay, reconstruction, data-quality checks, and route-stable downstream workflows to 0xArchive where they fit.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.
Migration Plan
Inventory current calls
Separate live venue behavior, account/execution behavior, historical market data, local book maintenance, and data-quality monitoring.
Map supported market data
Map Hyperliquid core, Hyperliquid Spot, HIP-3, HIP-4, or Lighter calls to the matching 0xArchive route family.
Preserve native authority
Do not route execution, account mutation, or official venue control-plane calls through 0xArchive.
Add response and quality handling
Parse the response envelope, preserve request IDs, and add freshness, coverage, incident, and gap handling before replacing historical jobs.
What Usually Moves
| Native-side job | 0xArchive replacement or support |
|---|---|
| Ad hoc historical order-book pulls | REST history or Data Catalog exports |
| Local archives built from live polling | REST history plus data-quality gates |
| Replay harnesses | WebSocket replay and SDK reconstruction |
| Agent-generated scripts | OpenAPI, docs Markdown, CLI, SDKs, MCP, or Skill |
| Support debugging | meta.request_id, route, parameters, and data-quality records |
What Should Stay Native
Official venue behavior, account operations, execution, wallet mutation, and venue control-plane actions should stay with the native API.Migration Boundary Packet
Use this packet before moving a native integration to 0xArchive.| Native workflow | Move to 0xArchive? | Reason |
|---|---|---|
| Historical order books, trades, candles, funding, OI, liquidations, or orders | Yes, when the venue family is supported | The job is market-data retrieval and can use route-specific history plus data-quality checks. |
| Replay or reconstruction | Yes, when the target depth and route family are supported | WebSocket replay, L3/L4 routes, and SDK reconstruction docs cover the migration path. |
| Export files for research or warehouse loads | Yes, through Data Catalog when file delivery fits | The export flow keeps schema keys, ranges, credits, delivery state, and rights review attached. |
| Official venue control, execution, or account mutation | No | The native API remains the correct authority for those behaviors. |
| Wallet or payment-aware key lifecycle | Only through account/access pages | Use Wallet Automation, Authentication, and Facilitator instead of market-data routes. |
Buyer Context
The migration case is strongest when a team already knows the native venue well but does not want to maintain its own historical archive, replay service, freshness checks, or agent-readable route contract. It is weakest when the requested job is execution, wallet control, live venue governance, or a market family outside the documented 0xArchive surface.Acceptance Criteria
A migrated workflow is not finished when the first request returns. It should preserve route family, symbol, time window, cursor chain,meta.request_id, data-quality result, and the native calls that still remain authoritative.