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

# WebSocket openOrders: Active Orders Snapshot and Updates

> Subscribe to openOrders to receive a full snapshot of all active orders on subscribe, followed by real-time incremental updates as orders change state.

The `openOrders` channel is the best starting point for managing an account's order state in real time. On subscribe, the server immediately pushes a complete snapshot of every currently active order — both regular open orders and untriggered conditional (TP/SL) orders. All subsequent changes are delivered as incremental update messages using the same compact format as [`orderUpdates`](/websocket/order-updates). This combination means you can always maintain a fully consistent local view of active orders.

Pass the account's wallet address (not the numeric account ID) as the `user` parameter.

## Subscribing

```json theme={"system"}
{
  "method": "subscribe",
  "subscription": {"type": "openOrders", "user": "0xabc...123"}
}
```

## Initial snapshot

Immediately after subscribing, the server sends an `OpenOrdersSnapshot` message:

```json theme={"system"}
{
  "msg": "OpenOrdersSnapshot",
  "channel": "openOrders.0xabc...123",
  "data": [
    {
      "id": "6",
      "clientOrderId": "0",
      "accountId": "5",
      "contractId": 1,
      "marginMode": "C",
      "positionSide": "OneWay",
      "orderSide": "B",
      "orderType": "L",
      "timeInForce": "Gtc",
      "price": "50",
      "size": "10",
      "leverage": "10",
      "status": "Open",
      "reduceOnly": false
    }
  ],
  "ts": 1782279307885
}
```

The snapshot uses expanded field names for clarity. The `data` array contains one object per active order. An empty array means the account has no open orders at subscription time.

## Snapshot field reference

<ResponseField name="id" type="string">
  Unique order ID assigned by the exchange.
</ResponseField>

<ResponseField name="clientOrderId" type="string">
  Client-assigned order ID. `"0"` if not set when placing the order.
</ResponseField>

<ResponseField name="accountId" type="string">
  Numeric account ID that owns this order.
</ResponseField>

<ResponseField name="contractId" type="number">
  The contract this order is placed on.
</ResponseField>

<ResponseField name="marginMode" type="string">
  Margin mode: `"C"` = cross margin, `"I"` = isolated margin.
</ResponseField>

<ResponseField name="positionSide" type="string">
  Position side: `"OneWay"` for one-way mode; `"Long"` or `"Short"` for hedge mode.
</ResponseField>

<ResponseField name="orderSide" type="string">
  `"B"` = buy (bid), `"S"` = sell (ask).
</ResponseField>

<ResponseField name="orderType" type="string">
  `"L"` = limit, `"M"` = market.
</ResponseField>

<ResponseField name="timeInForce" type="string">
  `"Gtc"` (good-till-cancel), `"Ioc"` (immediate-or-cancel), `"Alo"` (add-liquidity-only / post-only), or `"Fok"` (fill-or-kill).
</ResponseField>

<ResponseField name="price" type="string">
  Order price (raw string).
</ResponseField>

<ResponseField name="size" type="string">
  Remaining unfilled size (raw string).
</ResponseField>

<ResponseField name="leverage" type="string">
  Leverage applied to this order at placement time.
</ResponseField>

<ResponseField name="status" type="string">
  `"Open"` for a regular active order; `"Untriggered"` for a pending conditional order.
</ResponseField>

<ResponseField name="reduceOnly" type="boolean">
  `true` if this order can only reduce an existing position.
</ResponseField>

## Incremental update messages

After the snapshot, subsequent state changes arrive as `OpenOrdersUpdate` messages:

```json theme={"system"}
{
  "msg": "OpenOrdersUpdate",
  "channel": "openOrders.0xabc...123",
  "data": [ { ...compact entry... } ],
  "ts": 1782279307885
}
```

Update entries use the same compact short-field format as `orderUpdates` — see the [orderUpdates field reference](/websocket/order-updates#field-reference) for the full mapping.

## Maintaining local order state

<Steps>
  <Step title="Subscribe and wait for the snapshot">
    Subscribe and buffer any incoming `OpenOrdersUpdate` messages until you receive the `OpenOrdersSnapshot`. This prevents a race condition where an update arrives before the snapshot.
  </Step>

  <Step title="Seed your local state from the snapshot">
    Store every order in the snapshot keyed by `id`. Orders with `"status": "Untriggered"` are pending conditional orders.
  </Step>

  <Step title="Apply buffered and incoming updates">
    For each `OpenOrdersUpdate`, update or remove orders from your local map: upsert if the order is new or modified; remove if `"st": "Filled"` or `"st": "Canceled"`.
  </Step>
</Steps>

<Note>
  Pending conditional orders appear in the snapshot with `"isConditional": true` and `"status": "Untriggered"`. When a conditional order triggers, it is removed from the open orders state and a new regular order appears with a new `id`.
</Note>

<Tip>
  If you only need ongoing changes without the initial snapshot overhead, subscribe to [`orderUpdates`](/websocket/order-updates) instead. `openOrders` is the right choice when you need a guaranteed consistent starting state.
</Tip>