Order flow

Order flow groups Hyperliquid core, HIP-3, and HIP-4 order events into time buckets, so you can see how order activity changes over a window. Each row is one time bucket. Each bucket counts matching order-status event rows for limit, trigger, and TP/SL placements, plus fills, cancellations, forced cancellations, and triggered orders. They are not rates or deduplicated unique-order counts. Order flow does not include price levels, side, size, wallet, or individual order IDs. Order flow is not the resting order book, an individual order’s lifecycle, or the executed trade tape.

Order flow is derived from the same l4_orders order-event capture as order history, so it shares its coverage start: Hyperliquid core and HIP-3 begin 2026-03-10; HIP-4 begins 2026-05-02. A query entirely before that window returns 200 with an empty array. That means the dataset does not cover that period, not that there was no activity. For activity before the order-event start date, use Trades instead.

Get order flow

Hyperliquid
HIP-3
HIP-4

curl "https://api.0xarchive.io/v1/hyperliquid/orders/BTC/flow?start=1783968600000&end=1783968900000&interval=5m&limit=1" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"

/v1/hyperliquid/orders/{symbol}/flow. Plain perp symbols such as BTC.

curl "https://api.0xarchive.io/v1/hyperliquid/hip3/orders/km:US500/flow" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"

/v1/hyperliquid/hip3/orders/{symbol}/flow. Namespaced builder symbols, case-sensitive.

curl "https://api.0xarchive.io/v1/hyperliquid/hip4/orders/%230/flow" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"

/v1/hyperliquid/hip4/orders/{symbol}/flow. Outcome side ids such as %230.

Response items are untyped in OpenAPI. The Hyperliquid core example below shows one observed response shape, so capture a live response before binding a strict client model. The examples use a July 2026 window, which needs a paid plan; on Free, use a window inside the most recent 30 days. Set the bucket size with interval or granularity. They take the same values, and interval wins when both are sent. Long windows page with cursor and limit; see Page through a window.

Request parameters

Parameter	Description
`symbol`	Path, required, string. Trading pair symbol, e.g. `BTC`
`start`	Query, optional, integer (ms) or string. Start time, Unix milliseconds or RFC 3339 (e.g. `1767225600000`), inclusive. Default 24 hours before now
`end`	Query, optional, integer (ms) or string. End time, Unix milliseconds or RFC 3339, exclusive. Default now
`interval`	Query, optional, string. Bucket size: `1m`, `5m`, `15m`, or `1h`. Default `1m`
`granularity`	Query, optional, string. The name the OpenAPI contract uses for `interval`, with the same values. `interval` wins when both are sent
`cursor`	Query, optional, string. The previous page’s `meta.next_cursor`, passed unchanged. The page starts at the bucket after it
`limit`	Query, optional, integer. Buckets per page. Default 1000, max 10000

Example response

Hyperliquid core, BTC, one five-minute bucket. The request ID is synthetic. The window holds exactly one bucket, so the response has no meta.next_cursor.

{
  "success": true,
  "data": [
    {
      "timestamp": "2026-07-13T18:50:00Z",
      "limit_orders_placed": 112495,
      "orders_canceled": 110965,
      "orders_filled": 1702,
      "trigger_orders_placed": 232,
      "tpsl_orders_placed": 71,
      "orders_triggered": 54,
      "orders_force_canceled": 1225
    }
  ],
  "meta": {
    "count": 1,
    "request_id": "11111111-1111-4111-8111-111111111111"
  }
}

Buckets

Each bucket is labelled by its open time in UTC. Buckets open on multiples of the interval since the Unix epoch, so 5m buckets open at :00, :05, :10, and so on. A bucket with no matching events is omitted, so a quiet market returns fewer rows than its window has buckets. A bucket counts only the events inside [start, end). When start or end falls inside a bucket, that first or last bucket counts only its part of the window. Put start and end on bucket opens to get whole buckets.

Page through a window

A page holds the oldest limit buckets of the window. When the page is full and the window continues after its last bucket, meta.next_cursor contains that bucket’s open time as decimal Unix milliseconds. The continuation value is a string. Pass meta.next_cursor back unchanged. Keep the same start, end, and interval, and stop when meta.next_cursor is absent. Pages never split a bucket, and joined in order they hold the same buckets as one page large enough for the whole window. A full day of 1m buckets at the default limit is two pages: 1,000 buckets, then the other 440.

# first page: 00:00 to 16:39 UTC; meta.next_cursor is "1783960740000" (16:39)
curl "https://api.0xarchive.io/v1/hyperliquid/orders/BTC/flow?start=1783900800000&end=1783987200000&interval=1m" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"

# next page: same start, end, and interval, plus the cursor; 16:40 to 23:59, no meta.next_cursor
curl "https://api.0xarchive.io/v1/hyperliquid/orders/BTC/flow?start=1783900800000&end=1783987200000&interval=1m&cursor=1783960740000" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"

Send explicit start and end when you page. Without them, each request resolves its own defaults from the current time. Do not calculate or increment a cursor. Values that are not decimal Unix milliseconds return 400. General cursor handling is on Pagination.

When to use it

Use Order flow to compare how placement, cancellation, fill, and trigger counts change between buckets. If placements and cancellations rise while fills stay flat, the book may be churning without comparable execution. Inspect Order history for the individual orders or the L4 order book for the resulting resting depth. The interval parameter trades resolution for response size. Finer buckets show more detail but return more rows, and so more pages. Keep the venue family, symbol, window, and interval with every stored result so a later run reproduces the same view.

Order flow and the L4 order book use the same order-event source but answer different questions. L4 reconstructs the resting orders. Order flow summarizes event activity by time bucket.

How it differs

Dataset	Question it answers, and its grain
Order books	What liquidity is resting? Snapshot or ordered book changes
Trades	What executed? One fill
Order history	What happened to each order? One lifecycle event
Order flow	How did order activity change across time buckets? One aggregated time bucket
Take profits and stop losses	Which trigger orders were placed, fired, or canceled? One trigger-order event

Access

Each venue’s start date, WebSocket channels, and page limit come from GET /v1/capabilities, followed by the SDK, CLI, and MCP names for the same data. The start date is the first served row on that venue; exact starts vary by market, so check /v1/symbols for a single symbol. Send 0xArchive-Version: 2026-10-01 for the current response contract; see API conventions.

Venue	Availability
Hyperliquid	No venue-wide start date; see `/v1/symbols` per symbol REST only, no WebSocket channel Up to 10,000 rows a page
HIP-3	No venue-wide start date; see `/v1/symbols` per symbol REST only, no WebSocket channel Up to 10,000 rows a page
HIP-4	No venue-wide start date; see `/v1/symbols` per symbol REST only, no WebSocket channel Up to 10,000 rows a page

Surface	Names
Python SDK	`client.hyperliquid.orders.flow(symbol, ...)`
TypeScript SDK	`client.hyperliquid.orders.flow(symbol, ...)`
Rust SDK	`client.hyperliquid.orders.flow`
CLI	`oxa orders flow`; HIP-4 `oxa hip4 orders flow`
MCP tools	`get_order_flow`, `get_hip3_order_flow`, `get_hip4_order_flow`

Stream it live

Order flow is a REST-side aggregation, so there is no order-flow channel. For live order activity, use the WebSocket channel family matrix to stream the L4 order events (l4_orders, or the venue-prefixed variant) and aggregate the order-event activity yourself.

Export in bulk

There is no standalone order-flow export schema. Use Data Catalog exports to export the raw order events with the l4_orders (Order Events) schema ($4/GB, $12.50 minimum) and aggregate to flow downstream. Schema columns and coverage keys are on Export schemas.

Next step

For the individual orders behind these counts, continue to Order history.

Endpoint reference

Requests and responses

Datasets

Venues

OpenAPI and schemas

Guides

Get order flow

Request parameters

Example response

Buckets

Page through a window

When to use it

How it differs

Access

Stream it live

Export in bulk

Next step

​Get order flow

​Request parameters

​Example response

​Buckets

​Page through a window

​When to use it

​How it differs

​Access

​Stream it live

​Export in bulk

​Next step

Get order flow

Request parameters

Example response

Buckets

Page through a window

When to use it

How it differs

Access

Stream it live

Export in bulk

Next step