Datasets

Exactly what history exists — coverage windows, releases, gaps.

GET/context/datasets

The honest catalog: per venue and pair, what data exists, from when, in which release.

Query parameters

Response — 200

{
  "datasets": [
    {
      "venue": "lighter",
      "symbol": "SOL-PERP.LIGHTER",
      "tables": {
        "candles_1m": { "from": "2025-03-11T08:00:00Z", "to": "2026-07-28T01:00:00Z", "rows": 721440 },
        "mark_candles_1m": { "from": "2025-03-11T08:00:00Z", "to": "2026-07-28T01:00:00Z", "rows": 721440 },
        "funding_1h": { "from": "2025-03-11T08:00:00Z", "to": "2026-07-28T01:00:00Z", "rows": 12024 }
      },
      "release": "rel_2026-07-27T02",
      "gaps": [
        { "table": "funding_1h", "from": "2025-01-21T14:00:00Z", "to": "2025-01-21T15:00:00Z" }
      ]
    }
  ]
}

How to use it

Before a backtest: check the coverage window. POST /runtime/backtests rejects a range outside coverage with data_unavailable and points here; checking first saves the round-trip.

For reproducibility: the release ID names an immutable snapshot. Backtest results record which release they ran on, so a result can always be traced to exact input data — re-running against the same release is deterministic on the data side.

For honesty: gaps are venue-side holes (their API never served the interval). We record them; we don't bridge them. A backtest spanning a gap gets the gap too — the same reality live trading would have faced.

Coverage at a glance (design targets)

Honesty note: the immutability and gap guarantees on this page are the contract of the release model, and today two of four venues have that machinery. Until Hyperliquid and Binance move onto it, their rows report release: null and no gaps claim — absence of a gaps array means "not audited", never "no gaps".