Quality routes
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 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, and examples of each response are on Data quality routes.
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.Latest data
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
1
Check coverage for the same bounds
data_types; trades are reported as fills. Use exactly the bounds of the request the job will make.2
Find incidents that overlap the window
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 asvenue_family, are your own names, and only the route values are 0xArchive paths.
Handle gaps
A gap is any condition that makes a payload unsafe for the job:
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 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, 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.