> ## 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 and freshness > Check whether a market-data window is complete, current, and clear of incidents before a backtest, alert, export, or model depends on it. Check whether a window of market data is safe to use before a backtest, alert, export or model depends on it: is it complete, is it current, and did an incident touch it. The API reports what it observed; your job sets the tolerance and makes the decision. To check whether the service itself is up, use [Status monitoring](/status-monitoring). ## Quality routes | Route | What it tells you | | - | - | | `/v1/data-quality/coverage/{exchange}/{symbol}` | Windows, completeness, gaps, and empirical cadence for one symbol, by data type | | `/v1/data-quality/coverage` and `/v1/data-quality/coverage/{exchange}` | A coarse summary by venue and data type; use the symbol route for one market | | `/v1/data-quality/incidents` | Known current and past interruptions, with the data types and symbols they affected | | `/v1/hyperliquid/freshness/{symbol}` and the matching Spot, HIP-3, HIP-4, and Lighter routes | How far each data type for one symbol lags behind now | | `/v1/data-quality/positions` | Snapshot age and how far the change log is built and finalized, for account positions | The `exchange` value in these routes is a recognized venue-family key: `hyperliquid`, `spot`, `hip3`, `hip4`, `lighter`, or `rh-lighter`. It is not a claim that every exchange is covered. By default, the data-quality routes return their own fields at the top level, next to `success: true` and `meta`, instead of inside `data`; the [version header](/conventions#versioning) switches them to the standard envelope. Every route in the table returns `meta.request_id` on success. An error body carries a top-level `request_id` instead, and the `x-request-id` response header carries the ID in both cases. Exact fields are in the [Data-quality endpoint reference](/api-reference/data-quality), and examples of each response are on [Data quality routes](/rest-api/data-quality). ## Check one window before use Two questions need different checks. Is the latest data current enough? That matters for alerts, dashboards and live decisions. Is a historical window complete? That matters for backtests, exports and research. Run the checks that match the job, and set the maximum lag and the gaps it accepts before you start. The examples use Hyperliquid core BTC trades and a window that every plan's history reaches, including Free's most recent 30 days: 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 ``` ### Latest data ```bash theme={"theme":"github-dark"} curl -sS "https://api.0xarchive.io/v1/hyperliquid/freshness/BTC" \ -H "X-API-Key: $OXARCHIVE_API_KEY" ``` For trades, read `data.measured_at` and `data.trades.lag_ms` with its `last_updated` value. Each data type reports its own lag. Current lag matters when the job uses the latest data, or when the window ends so recently that it may still be filling in: if `END` is later than the data type's `last_updated`, the end of the window is not ingested yet. A window that closed before `last_updated` is not affected by today's lag; judge it by coverage and incidents instead. ### A historical window ```bash theme={"theme":"github-dark"} curl -sS "https://api.0xarchive.io/v1/data-quality/coverage/hyperliquid/BTC?from=$START&to=$END" \ -H "X-API-Key: $OXARCHIVE_API_KEY" ``` Read the data type's completeness, gaps, and cadence under `data_types`; trades are reported as `fills`. Use exactly the bounds of the request the job will make. ```bash theme={"theme":"github-dark"} curl -sS "https://api.0xarchive.io/v1/data-quality/incidents?exchange=hyperliquid&limit=100" \ -H "X-API-Key: $OXARCHIVE_API_KEY" ``` Keep each incident whose `started_at` is before `END` and whose `resolved_at` is empty or after `START`, then check its `data_types` and `symbols_affected`. The `since` parameter filters by start time only, so `since=$START` alone would miss an incident that began before the window and was still open during it. Page with `offset` when `pagination.total` is larger than the page. ### Decide and record Mark the window complete only when coverage, incidents and, where they apply, freshness meet the job's policy. Otherwise mark it stale, partial, interrupted, skipped or failed with a reason, then continue, narrow, delay, retry, rebuild or stop. Never relabel a quality failure as complete, and never fill a gap with synthetic rows. The job defines the tolerance. A stale latest quote may be acceptable for a UI smoke test and unacceptable for an alert. An alert on the latest order book cares about order-book freshness; a funding study cares about funding completeness for its window; a backtest on Spot trades checks Spot coverage and incidents for its window. Store the decision beside the output, not only in logs. The record is yours: its keys and labels, such as `venue_family`, are your own names, and only the route values are 0xArchive paths. ```json theme={"theme":"github-dark"} { "run": "btc-trades-quality-001", "venue_family": "hyperliquid_core", "symbol": "BTC", "data_family": "trades", "window": { "from": "START in Unix ms", "to": "END in Unix ms" }, "freshness_route": "/v1/hyperliquid/freshness/BTC", "coverage_route": "/v1/data-quality/coverage/hyperliquid/BTC", "incidents_route": "/v1/data-quality/incidents?exchange=hyperliquid", "overlapping_incidents": [], "data_route": "/v1/hyperliquid/trades/BTC", "request_ids": ["00000000-0000-0000-0000-000000000000"], "quality_state": "the application's decision: complete | stale | partial | interrupted | skipped | failed", "action": "continue | narrow | delay | retry | rebuild | stop", "output": "./artifacts/btc-trades-quality-001.json" } ``` The zero UUID is a placeholder for the shape. Replace it with the UUID each route returns. ## Handle gaps A gap is any condition that makes a payload unsafe for the job: | Gap | How it appears and what to do | | - | - | | Freshness lag | Latest ingestion is outside tolerance. Delay, mark stale, or stop. | | Coverage gap | The venue, symbol, data type or window is not available. Skip or narrow the window; do not add synthetic rows. | | Incident window | A known interruption overlaps the job window. Record the incident and mark the affected output. | | Replay gap | WebSocket replay emits `gap_detected`. Restart from a documented checkpoint or stop reconstruction. | | Route mismatch | The symbol belongs to another market type. Correct the route before collecting data. | For local order-book state, discard unsafe state and resync from a checkpoint before applying more ordered diffs. For REST history, rerun only the smallest window that contains the issue. Resume replay or historical pulls from a known safe checkpoint, not from whatever local state remains. Some apparent gaps are routing mistakes. A HIP-4 probability read as a USD price, a HIP-3 symbol with its builder prefix stripped, or a Spot pair sent to the core namespace can all look like missing or broken data. Check the namespace on [Venues and market types](/core-concepts/venue-taxonomy) first. A `429`, exhausted credits or consumer lag is a capacity condition, not a data gap. Handle it by the rule in [When you reach a limit](/rate-limits#when-you-reach-a-limit), which stops on exhausted credits and retries a rate limit after its wait, and record it separately from coverage or freshness. For a `5xx` or timeout, retry within a finite budget, then check [Status monitoring](/status-monitoring). ## Next step Run these checks from the job itself, whether it is a backtest, an alert, an export, or a model, with the requests and example responses on [Data quality routes](/rest-api/data-quality). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.