Monitor Freshness Before Use

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.

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:

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.

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

Check service status

Stop early if the relevant venue family is degraded for your job.

Check symbol coverage

Confirm the data family exists for the requested time window.

Check incidents

Inspect whether a known interruption overlaps the window.

Attach the check to the job

Store the quality-check request ID next to the data request ID.

Data Quality

Freshness, coverage, incidents, latency, and SLA routes.

Reliability and gaps

Build failure behavior for missing or delayed data.

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 and Reliability And Gaps before a job produces durable output.

Implementation guides

Documentation Index

Data Quality

Reliability and gaps

​Freshness Tolerance

​Fields To Read

​What To Log

​Pair With Coverage

​Review Rule

​Next Step