> ## 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.

# Migrate from a native venue API

> Move one historical order-book workflow to 0xArchive while keeping execution, account, and official venue control outside the market-data migration.

Move one historical Hyperliquid L4 order-book snapshot read from a native venue workflow to 0xArchive, and leave execution, account, and venue-control calls where they are. The example reads a snapshot from one hour ago, inside every plan's history, including Free's most recent 30 days.

## Before you start

* Identify one native workflow that reads historical market data.
* Separate market-data reads from execution, account, wallet, and venue-control operations.
* Choose one Hyperliquid market type, symbol, timestamp, and output consumer.
* Load an API key from the runtime environment and check the selected symbol's quality state.

## Inputs

| Field | Bounded value |
| - | - |
| Venue and market type | Hyperliquid core |
| Symbol | `BTC` |
| Data family | Hyperliquid L4 order-book snapshot |
| Route | `/v1/hyperliquid/orderbook/BTC/l4` |
| Request | `timestamp=$TS&depth=20`, where `TS` is one hour ago in Unix milliseconds |
| Completion condition | The snapshot is saved with its checkpoint, applied-diff count, route, quality, and request metadata |

## Steps

<Steps>
  <Step title="Mark the migration boundary">
    Move only the historical market-data read. Keep native execution, account state, wallet changes, and venue-control operations where they are.
  </Step>

  <Step title="Check the selected window">
    Check the exact market type, symbol, data family, and timestamp with [Data quality](/data-quality) before replacing the old read.
  </Step>

  <Step title="Call the 0xArchive snapshot route">
    ```bash theme={"theme":"github-dark"}
    TS=$(( ($(date +%s) - 3600) * 1000 ))   # one hour ago, in Unix milliseconds

    curl -sS "https://api.0xarchive.io/v1/hyperliquid/orderbook/BTC/l4?timestamp=$TS&depth=20" \
      -H "X-API-Key: $OXARCHIVE_API_KEY"
    ```

    L4 history starts on 2026-03-11 01:03 UTC. A timestamp older than 30 days needs Build or above, which keep the full retained archive.
  </Step>

  <Step title="Adapt only the market-data consumer">
    Preserve the returned checkpoint and reconstruction metadata. A snapshot-only consumer can use the returned state directly. A continuously updated local book still applies ordered diffs after the checkpoint.
  </Step>
</Steps>

## What you get back

The [Hyperliquid L4 snapshot endpoint](/api-reference/hyperliquid--l4-order-book/get-hyperliquid-l4-orderbook) returns an L4 snapshot object in `data` with `checkpoint_timestamp`, `diffs_applied`, `last_block_number`, `bids`, and `asks`. Each resting-order row carries the documented L4 fields, such as `oid`, `user_address`, `side`, `price`, `size`, and `timestamp`. See [L4 REST semantics](/rest-api/order-books-l4) for reconstruction behavior.

0xArchive collects, backfills, and reconstructs the returned snapshot server-side. That removes collection work from this migration, but a consumer that maintains continuously updated state still owns the local checkpoint, ordered-diff, gap, and reconstruction handling. For ordered events instead of a snapshot, use [WebSocket replay](/websocket/replay).

## Compare the outputs

Compare one old output and one 0xArchive output for the same market, symbol, timestamp, and depth. Record the route, query, snapshot timestamp, checkpoint timestamp, number of applied diffs, and request ID. Confirm that the consumer does not treat a snapshot as a continuous stream.

## If something fails

* No usable coverage for the timestamp: stop the migration and choose a window that the route and quality response show as covered.
* `401`: repair the key source or header.
* `404`: check the Hyperliquid namespace and symbol format.
* A reconstruction or gap signal: discard unsafe local state, restart from the returned checkpoint, and apply ordered diffs only after the checkpoint.
* A mismatch with the old consumer: keep the old market-data path for comparison, inspect the exact route schema, and keep execution and account calls out of this workflow.

## Saved run metadata

```json theme={"theme":"github-dark"}
{
  "migration": "hyperliquid-core-l4-snapshot-001",
  "venue_family": "hyperliquid_core",
  "symbol": "BTC",
  "data_family": "l4_orderbook",
  "route": "/v1/hyperliquid/orderbook/BTC/l4",
  "query": {
    "timestamp": "TS in Unix ms",
    "depth": 20
  },
  "quality_source": "record the selected data-quality response",
  "request_ids": ["00000000-0000-0000-0000-000000000000"],
  "checkpoint_timestamp": "record the response value",
  "diffs_applied": "record the response value",
  "native_scope_boundary": ["execution", "account", "wallet", "official venue control"],
  "output": "./artifacts/btc-l4-snapshot-001.json"
}
```

The zero UUID is a shape placeholder only. Replace it with the UUID returned by the route or client wrapper. `native_scope_boundary` lists the calls that stay on the native API.

## Next step

Keep a local book current after the snapshot by applying ordered diffs with [SDK reconstruction](/sdks/reconstruction).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.