Data Quality REST API

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 Endpoint Reference as the schema source for each response body. For public discovery surfaces, /v1/status/coverage exposes a System-route coverage summary in the same OpenAPI contract. Use /v1/data-quality/* when a workflow needs the deeper data-quality resource bodies. Some data-quality routes keep the path or query parameter name exchange for API compatibility. Treat that value as the supported venue-family key for the route. It is not a claim that every exchange is covered.

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):

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

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. These are resource-specific bodies (no success/data/meta envelope); parse them from the REST reference. Check one symbol and window:

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:

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

Response fields

These routes return resource-specific bodies (the no-envelope note above applies). The main shapes: /v1/data-quality/status

Field	Type	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	Type	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	Type	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. 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 venue-family state, active incident count
`/v1/data-quality/coverage`	Venue-family and data-family coverage summary	supported venue-family key, data type, earliest/latest, completeness
`/v1/data-quality/coverage/{exchange}/{symbol}`	Symbol-level coverage and gaps for a window	supported venue-family key, symbol, data family, gaps, completeness, historical coverage
`/v1/data-quality/incidents`	Known interruptions by status, venue family, and time	incident IDs, severity, status, affected symbols, start/end
`/v1/data-quality/latency`	Current API, WebSocket, and freshness latency	measured time, venue-family latency, data freshness lag
`/v1/data-quality/sla`	SLA-style reporting for a period	period, targets, actuals, downtime, incident count
`/v1/status/coverage`	Public coverage/status summary	route-family and coverage summary for discovery surfaces

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 decision inputs, not an optional monitoring sidebar. 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. Before generating historical pulls, alerts, exports, dashboards, or model inputs, add a data-quality preflight. A single raw request can stay simple; anything that depends on historical accuracy should make quality state part of the implementation.

Data quality guide

Apply freshness and coverage checks to real workflows.

Reliability guide

Design retry and fallback behavior around gaps.

​Preflight Sequence

​Example

​Response fields

​What To Store

​Route Fit

​Make Quality A Pipeline Input