> ## Documentation Index
> Fetch the complete documentation index at: https://docs.0xarchive.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Order flow

> Time-bucketed order-event activity across Hyperliquid core, HIP-3, and HIP-4, with the interval and window params for microstructure work.

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.

<Warning>
  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](/rest-api/trades) instead.
</Warning>

## Get order flow

<Tabs>
  <Tab title="Hyperliquid">
    ```bash theme={"theme":"github-dark"}
    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`.
  </Tab>

  <Tab title="HIP-3">
    ```bash theme={"theme":"github-dark"}
    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.
  </Tab>

  <Tab title="HIP-4">
    ```bash theme={"theme":"github-dark"}
    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`.
  </Tab>
</Tabs>

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](#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`.

```json theme={"theme":"github-dark"}
{
  "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.

```bash theme={"theme":"github-dark"}
# 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](/rest-api/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](/rest-api/order-history) for the individual orders or the [L4 order book](/rest-api/order-books-l4) 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.

<Note>
  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.
</Note>

## How it differs

| Dataset | Question it answers, and its grain |
| - | - |
| [Order books](/rest-api/order-books) | What liquidity is resting? Snapshot or ordered book changes |
| [Trades](/rest-api/trades) | What executed? One fill |
| [Order history](/rest-api/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](/rest-api/tpsl) | 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`](/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](/conventions).

| Venue | Availability |
| - | - |
| Hyperliquid | No venue-wide start date; see `/v1/symbols` per symbol<br />REST only, no WebSocket channel<br />Up to 10,000 rows a page |
| HIP-3 | No venue-wide start date; see `/v1/symbols` per symbol<br />REST only, no WebSocket channel<br />Up to 10,000 rows a page |
| HIP-4 | No venue-wide start date; see `/v1/symbols` per symbol<br />REST only, no WebSocket channel<br />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](/websocket/channels) 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](/data-catalog) 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](/export-schemas).

## Next step

For the individual orders behind these counts, continue to [Order history](/rest-api/order-history).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.