WhiteBit Orders Pending
Version 1.0.0
Query and subscribe to [active orders](/glossary#active-orders) (orders not yet executed). The WebSocket methods use `ordersPending_*` naming for API compatibility. **Important**: [Market](/glossary#market) should exist. The maximum limit is 100. **Note**: If a new [order](/glossary#orders) instantly matches an order from the [orderbook](/glossary#order-book), only one message is received with update event ID equal to 3. ## Update Event IDs | Update event ID | Description | | --------------- | -------------------------------- | | 1 | New order | | 2 | Update order | | 3 | Finish order (cancel or execute) | ## Order Modification Behavior When a client calls `POST /api/v4/order/modify`, the matching engine cancels the original order and creates a replacement. This channel emits **two sequential events**: 1. **event_id=3** (Finish) — the original order is cancelled. The `id` in the payload matches the old `order_id` that was passed to the modify request. 2. **event_id=1** (New) — the replacement order is created with a **new `order_id`**. **Implication:** `order_id` changes on every modification. Clients tracking orders by `order_id` must update the stored value after each modify call. Set `client_order_id` on orders for stable correlation across modifications. Events arrive in sequence (event_id=3 before event_id=1) in practice. Handle out-of-order delivery defensively. ## 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. **Implication:** 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. Applies to 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.
Channels
Messages
Servers
AsyncAPI Specification
Work with this as data
Every AsyncAPI spec here is available over the APIs.io API and to AI agents over MCP.