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

# Monitor Freshness Before Use

> Check freshness, coverage, and incidents before using 0xArchive results downstream.

Freshness checks turn market data from a raw response into a usable input. Run them before jobs that produce decisions, reports, alerts, exports, or models.

```bash theme={"theme":"github-dark"}
curl "https://api.0xarchive.io/v1/data-quality/status" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"
```

Check one market family directly when the job depends on a specific symbol:

```bash theme={"theme":"github-dark"}
curl "https://api.0xarchive.io/v1/hyperliquid/freshness/BTC" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"
```

For historical work, pair freshness with coverage over the requested window. Coverage `from` and `to` use Unix milliseconds.

```bash theme={"theme":"github-dark"}
curl "https://api.0xarchive.io/v1/data-quality/coverage/hyperliquid/BTC?from=1777593600000&to=1777680000000" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"
```

<Steps>
  <Step title="Check service status">
    Stop early if the relevant venue family is degraded for your job.
  </Step>

  <Step title="Check symbol coverage">
    Confirm the data family exists for the requested time window.
  </Step>

  <Step title="Check incidents">
    Inspect whether a known interruption overlaps the window.
  </Step>

  <Step title="Attach the check to the job">
    Store the quality-check request ID next to the data request ID.
  </Step>
</Steps>

<CardGroup cols={2}>
  <Card title="Data Quality" icon="activity" href="/data-quality">
    Freshness, coverage, incidents, latency, and SLA routes.
  </Card>

  <Card title="Reliability and gaps" icon="shield-check" href="/guides/reliability-and-gaps">
    Build failure behavior for missing or delayed data.
  </Card>
</CardGroup>

## Freshness Tolerance

Define tolerance before the job runs. A dashboard may tolerate a small delay, a backtest export may tolerate an annotated historical gap, and an alerting system may need to stop when order-book freshness is stale. The API can expose the state, but the application owns the policy decision.

| Job                       | Suggested policy shape                                                               |
| ------------------------- | ------------------------------------------------------------------------------------ |
| Dashboard tile            | Show the latest value with a visible stale state when lag exceeds the page threshold |
| Alerting job              | Stop or suppress alerts when the required data family is stale                       |
| Backtest or research pull | Annotate or reject the output when coverage gaps overlap the window                  |
| Export workflow           | Check coverage and incidents before purchase, delivery, or warehouse load            |
| Agent answer              | Include freshness, coverage, and incident state before drawing a conclusion          |

## Fields To Read

Symbol freshness responses expose the venue family, symbol, measurement time, and per-data-family freshness objects. For Hyperliquid core, read `data.measured_at`, then compare the relevant field such as `data.orderbook.lag_ms`, `data.trades.lag_ms`, `data.funding.lag_ms`, `data.open_interest.lag_ms`, or `data.liquidations.lag_ms` against the job threshold. The matching `last_updated` timestamp tells reviewers what market-data point the lag came from.

## What To Log

Log the freshness route, measured timestamp, relevant venue family, symbol, data family, lag, last-updated value, and `request_id`. Store that next to the downstream output so a chart, model, or report can explain why it used or rejected a window.

## Pair With Coverage

Freshness answers how current a data family is. Coverage answers whether the data family exists for the requested market and window. Use both when the job depends on historical correctness.

Coverage should run before large historical jobs, model features, export orders, and backtests. Incidents should run when a known interruption could overlap the requested market or time range. Latency and SLA routes are useful for dashboards and service review, but they should not replace symbol-level freshness when the downstream job depends on one market.

## Review Rule

A freshness check is useful only if the application has a threshold. Write down the maximum acceptable lag per job, then compare the API response to that threshold. Without a threshold, the check becomes a log line instead of a decision.

## Next Step

Pair freshness checks with [Data Quality REST API](/rest-api/data-quality) and [Reliability And Gaps](/guides/reliability-and-gaps) before a job produces durable output.