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

# Orders Pending

> Subscribe to real-time updates on pending account orders on WhiteBIT via WebSocket.

Query or subscribe to active (unexecuted) orders across specified markets. The server pushes `ordersPending_update` events in real time on every order state change. Subscribe to multiple markets simultaneously by passing market names in the `params` array.

<Note>Connect to `wss://api.whitebit.com/ws` — see [WebSocket Overview](/websocket/overview) for protocol details and keepalive requirements.</Note>

## Rate limits

## Query pending orders (one-time)

Fetch current pending orders for a market without subscribing to updates.

**Request**

**Response**

## Subscribe to order updates

<Note>
  Events during a disconnection are not replayed. After reconnecting, query current open orders with `ordersPending_request` or the REST [Query Unexecuted Orders](/api-reference/spot-trading/query-unexecuted-orders) endpoint before re-subscribing. See [Reconnection and state recovery](/guides/websocket-quickstart#state-recovery-after-reconnect).
</Note>

## Update frequency

Updates are pushed in **real time** on every order state change (new, modified, partially filled).

## Error codes

## Order modification behavior

When `POST /api/v4/order/modify` is called, the matching engine cancels the original order and creates a replacement, producing **two sequential events**:

1. `event_id=3` (Finish) — original order cancelled. The `id` in the payload matches the old `order_id`.
2. `event_id=1` (New) — replacement order created with a **new `order_id`**.

Clients tracking orders by `order_id` must update the stored value after each modify call. Use `client_order_id` for stable correlation across modifications.

<div style={{borderLeft: '3px solid #60a5fa', paddingLeft: '0.75rem', marginTop: '0.75rem', fontSize: '0.8125rem', color: '#374151', lineHeight: '1.5'}}>
  The private stream returns active orders, including orders using Retail Price Improvement (RPI) mode. Because public `depth` excludes RPI orders, this stream is the source for an account's own RPI orders — see [including RPI orders in a local order book](/websocket/market-streams/depth#including-rpi-orders-in-a-local-order-book) for how to overlay them onto the public order book.
</div>

## Stop order activation

When a stop order ([types](/websocket/account-streams/overview#order-types) `3`, `4`, `9`, `10`) triggers, the server emits an `event_id=1` (New) event for the now-active order **without** a preceding `event_id=3` (Finish) for the stop record. The `order_id` is preserved across activation — the same id appears on both the original stop and the activated order.

The `type` and `status` fields do not change on activation: the type integer stays (`3` → `3`, and so on), and `status` remains `OPEN` (or transitions to `PARTIALLY_FILLED` only once the activated order begins filling). The arrival of a second `event_id=1` for an `order_id` already present in local state is the only activation signal.

Clients tracking orders by `order_id` must **upsert** on `order_id` rather than append, otherwise the resting stop and the activated order will appear as two entries for the same logical order.

This applies to all stop types: spot stop-limit (`3`), spot stop-market (`4`), margin stop-limit (`9`), and margin stop-market (`10`). Types `3` and `4` are spot-only; margin and futures markets use types `9` and `10`.

## Order object

Fields present in both the query response (`records[]`) and the pushed `ordersPending_update` payload.

* [Orders Executed](/websocket/account-streams/orders-executed) — stream of filled and cancelled orders.
* [Query Unexecuted Orders](/api-reference/spot-trading/query-unexecuted-orders) — open order snapshot via REST for state recovery after reconnection.