Data quality routes live underDocumentation Index
Fetch the complete documentation index at: https://docs.0xarchive.io/llms.txt
Use this file to discover all available pages before exploring further.
/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
Example
Check current system state: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:
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 requiremeta.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 |
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.Data quality guide
Apply freshness and coverage checks to real workflows.
Reliability guide
Design retry and fallback behavior around gaps.