> ## 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 historical market-data workflows from native venue calls to 0xArchive while keeping execution, account, and official venue behavior on the native side.

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.

## Migration Plan

<Steps>
  <Step title="Inventory current calls">
    Separate live venue behavior, account/execution behavior, historical market data, local book maintenance, and data-quality monitoring.
  </Step>

  <Step title="Map supported market data">
    Map Hyperliquid core, Hyperliquid Spot, HIP-3, HIP-4, or Lighter calls to the matching 0xArchive route family.
  </Step>

  <Step title="Preserve native authority">
    Do not route execution, account mutation, or official venue control-plane calls through 0xArchive.
  </Step>

  <Step title="Add response and quality handling">
    Parse the response envelope, preserve request IDs, and add freshness, coverage, incident, and gap handling before replacing historical jobs.
  </Step>

  <Step title="Run side by side">
    Compare a bounded window before moving production consumers to the new route.
  </Step>
</Steps>

## 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](/wallet-automation), [Authentication](/authentication), and [Facilitator](/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.

## Next Step

Open [Native Hyperliquid API Vs 0xArchive](/comparisons/native-hyperliquid-api-vs-0xarchive), then map routes with [Venue Taxonomy](/core-concepts/venue-taxonomy) and [REST API](/rest-api).