Data quality routes

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). The Data-quality endpoint reference has each response body, and Data-quality operation schemas 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

Check status

Confirm the API and ingestion surfaces are healthy enough for the job.

Check coverage

Confirm venue, symbol, and data family history exists for the requested time range.

Check incidents

Look for interruptions that overlap the requested market and time window.

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.

Example

Check current system state:

curl "https://api.0xarchive.io/v1/data-quality/status" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"

A status response (shape; the values are live):

{
  "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:

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:

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

Endpoint reference

Requests and responses

Datasets

Venues

OpenAPI and schemas

Guides

Data quality routes

Preflight sequence

Example

Response fields

What to store

Route fit

Make quality a pipeline input

Next step

​Preflight sequence

​Example

​Response fields

​What to store

​Route fit

​Make quality a pipeline input

​Next step

Preflight sequence

Example

Response fields

What to store

Route fit

Make quality a pipeline input

Next step