Liquidations

GET/v1/cryptodata/market-intelligence/liquidations

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.

# 1. No key, no payment: the gateway answers 402 with the price
curl -i "https://api.realtimeapi.ai/v1/cryptodata/market-intelligence/liquidations"

# 2. Pay: retry with a signed x402 payment (any x402 client builds this header)
curl "https://api.realtimeapi.ai/v1/cryptodata/market-intelligence/liquidations" -H "PAYMENT-SIGNATURE: $X402_PAYMENT"

// npm i @x402/fetch @x402/core @x402/evm viem
import { wrapFetchWithPayment } from "@x402/fetch";
import { x402Client } from "@x402/core/client";
import { ExactEvmScheme } from "@x402/evm/exact/client";
import { privateKeyToAccount } from "viem/accounts";

const client = x402Client.fromConfig({ schemes: [{ network: "eip155:8453", client: new ExactEvmScheme(privateKeyToAccount(PRIVATE_KEY)) }] });
const pay = wrapFetchWithPayment(fetch, client);
const data = await (await pay("https://api.realtimeapi.ai/v1/cryptodata/market-intelligence/liquidations")).json();
console.log(data);

# pip install x402 eth-account requests
from eth_account import Account
from x402.clients.requests import x402_requests

session = x402_requests(Account.from_key(PRIVATE_KEY))
print(session.get("https://api.realtimeapi.ai/v1/cryptodata/market-intelligence/liquidations").json())

curl "https://api.realtimeapi.ai/v1/cryptodata/market-intelligence/liquidations" -H "X-API-Key: $RTAPI_KEY"