> ## 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 routes > Use 0xArchive REST routes for coverage, freshness, incidents, latency, status, and SLA checks before downstream market-data work. Check coverage, freshness, incidents, latency, status, and SLA for Hyperliquid and Lighter market data with the `/v1/data-quality/*` routes, before a historical pull, replay window, export, dashboard, alert, or model input depends on it. Each route returns its own resource body, such as `StatusResponse`, `CoverageResponse`, `SymbolCoverageResponse`, `IncidentsResponse`, `LatencyResponse`, or `SlaResponse`. By default the body's fields sit at the top level next to `success: true` and `meta.request_id`, not inside `data`; send `0xArchive-Version: 2026-10-01` to receive the standard `{ success, data, meta }` envelope (see [API conventions](/conventions#versioning)). The [Data-quality endpoint reference](/api-reference/data-quality) has each response body, and [Data-quality operation schemas](/schemas/families/data-quality) the JSON fields. `/v1/status/coverage` is a public coverage summary in the same OpenAPI contract. Use `/v1/data-quality/*` when a workflow needs the full data-quality bodies. Some data-quality routes keep the path or query parameter name `exchange` for API compatibility. Treat that value as the recognized venue-family key for the route. It is not a claim that every exchange is covered. The latency resource combines service timing and data freshness signals. Its `websocket.current_ms` value is the latest stored order-book freshness measurement, not client WebSocket round-trip time. Use the WebSocket ping/pong mechanism for a client-side observation, and do not treat it as a platform latency percentile. ## Preflight sequence Confirm the API and ingestion surfaces are healthy enough for the job. Confirm venue, symbol, and data family history exists for the requested time range. Look for interruptions that overlap the requested market and time window. Store the quality result, the data pull request ID, and any request ID exposed by the quality response or client wrapper. ## 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" ``` A status response (shape; the values are live): ```json theme={"theme":"github-dark"} { "success": true, "status": "degraded", "updated_at": "2026-06-05T17:09:49Z", "exchanges": { "hyperliquid": { "status": "operational", "last_data_at": "2026-06-05T17:09:45Z", "latency_ms": 4325 }, "lighter": { "status": "operational", "last_data_at": "2026-06-05T17:09:11Z", "latency_ms": 38773 } }, "data_types": { "orderbook": { "status": "operational", "completeness_24h": 100 }, "open_interest": { "status": "degraded", "completeness_24h": 98.5 } }, "active_incidents": 0, "meta": { "request_id": "dddddddd-dddd-4ddd-8ddd-dddddddddddd" } } ``` `status` rolls up to `operational`, `degraded`, or `outage`. A degraded data type does not mean every route is unusable, so compare the state to your job's tolerance. Check one symbol over the 24 hours that ended one hour ago: ```bash theme={"theme":"github-dark"} END=$(( ($(date +%s) - 3600) * 1000 )) # one hour ago, in Unix milliseconds START=$(( END - 24 * 3600 * 1000 )) # 24 hours earlier curl "https://api.0xarchive.io/v1/data-quality/coverage/hyperliquid/BTC?from=$START&to=$END" \ -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" ``` ## Response fields The main body shapes, as returned without the version header: **`/v1/data-quality/status`** | Field | Description | | - | - | | `status` | String. Overall roll-up: `operational`, `degraded`, or `outage` | | `updated_at` | String. When the status was computed | | `exchanges` | Object. Per venue-family map; each entry has `status`, `last_data_at`, `latency_ms` | | `data_types` | Object. Per-data-type map; each entry has `status` and `completeness_24h` (0–100) | | `active_incidents` | Integer. Count of active incidents | **`/v1/data-quality/coverage/{exchange}/{symbol}`**: `exchange` and `symbol` are path params; `from` and `to` are optional Unix-ms query bounds. | Field | Description | | - | - | | `exchange` | String. Venue-family key | | `symbol` | String. Symbol | | `data_types` | Object. Per-data-type map; each entry has `earliest`, `latest`, `total_records`, `completeness`, `historical_coverage`, `gaps`, and `cadence` | Each `gaps` entry has `start`, `end`, and `duration_minutes`; `cadence` has `median_interval_seconds`, `p95_interval_seconds`, and `sample_count`. **`/v1/data-quality/sla`**: optional `year` and `month` query params. | Field | Description | | - | - | | `period` | String. Period covered, e.g. `2026-01` | | `sla_targets` | Object. Target thresholds: `uptime`, `data_completeness`, `api_latency_p99_ms` | | `actual` | Object. Measured values plus a `*_status` (`met`/`missed`) per target | | `incidents_this_period` | Integer. Incidents in the period | | `total_downtime_minutes` | Integer. Total downtime minutes in the period | ## 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. Keep each response's `meta.request_id` too, or the `x-request-id` response header. ## Route fit | Route | Use it for, and what to store with the output | | - | - | | `/v1/data-quality/status` | Broad service and ingestion state. Store the overall status, updated time, per venue-family state, and active incident count | | `/v1/data-quality/coverage` | Venue-family and data-family coverage summary. Store the recognized venue-family key, data type, earliest/latest, and completeness | | `/v1/data-quality/coverage/{exchange}/{symbol}` | Symbol-level coverage and gaps for a window. Store the recognized venue-family key, symbol, data family, gaps, completeness, and historical coverage | | `/v1/data-quality/incidents` | Known interruptions by status, venue family, and time. Store incident IDs, severity, status, affected symbols, and start/end | | `/v1/data-quality/latency` | Service timing context and stored order-book freshness, not client WebSocket RTT. Store the measured time, venue-family latency, and data freshness lag | | `/v1/data-quality/sla` | SLA-style reporting for a period. Store the period, targets, actuals, downtime, and incident count | | `/v1/status/coverage` | Public coverage/status summary. Store the route-family and coverage summary | 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. ## Make quality a pipeline input Treat these responses as inputs to the job, not a separate monitoring view. If a window is stale or interrupted, narrow the request, delay, annotate the output, or stop; do not interpolate missing market data. A single raw request can stay simple, but anything that depends on historical accuracy should run a data-quality preflight first. [Handle gaps](/data-quality#handle-gaps) covers what to do when a window is not safe. ## Next step To combine status, freshness, and coverage into one decision before a job runs, continue to [Check one window before use](/data-quality#check-one-window-before-use). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.