Query API
SQL over the complete archive (every trade, order event, and book delta since launch) without running your own warehouse. POST a query, get rows back as JSON (or CSV via Accept: text/csv). Same schema as the live streams, so a query you debug here deploys against the feed unchanged.
Endpoint
- Endpoint
- https://data.hyperliquidrpc.com/query
- Protocol
- HTTPS POST, SQL string body
- Auth
- API key in the x-api-key header
- Results
- JSON rows (default) or CSV
curl https://data.hyperliquidrpc.com/query \ -H 'x-api-key: YOUR_KEY' \ -d "SELECT count() FROM trades WHERE coin = 'BTC' AND block_time > now() - 86400"The dialect is the same SQL the canonical examples use. ClickHouse-style functions like toStartOfMinute, argMin/argMax, and countIf work as written. Tables and columns are documented in Schemas; financial columns (px, sz, closed_pnl, fee) are stored with exact decimal precision.
Recipe: OHLCV from raw trades
Candles computed directly from the fill tape: one row per minute for the last hour of BTC. The ready-made ohlcv_1s/1m/1h/1d datasets hold the same shape precomputed; build from trades when you need a custom interval or filter (e.g. excluding liquidation fills).
SELECT toStartOfMinute(block_time) m, argMin(px, block_time) o, max(px) h, min(px) l, argMax(px, block_time) c, sum(sz) volFROM tradesWHERE coin = 'BTC' AND block_time > now() - 3600GROUP BY mORDER BY mIllustrative rows in the real shape. Prices are exact decimal strings, volume is base-asset size.
Recipe: wallet PnL
Every fill carries the trader's wallet, realized PnL, fees, and notional, so copy-trading research is a GROUP BY user away. Thirty-day realized PnL, volume, and win rate for one address:
SELECT user, sum(closed_pnl) realized_pnl, sum(notional) volume, countIf(closed_pnl > 0) / countIf(closed_pnl != 0) win_rate, count() fillsFROM tradesWHERE user = '0x7c4ee0c0c5d3ab91f7f0f3c2a3d6b18452e9a3f9' AND block_time > now() - 86400 * 30GROUP BY userDrop the WHERE user filter and add ORDER BY realized_pnl DESC LIMIT 100 for a leaderboard. The wallet_pnl derived dataset precomputes this per address.
Recipe: liquidation history
The liquidations derived dataset has one row per liquidation: victim wallet, size, execution price, and mark price at the time. The largest ETH liquidations of the past week:
SELECT block_time, coin, victim, sz, px, mark_pxFROM liquidationsWHERE coin = 'ETH' AND block_time > now() - 86400 * 7ORDER BY px * sz DESCLIMIT 20The same events are on the live events stream. Backtest the query here, then subscribe with the identical field names.
Recipe: funding series
The funding derived dataset is the funding-rate time series per market, the input for basis and carry studies. BTC over the last week:
SELECT block_time, funding_rateFROM fundingWHERE coin = 'BTC' AND block_time > now() - 86400 * 7ORDER BY block_timePer-wallet funding payments (amount, position size, rate) live in the events dataset with type = 'funding'.
Query guidance
- Always constrain
block_time(andcoinwhere you can).book_updatesalone holds 1B+ rows, and unbounded scans will hit your plan's query limits. - Treat financial columns as decimals end to end; casting
pxorclosed_pnlto float reintroduces exactly the rounding error the archive exists to avoid. - Results are capped per response; page long extracts with
LIMIT … OFFSET, or use bulk exports for anything that looks like a full-dataset pull. - For sustained interactive analytics, ask about direct read-only database access.