/liquidations

GET https://data.vike.io/v1/hyperliquid/liquidations

Realized liquidation fills — what actually got liquidated.

cURL

# the most recent forced closes across the venue
curl -s "https://data.vike.io/v1/hyperliquid/liquidations?limit=3" \
  -H "X-API-KEY: $VIKE_API_KEY"

# longs being liquidated on BTC (direction is the side that was closed, so price fell)
curl -s "https://data.vike.io/v1/hyperliquid/liquidations?coin=BTC&direction=long&limit=100" \
  -H "X-API-KEY: $VIKE_API_KEY"

# next page of the call just above: NEXT is its nextCursor, passed back verbatim
curl -s "https://data.vike.io/v1/hyperliquid/liquidations?coin=BTC&direction=long&limit=100&cursor=$NEXT" \
  -H "X-API-KEY: $VIKE_API_KEY"

# one day of liquidations for an event study, the largest page the route serves
curl -s "https://data.vike.io/v1/hyperliquid/liquidations?start=2026-08-17T00:00:00Z&end=2026-08-18T00:00:00Z&limit=5000" \
  -H "X-API-KEY: $VIKE_API_KEY"

# has this wallet been liquidated before
curl -s "https://data.vike.io/v1/hyperliquid/liquidations?wallet=0xffbdde0c5392ae87f4a56c2095787e96fb241546&limit=100" \
  -H "X-API-KEY: $VIKE_API_KEY"

# check which label each row carries: rows before 2026-04-07 hold a current label, not a point-in-time one
curl -s "https://data.vike.io/v1/hyperliquid/liquidations?start=2026-04-05T00:00:00Z&end=2026-04-09T00:00:00Z&limit=5000" \
  -H "X-API-KEY: $VIKE_API_KEY" \
  | jq '.liquidations | group_by(.pnl_cohort_basis) | map({basis: .[0].pnl_cohort_basis, rows: length})'

coinqueryoptional

HL coin ticker

walletqueryoptional

One wallet

startqueryoptional

ISO-8601 UTC bounds

endqueryoptional

ISO-8601 UTC bounds

directionqueryoptional

long | short

limitqueryoptional

Default 100, max 5000

cursorqueryoptional

Keyset cursor

Example response

{
  "liquidations": [
    {
      "liq_ts": "2026-09-03T07:54:00+00:00",
      "wallet": "0xffbdde0c5392ae87f4a56c2095787e96fb241546",
      "asset": "BTC",
      "side": "long",
      "size_token": 0.05124,
      "size_usd": 3997.28364,
      "mark_price": 78011.0,
      "size_cohort": null,
      "pnl_cohort": "unknown",
      "pnl_cohort_basis": "point_in_time"
    },
    {
      "liq_ts": "2026-09-03T07:54:00+00:00",
      "wallet": "0xfd8b9b4d81d5783dd525d8af2a3566428b6a75c9",
      "asset": "BTC",
      "side": "long",
      "size_token": 0.04319,
      "size_usd": 3369.29509,
      "mark_price": 78011.0,
      "size_cohort": null,
      "pnl_cohort": "3x winner",
      "pnl_cohort_basis": "point_in_time"
    },
    {
      "liq_ts": "2026-09-03T07:54:00+00:00",
      "wallet": "0xfc6a4b0024249e6450723cdcd25f76ad2e565980",
      "asset": "SUI",
      "side": "short",
      "size_token": 313.8,
      "size_usd": 243.58725,
      "mark_price": 0.77625,
      "size_cohort": "shrimp",
      "pnl_cohort": "3x winner",
      "pnl_cohort_basis": "point_in_time"
    }
  ],
  "label_computed": {
    "grading": "realized",
    "when": "at the row's own hour where an hourly label exists for it; at query time for the rows it does not (see caveat)",
    "lookahead": false,
    "resolution": "hourly",
    "source": "hourly point-in-time label set (fallback: live wallet realized-PnL ladder)",
    "detail": "Each row's pnl_cohort is the realized ladder as it stood at the liquidation's own hour, read from the hourly point-in-time label set; pnl_cohort_basis='point_in_time' on those rows. Rows that set does not cover fall back to the live ladder — today's label stamped on a historical event, which IS lookahead — and declare it with pnl_cohort_basis='current'. A wallet in neither source carries null for both fields.",
    "caveat": "Two windows have no point-in-time label and always fall back: rows before 2026-04-07 (liquidations reach back to 2026-01-01, point-in-time labels start 2026-04-07), and the newest hours not yet labelled. In steady state that is only the current incomplete hour — a label is published at hour close — but a backfill or recovery can temporarily widen it (observed 2026-08-21: labels 7h45m behind the wall clock for the duration), so the trailing window is however far the newest label lags now, not a constant."
  },
  "nextCursor": "eyJ0cyI6IjIwMjYtMDktMDMgMDc6NTQ6MDAuMDAwIiwidyI6IjB4ZmM2YTRiMDAyNDI0OWU2NDUwNzIzY2RjZDI1Zjc2YWQyZTU2NTk4MCJ9"
}

Each row's pnl_cohort is point-in-time — the label as it stood at the liquidation's own hour — wherever an hourly label exists for it, and the query-time label where one does not. pnl_cohort_basis says which, per row.

Two windows carry a current label, not a point-in-time one

The envelope's label_computed block declares the two windows the hourly labelling does not cover: rows before 2026-04-07, and the newest hours not yet labelled. Rows in those windows carry a current label, not a point-in-time one.