Evaluate a market data API

Outcome

Produce a decision record for one market-data job that says whether the named API can return the required record, with the route and evidence needed to repeat the decision.

Prerequisites

Name the record and grain: snapshot, trade, candle, funding, open interest, liquidation, order event, replay, or export.
Name one venue family, symbol, and bounded time window.
Define the required response fields, freshness tolerance, and downstream use before comparing providers.
Separate market-data retrieval from account state and execution. Those account and execution behaviors are outside 0xArchive’s market-data scope.

Inputs

Field	Example
Job	One-hour Hyperliquid core BTC trade pull
Route	`/v1/hyperliquid/trades/BTC`
Window	`start=1767225600000`, `end=1767229200000`
Response needs	Trade rows, cursor behavior, and request IDs
Quality gate	Coverage, freshness, and incident state for the same family and window
Decision	Use, hold for more evidence, or route to another product category

Steps

State the required result

Write the venue family, symbol, data family, window, required fields, freshness tolerance, and intended use in one short record.

Inspect the exact contract

Use OpenAPI and the matching endpoint page to check route, authentication, parameter types, response shape, pagination, errors, and request-ID location.

Run one bounded request

curl -sS "https://api.0xarchive.io/v1/hyperliquid/trades/BTC?start=1767225600000&end=1767229200000&limit=1000" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"

Check quality and capacity

Compare the response with the selected symbol’s coverage and freshness state. Check the current account response and limits before turning one call into a recurring or wider job.

Expected state

The record contains a route-backed answer: the response has the required row shape, the requested window is represented by the returned data or an explicit empty result, the request ID is saved, and the quality decision is named. A route existing in OpenAPI is not evidence of every symbol, date, or schema window.

Verification

Score the selected API on the exact job, not on a product inventory:

Check	Passing observation
Route and auth	Exact operation and key requirement are written down
Parameters	Types, bounds, and cursor behavior match the endpoint page
Response	Required fields and request-ID location are observable
Quality	Coverage, freshness, and incident state are checked for the selected family and window
Capacity	Account rate, concurrency, credit, and request-span constraints are recorded
Rights	The downstream transformation and source-exposure decision is recorded

For this decision, Internal research and Parquet exports are permitted. Materially transformed derived products and ordinary customer-facing use are permitted when they do not expose or allow reconstruction of original records. Benchmarks, indices, financial products, standalone or substitute market-data products, raw redistribution, and white-label or OEM delivery require prior written permission.

Failure and recovery

400: fix the named parameter or time window before another call.
401: repair the key source or header.
403: inspect the exact endpoint/account/key response. Do not infer a route or schema gate from the status.
404: recheck family, symbol, and route namespace.
429: honor Retry-After when present, otherwise use capped exponential backoff with jitter and reduce concurrency.
Missing coverage or stale data: hold the decision, narrow the job, or mark the output. Do not replace missing rows with synthetic data.

Saved run metadata

{
  "job": "btc_trade_api_fit_001",
  "venue_family": "hyperliquid_core",
  "symbol": "BTC",
  "data_family": "trades",
  "route": "/v1/hyperliquid/trades/BTC",
  "query": {
    "start": 1767225600000,
    "end": 1767229200000,
    "limit": 1000
  },
  "request_ids": ["00000000-0000-0000-0000-000000000000"],
  "quality_source": "record the exact coverage, freshness, and incident responses",
  "decision": "record use, hold, or route elsewhere"
}

The zero UUID is a shape placeholder only. Replace it with the returned UUID and keep the API key out of the record.

Next task

Use Historical market data to implement the selected pull, or Point-In-Time Backtesting when the result feeds a reproducible research run.

​Outcome

​Prerequisites

​Inputs

​Steps

​Expected state

​Verification

​Failure and recovery

​Saved run metadata

​Next task