Skip to main content
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.
Connect to wss://api.whitebit.com/ws — see WebSocket Overview for protocol details and keepalive requirements.

​
Rate limits

​
Query pending orders (one-time)

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

​
Subscribe to order updates

Events during a disconnection are not replayed. After reconnecting, query current open orders with ordersPending_request or the REST Query Unexecuted Orders endpoint before re-subscribing. See Reconnection and state recovery.

​
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.
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 for how to overlay them onto the public order book.

​
Stop order activation

When a stop 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.