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

> Per-order history routes across Hyperliquid core, HIP-3, and HIP-4, with the filters and request params for auditing order lifecycle.

Order history is the per-order lifecycle: placements, fills, cancels, and status changes for a symbol. It is available on Hyperliquid core, Spot, HIP-3, and HIP-4. Lighter has no order-lifecycle routes.

Use Order history when you need the sequence for each order. Each row is one lifecycle event with the order ID, status, size, wallet, and timestamps. Unlike Order flow, it does not collapse activity into time buckets.

<Warning>
  Order history is backed by the `l4_orders` order-event capture, which starts later than trades, funding, and open interest for the same symbol: Hyperliquid core, Spot, and HIP-3 order-event coverage begins 2026-03-10; HIP-4 begins 2026-05-02. A query entirely before that window returns `200` with an empty array — that means the order-event dataset doesn't cover that period yet, not that the wallet or symbol had no activity. For activity before the order-event start date, use [Trades](/rest-api/trades) instead.
</Warning>

## Get order history

<Tabs>
  <Tab title="Hyperliquid">
    ```bash theme={"theme":"github-dark"}
    curl "https://api.0xarchive.io/v1/hyperliquid/orders/BTC/history?start=1783886308365&end=1783886308365&limit=1" \
      -H "X-API-Key: $OXARCHIVE_API_KEY"
    ```

    `/v1/hyperliquid/orders/{symbol}/history`. Plain perp symbols such as `BTC`.
  </Tab>

  <Tab title="Spot">
    ```bash theme={"theme":"github-dark"}
    curl "https://api.0xarchive.io/v1/hyperliquid/spot/orders/HYPE-USDC/history" \
      -H "X-API-Key: $OXARCHIVE_API_KEY"
    ```

    `/v1/hyperliquid/spot/orders/{symbol}/history`. Pair symbols such as `HYPE-USDC`. Spot supports the time-window filters (`start`, `end`, `limit`, `cursor`); the status, order-type, and wallet filters are core, HIP-3, and HIP-4 only.
  </Tab>

  <Tab title="HIP-3">
    ```bash theme={"theme":"github-dark"}
    curl "https://api.0xarchive.io/v1/hyperliquid/hip3/orders/km:US500/history" \
      -H "X-API-Key: $OXARCHIVE_API_KEY"
    ```

    `/v1/hyperliquid/hip3/orders/{symbol}/history`. 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/history" \
      -H "X-API-Key: $OXARCHIVE_API_KEY"
    ```

    `/v1/hyperliquid/hip4/orders/{symbol}/history`. Outcome side ids such as `%230`.
  </Tab>
</Tabs>

The current OpenAPI leaves each response item untyped. The Hyperliquid core example below is representative and abridged. Fields can be omitted or added by order type and venue family, so capture a live fixture before binding a strict client model.

## Request parameters

| Parameter    | In    | Type    | Required | Description                                                                                                                                        |
| ------------ | ----- | ------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| `symbol`     | path  | string  | Yes      | Trading pair symbol, e.g. `BTC`                                                                                                                    |
| `start`      | query | integer | No       | Start time, Unix milliseconds (e.g. `1767225600000`)                                                                                               |
| `end`        | query | integer | No       | End time, Unix milliseconds                                                                                                                        |
| `status`     | query | string  | No       | Filter by order status                                                                                                                             |
| `order_type` | query | string  | No       | Filter by order type                                                                                                                               |
| `user`       | query | string  | No       | Filter by wallet address. `user_address` is not read by this route — passing it is silently ignored and returns unfiltered results, so use `user`. |
| `limit`      | query | integer | No       | Max results. Core, HIP-3, and HIP-4 default to 1000 and cap at 10000. Spot defaults to 100 and caps at 1000                                        |
| `cursor`     | query | string  | No       | Pagination cursor from `meta.next_cursor`                                                                                                          |

## Example response

Hyperliquid core, `BTC`. The example is representative and abridged. The wallet, client order ID, and request ID values are synthetic. The opaque response cursor and transaction hash are omitted.

```json theme={"theme":"github-dark"}
{
  "success": true,
  "data": [
    {
      "timestamp": "2026-07-12T19:58:28.365Z",
      "block_time": "2026-07-12T19:58:28.365Z",
      "block_number": 1070259873,
      "seq": 7,
      "coin": "BTC",
      "user_address": "0x1234567890abcdef1234567890abcdef12345678",
      "status": "open",
      "side": "B",
      "limit_price": 64211,
      "size": 0.05,
      "orig_size": 0.05,
      "oid": 494264716805,
      "order_type": "Limit",
      "is_trigger": false,
      "is_position_tpsl": false,
      "reduce_only": false,
      "tif": "Alo",
      "cloid": "0x00000000000000000000000000000001"
    }
  ],
  "meta": {
    "count": 1,
    "request_id": "22222222-2222-4222-8222-222222222222"
  }
}
```

## What the lifecycle covers

Each record is one event in an order's life: placed, partially filled, filled, canceled, or triggered. Join history to [Trades](/rest-api/trades) and the L4 book with the order id to follow a single order from placement to fill, and use the `status` and `order_type` filters to narrow to the lifecycle stage you care about. For trigger-only rows, use [Take profits & stop losses](/rest-api/tpsl). Store the order id, status, and timestamps so a later run can rebuild the same sequence.

## Stream it live

There is no separate order-history channel. Live order events stream through the L4 order channels (`l4_orders`, plus `spot_l4_orders`, `hip3_l4_orders`, `hip4_l4_orders`), which carry placements, fills, cancels, and status changes as they happen.

```javascript theme={"theme":"github-dark"}
ws.send(JSON.stringify({ op: "subscribe", channel: "l4_orders", symbol: "BTC" }));
```

Connection and reconnect handling live in the [WebSocket](/websocket) tab; see [WebSocket channels](/websocket/channels) for the family matrix.

## Export in bulk

For order-event history as files, use the `l4_orders` (Order Events / TP/SL) export schema (`$8/GB`, `$25 minimum`), delivered as Parquet with ZSTD compression. Build a selection in the [Data catalog](/data-catalog); columns and coverage keys are on [Export schemas](/export-schemas).

## Next

Use [Order flow](/rest-api/order-flow) for aggregated activity, [Take profits & stop losses](/rest-api/tpsl) for trigger orders, or [Order books](/rest-api/order-books) for the L4 book those orders rest in.
