---
title: "Get Liquidations"
method: GET
path: "/api/v1/backtesting/liquidations"
tags: ["Backtesting"]
---

# Get Liquidations

`GET /api/v1/backtesting/liquidations`

## Request

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

Venue-merged liquidation totals — a ROLLING 24-HOUR level sampled every
5 minutes (OKX + Bybit + Hyperliquid), not that interval's flow.

Each row answers "how much was liquidated in the 24h ending at this
sample"; summing rows, or differencing consecutive ones, does not recover a
burst. For incremental 5m / 15m / 1h flow from exact fills use
``/backtesting/hl-liquidation-bars``; for the fills themselves,
``/backtesting/hl-liquidations``. Rows are ordered (time, symbol) and
``next_cursor`` resumes exactly there.

## Query parameters

- `symbol` string: One symbol, or a comma list (BTC,ETH,SOL — up to 25; every value rides the index). Omit for all symbols.
- `start` string, required: Start time (ISO 8601 or unix ms)
- `end` string: End time (ISO 8601 or unix ms, defaults to now). EXCLUSIVE — the range is [start, end), so consecutive windows do not repeat a boundary row.
- `bounds` string: Interval convention for `start`/`end`. `half-open` (default) is [start, end) — `end` is EXCLUSIVE, so consecutive windows tile without repeating a boundary row. `closed` is [start, end] — `end` INCLUSIVE, the pre-2026-08-08 behaviour; use it only to keep an existing integration byte-identical.
- `limit` integer
- `cursor` string, nullable: Opaque page cursor — the `next_cursor` of the previous response, verbatim. Resumes strictly after the last row served, keyed on the table's full primary key, so a page boundary inside a same-millisecond burst loses nothing (unlike `start = last.time + 1`). `start` / `end` still bound the window.
- `format` string: json or csv. CSV has no envelope: paging state travels in the `X-Has-More` / `X-Next-Cursor` response headers.

## Response `200`

Successful Response

- BacktestLiquidationsResponse
  - `grain` GrainDescriptor: What ONE ROW of a series is, stated on the payload so it cannot be mis-summed. ``kind``: ``event`` (one fill), ``bar`` (a closed bucket), ``rate_snapshot`` (the live rate sampled on a timer), ``rolling_window`` (a trailing total sampled on a timer), ``settled_payment`` (one settlement print). ``sum_ok`` — adding rows across time is meaningful. ``is_cumulative`` — a row already contains its predecessors' flow. ``settlements_per_day`` is set for funding series only.
    - `kind` string, required
    - `cadence` string, nullable
    - `is_cumulative` boolean
    - `sum_ok` boolean
    - `window` string, nullable
    - `settlements_per_day` integer, nullable
    - `note` string, required
  - `coverage` CoverageInfo: Local retention bounds (ms) for the queried scope. ``archive_hint`` is set when the window starts before ``local_first`` — those rows are not missing, they live in the daily Parquet archive.
    - `local_first` integer, nullable
    - `local_last` integer, nullable
    - `archive_hint` string, nullable
  - `next_cursor` string, nullable
  - `has_more` boolean
  - `symbol` string, nullable, required
  - `count` integer, required
  - `data` BacktestLiquidationEntry[], required
    - `time` integer, required
    - `symbol` string, required
    - `long_liq_usd` number, nullable
    - `short_liq_usd` number, nullable
    - `total_liq_usd` number, nullable

## 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)