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

# Data quality and freshness

> Use 0xArchive freshness, coverage, incident, latency, and SLA routes before downstream jobs depend on market data.

Market-data integrations fail quietly when freshness, coverage, and incidents go unchecked. Before a backtest, alert, export, or model run depends on a result, query the data-quality routes to confirm the venue, symbol, data family, and time window are in a state the job can trust.

<Steps>
  <Step title="Choose venue and symbol">
    Keep Hyperliquid core, Spot, HIP-3, HIP-4, and Lighter separate before checking data state.
  </Step>

  <Step title="Check coverage">
    Confirm the data family and historical window exist before the job depends on them.
  </Step>

  <Step title="Check freshness and incidents">
    Compare latest ingestion and known interruptions against the job's tolerance.
  </Step>

  <Step title="Run the downstream job">
    Store the quality result beside the REST, WebSocket, export, or model output.
  </Step>
</Steps>

## Data Quality Routes

| Route family                                    | Use it for                                            |
| ----------------------------------------------- | ----------------------------------------------------- |
| `/v1/data-quality/status`                       | Current service and ingestion state                   |
| `/v1/data-quality/coverage`                     | Venue, symbol, and data-family availability           |
| `/v1/data-quality/coverage/{exchange}/{symbol}` | Symbol-level windows, completeness, and gaps          |
| `/v1/data-quality/incidents`                    | Known historical or current interruptions             |
| `/v1/data-quality/latency`                      | Freshness and latency measurements                    |
| `/v1/data-quality/sla`                          | SLA-style service reporting                           |
| `/v1/status/coverage`                           | Public coverage/status summary for discovery surfaces |

Data-quality responses use route-specific schemas instead of the standard market-data envelope. Use [OpenAPI](/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 supported venue-family key for that route. It is not a claim that every exchange is covered.

## Pre-Job Quality Check

<Steps>
  <Step title="Confirm the market exists">
    Use instruments or coverage before you request long historical windows.
  </Step>

  <Step title="Check the data family">
    Order books, trades, candles, funding, open interest, liquidations, L3, and L4 can have different history windows.
  </Step>

  <Step title="Inspect freshness">
    Compare the latest ingestion timestamp to the job's tolerance.
  </Step>

  <Step title="Record quality state">
    Keep the quality response, the downstream data request ID, and any request ID exposed by the quality response or client wrapper.
  </Step>
</Steps>

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

<CardGroup cols={2}>
  <Card title="Data quality REST routes" icon="activity" href="/rest-api/data-quality">
    See route families and examples for coverage, freshness, incidents, latency, and SLA checks.
  </Card>

  <Card title="Reliability guide" icon="shield-check" href="/guides/reliability-and-gaps">
    Design jobs that handle gaps and upstream interruptions without corrupting results.
  </Card>
</CardGroup>