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
Data-quality responses use route-specific schemas instead of the standard market-data envelope. Use OpenAPI for exact fields before writing typed clients.
Where the API uses
exchange as a path, query, or response field name, read it as the recognized venue-family key for that route. It is not a claim that every exchange is covered.
Pre-Job Quality Check
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.