Get liquidations
- Hyperliquid
- HIP-3
/v1/hyperliquid/liquidations/{symbol}. Volume buckets: /v1/hyperliquid/liquidations/{symbol}/volume.Request parameters
| Parameter | In | Type | Required | Description |
|---|---|---|---|---|
symbol | path | string | Yes | Trading pair symbol, e.g. BTC |
start | query | integer (ms) | No | Start time, Unix ms. Defaults to 24h ago |
end | query | integer (ms) | No | End time, Unix ms. Defaults to now |
limit | query | integer | No | Max results. Default 100, max 1000 |
cursor | query | string | No | Pagination cursor (format timestamp_tradeId) |
Response fields
Each item in thedata array:
| Field | Type | Description |
|---|---|---|
symbol | string | Trading pair symbol (coin is a deprecated alias) |
timestamp | string | Liquidation time (UTC) |
liquidated_user | string | Wallet that was liquidated |
liquidator_user | string | Liquidator (counterparty) wallet |
price | string | Price the liquidation executed at |
size | string | Size of the liquidated position |
side | string | Venue side code (A/B); use direction for close/open |
mark_price | string | Mark price at liquidation |
closed_pnl | string | Realized PnL (usually negative) |
direction | string | Label such as Close Long, Close Short |
trade_id | integer | Trade ID for this liquidation |
tx_hash | string | Blockchain transaction hash |
Raw events vs volume
Use raw liquidation event routes (/v1/hyperliquid/liquidations/{symbol} or /v1/hyperliquid/hip3/liquidations/{symbol}) when you need event-level records for audit, replay, or model input. They are heavier and may need pagination, tighter windows, and lower concurrency.
Use /volume (/v1/hyperliquid/liquidations/{symbol}/volume?interval=1h) when you need aggregate liquidation-volume buckets for dashboards or backtests that don’t inspect every event. Each bucket returns total_usd, long_usd, short_usd, count, long_count, and short_count. For high-volume dashboards and repeated backtests, start with /volume and keep raw event pulls as a narrower drill-down.
For liquidation routes that return 429, honor Retry-After when present; if it is absent, use capped exponential backoff with jitter, reduce concurrency, and keep meta.request_id or x-request-id for the failed attempts. Don’t retry unchanged after auth, access, malformed-request, or unsupported-symbol errors. Fix the request or key first.
Next call after a 429
When a raw liquidation route rate-limits, choose the next call from the workflow instead of replaying the same request.| Workflow | Safer next call |
|---|---|
| Dashboard, scan, or repeated backtest summary | /v1/hyperliquid/liquidations/{symbol}/volume?interval=1h or the matching HIP-3 /volume route |
| Event-level audit or model input | Same raw route with a smaller window, lower concurrency, and request-ID logging |
| Unclear venue family | Check Venue Coverage before switching between core and HIP-3 |
Retry-After value when present, meta.request_id or x-request-id, and the chosen next call in the job log so the retry decision is reviewable later.
Stream it live
Liquidations stream on Hyperliquid core (liquidations) and HIP-3 (hip3_liquidations) only, matching the REST coverage. Spot, HIP-4, and Lighter do not serve a liquidation stream.
Export in bulk
For event-level liquidation history as files, use theliquidations export schema ($8/GB, $25 minimum), delivered as Parquet with ZSTD compression. Build a selection in the Data Catalog; columns and coverage keys are on Export Schemas.