---
title: "Liquidations"
method: GET
path: "/api/v1/market-intelligence/liquidations"
tags: ["Market Intelligence"]
---

# Liquidations

`GET /api/v1/market-intelligence/liquidations`

## Request

- Base URL: `https://cryptodataapi.com`
- URL: `https://cryptodataapi.com/api/v1/market-intelligence/liquidations`
- Auth: API key in header `X-API-Key`

Realized-liquidation data (long/short USD over 1h/4h/12h/24h windows).
Defaults to Hyperliquid perps coins only.

**Coverage:** totals aggregate our configured realized-liquidation venue
feeds (OKX + Bybit + Hyperliquid where armed; the HL contribution is exact
per-fill capture) — see the ``coverage`` field on the response. **Binance,
the largest venue, geo-blocks its liquidation stream from our infrastructure
(no REST fallback), so these figures run below a true all-exchange total.**

**Filter semantics:** ``exchange=`` is a **coin-set filter**, not an
exchange-data filter. With ``exchange=hyperliquid`` you get the coins
listed on Hyperliquid, but the liquidation values inside each entry are the
venue-subset totals above. For Hyperliquid's own per-asset trading data use
``/daily/hyperliquid``.

**AsterDEX coverage:** With ``exchange=asterdex`` the response is the union
of (a) CoinGlass cross-exchange aggregate rows whose symbol is also listed
on AsterDEX and (b) AsterDEX venue-native rows (``source: "asterdex"``)
for AsterDEX-only symbols (e.g. LAB, ASTEROID). Native rows depend on
AsterDEX's force-order feed, which is intermittently disabled upstream;
when unavailable, only the CoinGlass-aggregate rows are returned.

``as_of`` (unix seconds) is when the liquidation snapshot behind ``data``
was last refreshed. Each row also carries ``liq_1h_vs_7d_median``
``{long, short, total, hours_7d}``: the trailing hour's liquidated notional
over the **median hourly notional of the prior 7 days** for that coin
(1.0 = a normal hour), computed from the exact Hyperliquid fill tape on
both sides of the ratio — see ``baseline`` for the exact definition. Null
per side when the 7d median is zero, per row when fewer than 24 hours of
tape exist, and for every row on a box without the backtesting archive.

**Row grain:** each row's USD fields are trailing-window LEVELS (see
``grain``: ``kind: rolling_window``, ``sum_ok: false``) — polling this every
few minutes and summing or differencing the answers double-counts. For
incremental flow use the Pro ``/backtesting/hl-liquidation-bars``, built from
the Hyperliquid fill tape. ``count`` is the number of liquidation events in
the 24h window and ``source`` the venues they came from (``row_count_meaning``).

**Order:** rows are sorted by ``liquidation_usd_24h``, largest first, so
``limit`` keeps the coins with the most liquidated notional. AsterDEX-native
rows (``exchange=asterdex``) follow the aggregate rows.

The free tier is scoped to BTC; full-universe coverage is Pro and Pro Plus.

## Query parameters

- `symbol` string: Filter to a single coin (e.g. BTC)
- `exchange` string: Filter to coins on exchange: hyperliquid, binance_spot, asterdex, or all
- `type` string: Instrument type — currently a no-op reserved for future filtering; only perps data is returned
- `limit` integer: Max coins to return (default 250)

## Response `200`

Successful Response

- MarketIntelligenceLiquidationsResponse: Liquidation rows + a coverage descriptor. ``coverage`` states which venue feeds the totals aggregate and that Binance (the largest venue) is excluded — so consumers know these run under a true all-exchange number rather than mistaking the subset for the full market. ``as_of`` is the unix-seconds refresh time of the snapshot behind ``data``. ``baseline`` describes the per-row ``liq_1h_vs_7d_median`` ratio block (source, window, and what null means).
  - `data` unknown, required
  - `as_of` integer, nullable: Unix seconds the liquidation snapshot was refreshed
  - `coverage` object, nullable
  - `baseline` object, nullable: Definition of the per-row liq_1h_vs_7d_median ratios
  - `grain` object, nullable: What a row's USD fields ARE: rolling trailing-window levels (kind=rolling_window, sum_ok=false) — never sum or difference successive polls
  - `row_count_meaning` string, nullable: What each row's `count` counts (liquidation events in the 24h window)

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/cryptodataapi/apis/crypto-data-api.md) · [All operations](https://skmtc.dev/cryptodataapi/apis/crypto-data-api/llms.txt) · [OpenAPI document](https://skmtc.dev/cryptodataapi/apis/crypto-data-api/revisions/8628b754ca81?raw)