Skip to main content

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.

Market-data integrations fail quietly when they ignore freshness, coverage, and incidents. Use the data quality routes before backtests, alerts, exports, and research jobs trust a result.
1

Choose venue and symbol

Keep Hyperliquid core, Spot, HIP-3, HIP-4, and Lighter separate before checking data state.
2

Check coverage

Confirm the data family and historical window exist before the job depends on them.
3

Check freshness and incidents

Compare latest ingestion and known interruptions against the job’s tolerance.
4

Run the downstream job

Store the quality result beside the REST, WebSocket, export, or model output.

Data Quality Routes

Route familyUse it for
/v1/data-quality/statusCurrent service and ingestion state
/v1/data-quality/coverageVenue, symbol, and data-family availability
/v1/data-quality/coverage/{exchange}/{symbol}Symbol-level windows, completeness, and gaps
/v1/data-quality/incidentsKnown historical or current interruptions
/v1/data-quality/latencyFreshness and latency measurements
/v1/data-quality/slaSLA-style service reporting
Data-quality responses use route-specific schemas instead of the standard market-data envelope. Use Data Quality REST routes or OpenAPI for exact fields before writing typed clients.

Practical Gate

1

Confirm the market exists

Use instruments or coverage before you request long historical windows.
2

Check the data family

Order books, trades, candles, funding, open interest, liquidations, L3, and L4 can have different history windows.
3

Inspect freshness

Compare the latest ingestion timestamp to the job’s tolerance.
4

Record quality state

Keep the quality response, the downstream data request ID, and any request ID exposed by the quality response or client wrapper.

Reading Status

/v1/data-quality/status returns the service-level view you should check before a downstream workflow acts on market data. A degraded sub-state does not automatically mean every route is unusable. It means the client should inspect the relevant venue and data family, decide whether the lag or missing coverage matters for the job, and record that decision with the output. For example, an alerting job that depends on latest order-book state should care about order-book freshness. A funding-rate analysis should care about funding completeness and the window it is analyzing. A backtest using Spot trades should check Spot freshness, coverage, and incidents before treating the resulting file as clean research data.

Downstream Policy

Do not silently fill gaps. If a coverage route, incident route, or freshness check says a window is unsafe for the job, either narrow the request, delay the run, mark the output, or stop. That policy is more important than the specific client language because it prevents bad data from becoming a strategy result, alert, export, or model feature.

Data quality REST routes

See route families and examples for coverage, freshness, incidents, latency, and SLA checks.

Reliability guide

Design jobs that handle gaps and upstream interruptions without corrupting results.
Last modified on May 18, 2026