> ## 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 REST API

> Use REST routes for coverage, freshness, incidents, latency, status, and SLA checks.

Data quality routes live under `/v1/data-quality/*`. Use them before historical pulls, replay windows, exports, dashboards, alerts, and model inputs depend on market data.

These routes return resource-specific bodies such as `StatusResponse`, `CoverageResponse`, `SymbolCoverageResponse`, `IncidentsResponse`, `LatencyResponse`, and `SlaResponse`. They are not ordinary market-data envelopes. Use the generated REST reference as the schema source for each response body.

## Preflight Sequence

<Steps>
  <Step title="Check status">
    Confirm the API and ingestion surfaces are healthy enough for the job.
  </Step>

  <Step title="Check coverage">
    Confirm venue, symbol, and data family history exists for the requested time range.
  </Step>

  <Step title="Check incidents">
    Look for interruptions that overlap the requested market and time window.
  </Step>

  <Step title="Run the market-data request">
    Store the quality result, the data pull request ID, and any request ID exposed by the quality response or client wrapper.
  </Step>
</Steps>

## Example

Check current system state:

```bash theme={"theme":"github-dark"}
curl "https://api.0xarchive.io/v1/data-quality/status" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"
```

Check one symbol and window:

```bash theme={"theme":"github-dark"}
curl "https://api.0xarchive.io/v1/data-quality/coverage/hyperliquid/BTC?from=1777593600000&to=1777680000000" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"
```

`from` and `to` are Unix timestamps in milliseconds. Convert ISO windows before calling this coverage route from shell scripts, generated clients, or agent tools.

Check recent incidents for one venue:

```bash theme={"theme":"github-dark"}
curl "https://api.0xarchive.io/v1/data-quality/incidents?exchange=hyperliquid&status=resolved&limit=10" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"
```

## What To Store

Store the quality result with the downstream job output. At minimum, keep the route, request parameters, returned status or coverage fields, venue family, symbol or market set, gaps or incidents that changed the decision, and the time the check ran. If a response or client wrapper exposes a request ID, keep it too; do not require `meta.request_id` from data-quality bodies that do not expose the market-data envelope.

## Route Fit

| Route                                           | Use it for                                        | Store with output                                                       |
| ----------------------------------------------- | ------------------------------------------------- | ----------------------------------------------------------------------- |
| `/v1/data-quality/status`                       | Broad service and ingestion state                 | overall status, updated time, per-exchange state, active incident count |
| `/v1/data-quality/coverage`                     | Exchange and data-family coverage summary         | exchange, data type, earliest/latest, completeness                      |
| `/v1/data-quality/coverage/{exchange}/{symbol}` | Symbol-level coverage and gaps for a window       | exchange, symbol, data family, gaps, completeness, historical coverage  |
| `/v1/data-quality/incidents`                    | Known interruptions by status, exchange, and time | incident IDs, severity, status, affected symbols, start/end             |
| `/v1/data-quality/latency`                      | Current API, WebSocket, and freshness latency     | measured time, exchange latency, data freshness lag                     |
| `/v1/data-quality/sla`                          | SLA-style reporting for a period                  | period, targets, actuals, downtime, incident count                      |

A job that depends on historical accuracy should usually call more than one route: coverage first, then incidents or latency depending on the downstream risk.

## Client Policy

Treat data-quality responses as decision inputs for your pipeline. If a window is stale or interrupted, the application should narrow the request, delay, annotate the output, or stop. It should not silently interpolate missing market data.

## Evaluation Fit

A market-data provider should not only return rows; it should tell you whether the requested window was covered, fresh enough, delayed, or affected by an incident. Use these routes to turn that question into application behavior instead of a manual review step.

## Generated-Client Rule

Before generating historical pulls, alerts, exports, dashboards, or model inputs, add a data-quality preflight. If the user only asks for one raw request, keep it simple; otherwise make quality state part of the implementation.

Quality routes are part of the API contract, not an optional monitoring sidebar.

<CardGroup cols={2}>
  <Card title="Data quality guide" icon="activity" href="/data-quality">
    Apply freshness and coverage checks to real workflows.
  </Card>

  <Card title="Reliability guide" icon="shield-check" href="/guides/reliability-and-gaps">
    Design retry and fallback behavior around gaps.
  </Card>
</CardGroup>