Migrate from a native venue API

Move the jobs that fit 0xArchive: historical market data, replay, reconstruction, exports, data-quality checks, and agent-readable route contracts. Keep official venue control, execution, and account operations on the native side. The goal is not to replace every native call; it is to stop operating the parts of the stack that 0xArchive already runs.

Before and after

The native Hyperliquid API streams live data and answers point-in-time queries, but it has no historical order-book or L4 endpoint. To get history, a team runs and maintains its own pipeline:

a WebSocket collector running around the clock, subscribed to every book and trade channel
storage for the raw stream, sized for the deepest book you keep
a reconstruction step that replays diffs into a point-in-time book
gap detection and backfill for every disconnect
decimal handling for integer-scaled and string fields, per channel

That is a service to operate, not a feature to call. And it only collects data from the day you turned it on. 0xArchive runs that pipeline for you. The same point-in-time L4 book is one request:

curl "https://api.0xarchive.io/v1/hyperliquid/orderbook/BTC/l4" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"

You get the reconstructed book as normalized JSON: oid and the wallet on every resting order, a checkpoint_timestamp, and the diffs already applied. No collector, no backfill, no decode step. Hyperliquid history reaches back to 2023, including the window you never collected.

Migration plan

Inventory current calls

Separate live venue behavior, account/execution behavior, historical market data, local book maintenance, and data-quality monitoring.

Map Hyperliquid and Lighter 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.

Run side by side

Compare a bounded window against your native pipeline before moving production consumers to the new route.

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 stay with the native API. 0xArchive is the historical and live market-data layer, not an execution venue.

Migration boundary checklist

Use this 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 call maps to a documented Hyperliquid or Lighter route family	The job is market-data retrieval and can use route-specific history plus data-quality checks.
Replay or reconstruction	Yes, when the exact route exposes the target depth	WebSocket replay, L3/L4 routes, and SDK reconstruction 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-owned account verification or payment infrastructure	Only through account/access pages	Use SIWE verification, Authentication, and Facilitator instead of market-data routes.

When the case is strongest

The migration case is strongest when a team 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 job is execution, wallet control, live venue governance, or a market family outside the documented 0xArchive surface.

Acceptance

A migrated workflow is not finished when the first request returns. It should preserve route family, symbol, time window, cursor chain, meta.request_id, the data-quality result, and the native calls that remain authoritative.

Next step

Open Native Hyperliquid API Vs 0xArchive, then map routes with Venue taxonomy and the REST API.

​Before and after

​Migration plan

​What usually moves

​What should stay native

​Migration boundary checklist

​When the case is strongest

​Acceptance

​Next step