Does Hyperliquid have a liquidation API?
No. If you are looking for a hyperliquid liquidation data api in the venue's own documentation you will not find one. The documented info request types cover mids, order books, candles, open orders, funding history and per-address fills; none of them is a liquidation feed, and the only liquidation reference in the order-status table is liquidatedCanceled, an order cancelled because its owner was liquidated. The public trades stream, which many trackers subscribe to, carries no liquidation flag at all, which is why our own trade tape and liquidation tape are separate feeds.
That answers the question most people are actually asking, which is "why does my dashboard vendor's Hyperliquid liquidation number disagree with another vendor's?" Because neither is reading a feed. Each is reconstructing liquidations from something lower level, and the something differs.
What Hyperliquid does guarantee is that a liquidation is a fill. When an account crosses its maintenance margin the position is closed by a market order against the book, or, when the book cannot absorb it, by the liquidator vault as a backstop. Either way the result is a fill with a price, a size, a time and a counterparty that exists in the chain's fill data, with the liquidated account and the method attached. That is where a complete tape has to come from.
Why vendor answers disagree
Reading around, three kinds of claim appear:
| Claim | What is actually behind it | Consequence |
|---|---|---|
| "Hyperliquid has no public liquidation or leaderboard API" | A correct reading of the documented info types | Any feed is derived; ask the vendor from what |
| "Subscribe to trades and infer liquidations from large aggressive fills" | The public trades stream, which has no liquidation marker | Heuristic. Misses small liquidations, mislabels large voluntary market orders |
| "We serve exact Hyperliquid liquidations" | Node fill data, where a liquidation fill carries the liquidated user, the mark price and the method | Exact per fill; coverage starts whenever that vendor started capturing |
The third is what we do, and the honest part is the last column. A per-fill tape is only as deep as the day someone started writing it down, because the venue does not serve the back catalogue. Ours is described below with its real start dates, including a gap.
The per-fill tape: /backtesting/hl-liquidations
GET /api/v1/backtesting/hl-liquidations is every exact liquidation fill, market and backstop, across the full Hyperliquid perp universe, sourced from node fill data. Each row is one fill:
time(ms) andtid, the fill id, which together are the row's primary keycoinandsymbolside, the liquidated position's sidepx,szandusd, the fill price, size and notionalmethod, how the position was closed (a market liquidation against the book, or a backstop fill)mark_px, the mark at the timeliquidated_userandhash, the account that was liquidated and the transaction
curl "https://cryptodataapi.com/api/v1/backtesting/hl-liquidations?coin=ETH&start=2026-10-10T00:00:00Z&end=2026-10-11T00:00:00Z&limit=10000" \
-H "X-API-Key: cdk_live_your_key"An example row (illustrative values, real field names):
{
"time": 1791683461204, "tid": 918234021117, "coin": "ETH", "symbol": "ETH",
"side": "long", "px": 3842.1, "sz": 12.4, "usd": 47642.04,
"method": "market", "mark_px": 3843.0,
"liquidated_user": "0x6f1c...e2a9", "hash": "0x9b0d...41c7"
}Page with cursor, never with start = last.time + 1. One liquidation order sweeping N book levels is N rows at a single millisecond. Rows are ordered by the full (time, tid) key and next_cursor resumes exactly there; the timestamp-plus-one pattern silently drops the siblings that fell past a page boundary, and on a cascade that is precisely the data you came for.
Coverage, honestly: live capture began 2026-07-23, and coverage.local_first in the response is authoritative for the coin you asked about. The hl_liquidations daily Parquet archive, one file per day for all coins via /backtesting/archives, additionally holds a pilot backfill from 2026-04-24 to 2026-05-05. No per-fill tape exists anywhere for 2026-05-06 to 2026-07-22. A window before local retention returns an empty data with coverage.archive_hint set, never silently. The endpoint is Pro (Pro Plus included) since 2026-09-07; the archive files stay Pro Plus, or $1.00 per day-file over x402.
Bars for the burst clock: /backtesting/hl-liquidation-bars
A cascade is a rate, and a per-fill tape makes you compute the rate yourself. GET /api/v1/backtesting/hl-liquidation-bars does the bucketing from the same fills: one row per closed UTC-aligned interval bucket of 5m, 15m (default) or 1h, with long_usd and short_usd (notional liquidated on each side), total_usd, n_long and n_short (fill counts) and max_fill_usd. Buckets with no fills are not returned, and start and end are floored to the grid so the bucket containing now is never served; its fills are still forming on the tape.
curl "https://cryptodataapi.com/api/v1/backtesting/hl-liquidation-bars?coin=BTC&interval=15m&start=2026-09-01&end=2026-09-08" \
-H "X-API-Key: cdk_live_your_key"{
"coin": "BTC", "interval": "15m", "count": 412,
"data": [{ "time": 1788220800000, "coin": "BTC", "long_usd": 1834210.5, "short_usd": 96120.0,
"total_usd": 1930330.5, "n_long": 217, "n_short": 9, "max_fill_usd": 412000.0 }, ...],
"audit": { "fills": "/api/v1/backtesting/hl-liquidations",
"how": "same coin, start=row.time, end=row.time+900000 - the exact fills that summed to the bar" },
"grain": { "kind": "bar", "cadence": "15m", "sum_ok": true, ... },
"coverage": { "local_first": 1784788771678, "local_last": 1789166399000, "archive_hint": null },
"next_cursor": null, "has_more": false
}Omit coin for one market-wide row per bucket (coin is null, window up to 31 days) or pass a coin or comma list of up to 25 for per-coin rows (window up to 93 days); past the cap you get 400 range_too_large. Every bar is auditable: the audit block names the /hl-liquidations call whose fills sum to it. Join to /hyperliquid/candles or /backtesting/klines?exchange=hyperliquid on time for a same-bar or next-bar test. Same tier as the tape.
Live events and the rolling 24h board
Two more surfaces carry Hyperliquid liquidations, and they answer different questions from the tape.
Live: GET /api/v1/stream?types=liquidation is a Server-Sent Events feed. Each liquidation event has the common envelope (id, ts, recv_ts, type, venue, symbol) plus side, the liquidated position's side, and usd; Hyperliquid events also carry px and sz. Venues are OKX, Bybit and Hyperliquid, from $250 up. Pro and Pro Plus; a Free key reads the same events from /stream/recent as JSON. The feed is covered in its own post, Real-Time Crypto Liquidation Feed Over SSE.
The board: GET /api/v1/market-intelligence/liquidations returns one row per coin with liquidation_usd_24h, liquidation_usd_12h, _4h and _1h, each split into long_liquidation_usd_* and short_liquidation_usd_*, plus count (liquidation events in the 24h window), source (the contributing venues, for example hyperliquid+okx+bybit) and liq_1h_vs_7d_median, the last hour's notional divided by the coin's median hourly notional over the trailing seven days, computed from the exact Hyperliquid fill tape. 3.0 means three times a normal hour for this coin; it is null while the tape holds under 24 hours for the coin or the median is zero.
The board's top-level grain says kind: "rolling_window", is_cumulative: true, sum_ok: false. Every liquidation_usd_* field is a trailing-window level. Never sum or difference successive polls to recover a burst; that is what the bars are for. Any key can read it, or $0.01 per call over x402 with no key. The 24h totals exclude Binance, which geo-blocks its liquidation stream from our infrastructure, so they run below a true all-exchange number; the Hyperliquid portion is exact.
Four surfaces compared
| Endpoint | One row is | Use it for | Sum across rows? | Tier |
|---|---|---|---|---|
/backtesting/hl-liquidations | One exact fill | Forensics, per-account study, auditing any aggregate | Yes | Pro |
/backtesting/hl-liquidation-bars | One closed 5m/15m/1h bucket | Cascade detection, same-bar backtests | Yes (sum_ok: true) | Pro |
/stream type liquidation | One live event | Reacting in seconds | Yes, within your own window | Pro |
/market-intelligence/liquidations | A rolling 24h level per coin | Ranking coins by stress right now | No (sum_ok: false) | Any key, or x402 |
The split that trips people up is the last column. The tape, the bars and the stream are flow; the board is a level. Differencing the board between two polls does not give you the flow in between, because the window slides at both ends.
How to use this in a bot (and when not to)
For a risk gate on an open position, subscribe to the stream filtered to your coins with a min_usd floor, and treat one-sided flow on the side you hold as a reason to tighten. side names the position being closed, so a burst of short liquidations is forced buying.
For a backtest, pull hl-liquidation-bars at the interval your strategy trades, join on time to the candle series, and act at the next bar's open. Every value in a bar was observable by that bar's close, so there is no lookahead in the join.
For a study of who gets liquidated, the tape's liquidated_user and method let you group by account and separate market liquidations from backstop fills. Nothing else exposes that.
Do not extend any of this before 2026-07-23 expecting continuity. The pilot window in April and May 2026 is real and the gap after it is real. Do not infer liquidations from the public trades stream and call them exact; the stream has no flag. And do not sum the 24h board.
A free key reads the board today; the tape and bars are on Pro at $29 a month, and the 24-hour Pro trial granted on email verification reaches them. Details at /pricing and the full reference at /docs. For the public teaser of the newest fills with no key, see /hl-liquidations.
Frequently asked questions
Does Hyperliquid have a public liquidation API?
No. The documented info request types include no liquidation feed and the public trades stream carries no liquidation flag. Liquidations are fills, and a complete tape has to be reconstructed from node fill data.
What fields does the Hyperliquid liquidation tape carry?
Each row of /api/v1/backtesting/hl-liquidations is one exact fill: time, tid, coin, symbol, side (the liquidated position's side), px, sz, usd, method, mark_px, liquidated_user and hash.
How far back does Hyperliquid liquidation history go?
Live per-fill capture began 2026-07-23, and the hl_liquidations archive also holds a pilot backfill from 2026-04-24 to 2026-05-05. No per-fill tape exists anywhere for 2026-05-06 to 2026-07-22.
Can I sum the 24-hour liquidation totals to get flow over time?
No. /market-intelligence/liquidations is a rolling 24h level with grain.sum_ok false. Use /backtesting/hl-liquidation-bars, which sums exact fills into closed 5m, 15m or 1h buckets.
