/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 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
1
Check status
Confirm the API and ingestion surfaces are healthy enough for the job.
2
Check coverage
Confirm venue, symbol, and data family history exists for the requested time range.
3
Check incidents
Look for interruptions that overlap the requested market and time window.
4
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: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:
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:
Response fields
These routes return resource-specific bodies (the no-envelope note above applies). The main shapes:/v1/data-quality/status
/v1/data-quality/coverage/{exchange}/{symbol}: exchange and symbol are path params; from and to are optional Unix-ms query bounds.
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.
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
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.