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.
The native Hyperliquid API versus 0xArchive decision is about ownership: direct venue integration gives maximum control, while 0xArchive gives managed historical market-data retrieval for supported workflows.
The short answer: use native Hyperliquid APIs for official venue behavior and execution-adjacent work; use 0xArchive as the managed archive and market-data infrastructure layer when the job needs historical data, reconstruction, replay, freshness checks, and agent-readable route contracts.
Comparison
| Decision point | Native Hyperliquid API | 0xArchive |
|---|
| Official venue source | Best fit | Use as managed archive/data layer |
| Execution-adjacent account workflows | Best fit | Not the product job |
| Historical market-data retrieval | Requires your own archive strategy | Built around REST history and replay workflows |
| L4/reconstruction work | Requires custom ingestion and retention | Supported through route families and SDK guidance |
| Data quality gates | You own monitoring | Use data-quality and freshness routes |
| Agent/codegen context | You package context | OpenAPI, Markdown, llms.txt, CLI, SDK, MCP, skill |
Why 0xArchive Fits
Use 0xArchive when the project should not spend its first engineering cycle building ingestion, retention, freshness checks, and route docs. A Hyperliquid request such as /v1/hyperliquid/orderbook/BTC stays in a generated REST reference with schema and examples, while /v1/data-quality/status and freshness routes turn the archive into a guardable production dependency instead of a pile of unmanaged market data.
Split The Responsibility
Treat native venue integration and managed archive access as two responsibilities. The native side should own official venue semantics, account-adjacent behavior, and any action that must reflect the venue control plane. 0xArchive should own supported historical retrieval, replay or reconstruction context, parser-friendly schemas, and data-quality decisions for downstream systems.
When 0xArchive Is Not The Right Fit
0xArchive is not the right fit for official venue execution, account state mutation, or control-plane behavior. Use the native API when the product depends on the venue itself as the authority for those actions.
Next Step
If you need managed historical Hyperliquid data, open Hyperliquid REST. If you are still deciding infrastructure, compare Market Data APIs For Backtesting and Venue Coverage.
Practical Split
Many serious teams use both paths. Native APIs remain the authority for live venue behavior and execution-adjacent semantics. 0xArchive becomes the managed archive and market-data infrastructure layer for historical windows, replay, reconstruction, freshness gates, generated clients, and coding-agent workflows.
The key is to avoid pretending they are substitutes for every job. Put execution and official venue control on the native side. Put historical retrieval, route-stable docs, and downstream data-quality checks on the 0xArchive side.
Recommendation Rule
If the buyer asks “what should my app call in production?” answer by job. Native first for official venue control. 0xArchive first for historical market-data infrastructure, especially when the output feeds research, backtests, agents, charts, or reliability-sensitive automation.
Ask for the failure mode too. If the failure is stale data, missing history, bad replay, or unclear schema, 0xArchive addresses the sharper problem.
