WebSocket Order Updates

The orderUpdates channel sends incremental state changes for every order associated with an account — the moment an order is placed, partially filled, fully filled, cancelled, or when a conditional (TP/SL) order triggers or is cancelled. On subscribe the server first sends one frame of recent order history (see History snapshot on subscribe); live increments follow. That snapshot contains only orders that have already terminated — for a full view of orders currently resting, subscribe to openOrders or query userOrders. Pass the account’s wallet address (not the numeric account ID) as the user parameter.

Subscribing

{
  "method": "subscribe",
  "subscription": {"type": "orderUpdates", "user": "0xabc...123"}
}

Push envelope

All order update messages share this envelope structure:

{
  "msg": "OrderUpdate",
  "channel": "orderUpdates.0xabc...123",
  "data": [ { "...": "..." } ],
  "ts": 1782279307885
}

The data array may contain multiple entries when several orders change state in the same block.

Regular order entry

{
  "id": "15",
  "r": "144115188075856500",
  "si": 0,
  "cid": "1778844423064",
  "a": "5",
  "c": 1,
  "b": "B",
  "t": "L",
  "tif": "Gtc",
  "p": "50",
  "s": "10",
  "st": "Open"
}

Field reference

Field	Type	Description
`id`	string	Unique order ID assigned by the exchange
`r`	string	Server-assigned request ID (debugging only). It is not known at submit time, so do not use it to correlate — match on `cid`, or on the signed `nonce` for a rejected entry
`si`	number	subIndex — the position of this order within the submitted batch, starting at `0`; always `0` for a single-order request. Combine with `n` to map a push back to an exact element of your `orders[]`
`cid`	string	Client order ID — omitted if you did not set one when placing the order
`a`	string	Account ID that owns this order
`c`	number	Contract ID
`b`	string	Direction: `"B"` = buy, `"S"` = sell
`t`	string	Order type: `"L"` limit, `"M"` market, `"SL"` stop limit, `"SM"` stop market, `"TPL"` take-profit limit, `"TPM"` take-profit market
`tif`	string	Time-in-force: `"Gtc"` (good-till-cancel), `"Ioc"` (immediate-or-cancel), `"Alo"` (add-liquidity-only / post-only), `"Fok"` (fill-or-kill)
`p`	string	Order price (raw)
`s`	string	Remaining unfilled size (raw) — equals total size minus already-filled size
`st`	string	Order status: `"Open"`, `"Filled"`, `"Canceled"`, or `"Rejected"` (see Rejected order entry)
`tp` / `sl`	object	Take-profit / stop-loss attached to this order at placement — `{"isSet": bool, "triggerPrice": "…", "price": "…", "triggerType": int, "size": "…"}`, field for field identical to the `tp` / `sl` objects in REST `userOrders`. Present even while the order is still resting, so one parser serves both

On a regular entry tp is an object; on a conditional entry tp is a scalar trigger price. Check for "cond": true before parsing it.

Immediately after a successful subscription the server pushes one frame carrying up to the last 10 terminated orders, so a client can render history without a separate REST call. It differs from an incremental frame in two ways:

	Incremental frame	Snapshot frame
`msg`	`OrderUpdate`	`OrderHistorySnapshot`
`data`	array of entries	object `{"rows": [...], "count": N, "truncated": false}`

{
  "msg": "OrderHistorySnapshot",
  "channel": "orderUpdates.0xabc...123",
  "data": {"rows": [ { "...": "..." } ], "count": 10, "truncated": false},
  "ts": 1782279307885
}

rows[] uses different field names from the incremental entries — you cannot reuse one parser for both. A private-channel snapshot passes through the corresponding REST response body verbatim, so it uses the full REST column names (order_id, contract_id, price) while increments use the compact wire names (id, c, p). Reuse your REST parser for the snapshot.

Snapshot row fields

Field	Type	Description	Incremental equivalent
`updated_time_ms`	number	Time the order terminated (ms)	—
`created_time_ms`	number	Time the order was placed (ms)	—
`height`	number	Block height at termination	—
`seq`	number	Sequence within the block	—
`order_id`	string	Order ID	`id`
`cl_ord_id`	string	Client order ID; `"0"` when none was set	`cid`
`contract_id`	number	Contract ID	`c`
`market_deployer_id`	number	Market deployer ID	—
`side`	number	`66` = buy, `83` = sell (ASCII `B` / `S`)	`b` (string `"B"` / `"S"`)
`ord_type`	number	`1` limit, `2` market, `3` stop limit, `4` stop market, `5` take-profit limit, `6` take-profit market	`t` (string)
`price`	string	Order price (raw)	`p`
`orig_qty`	string	Original quantity (raw)	—
`filled_qty`	string	Filled quantity (raw)	—
`leaves_qty`	string	Remaining quantity (raw)	`s`
`status`	number	`0` Open, `1` Filled, `2` Canceled, `3` Untriggered	`st` (string)
`origin`	number	How it terminated: `0` normal, `1` modify, `2` liquidation, `3` conditional trigger, `4` passive fill, `5` cancel	—
`cancel_reason`	number	Cancellation reason	—
`reject_code`	number	Rejection code; `0` means not rejected	`code`

Working with the snapshot:

The payload is at data.rows, and data is an object rather than an array. (openOrders also sends an object, but its payload key is orders.)
Quoted fields are big integers carried as strings (order_id, cl_ord_id, price, every *_qty). They can exceed the JavaScript safe-integer range — never pass them through Number() before comparing or echoing them back.
side, ord_type, and status are numeric here and strings in the incremental frames. Map them before display.
It contains only terminated orders. Orders still working are not included — use the openOrders first frame or userOrders for those.
Fewer than 10 rows, or none at all, is normal — the account may have little history, or the history service may be briefly unavailable. Do not treat it as an error.
The snapshot and the increments that follow may overlap. Deduplicate by order ID (order_id in the snapshot, id in increments); nothing is dropped.
The snapshot is fixed at 10 rows, with no paging and no cursor. For deeper history use orderHistory.

Cancel entry

When an order is cancelled, a compact entry is sent with "st": "Canceled". The s field carries the remaining unfilled size at the time of cancellation.

{
  "id": "15",
  "r": "144115188075856500",
  "cid": "1778844423064",
  "a": "5",
  "c": 1,
  "s": "10",
  "st": "Canceled"
}

Rejected order entry

If the matching engine rejects an order (for example, the contract doesn’t exist, insufficient margin, or a position-mode mismatch), a "st": "Rejected" entry is pushed here. A rejected order appears only on this channel — it is never assigned an order ID, never appears in openOrders, and cannot be found by any order-ID or client-order-ID query.

{
  "id": "-1",
  "n": "1743600000000",
  "r": "144115188075856500",
  "a": "5",
  "c": 1,
  "code": 19,
  "reason": "account not enrolled",
  "st": "Rejected"
}

Field	Type	Description
`id`	string	`"-1"` for a rejected order placement, which has no order ID. A rejected cancel echoes the real order ID when the target order exists (for example it had already filled), and you can correlate on that directly
`n`	string	The correlation key. The `nonce` you chose when submitting the order, echoed back — use it to match this push to the order you sent
`si`	number	subIndex within the submitted batch, starting at `0`; always `0` for a single-item request. Combine with `n` to identify which element of `orders[]` / `cancels[]` was rejected
`b`	string	Direction, present only when a valid side can be resolved — omitted when it cannot, such as a rejected cancel
`r`	string	Request ID, for debugging only. Do not correlate on it — it is server-assigned and unknown at submit time
`cid`	string	Client order ID — present only if you set one; when present, prefer it for correlation
`a`	string	Account ID
`c`	number	Contract ID
`code`	number	Rejection error code
`reason`	string	Rejection reason (max 40 characters; truncated if longer)
`st`	string	Always `"Rejected"`

A rejected entry omits t / tif / p / s — the order never became active, so it has none of those attributes. b appears only when a valid direction can be resolved.

Conditional (TP/SL) order entry

Conditional orders include "cond": true and use a different set of status values:

{
  "id": "20",
  "a": "5",
  "c": 1,
  "b": "S",
  "t": "M",
  "p": "0",
  "s": "10",
  "tp": "80000",
  "tpt": 0,
  "ro": true,
  "cond": true,
  "st": "Untriggered"
}

Additional fields for conditional orders:

Field	Type	Description
`cond`	boolean	`true` identifies this as a conditional order
`tp`	string	Trigger price (raw)
`tpt`	number	Trigger price type: `0` = mark price, `1` = oracle price
`ro`	boolean	`true` if this is a reduce-only order
`ts`	number	Block time at which the conditional order was created (Unix ms). This is inside the entry and is not the envelope’s frame-send `ts` — same name, different meaning

Conditional order statuses:

Status	Meaning
`Untriggered`	Conditional order is active and waiting for the trigger price
`Canceled`	Conditional order was cancelled before triggering
`Triggered`	Trigger price was reached; the order has been promoted to a regular order and a new entry with the regular order ID will follow

orderUpdates provides only incremental changes — there is no initial snapshot on subscribe. If you need the full list of currently active orders as a starting point, subscribe to openOrders first.

Set a client order ID (cid) when you place an order, then match incoming OrderUpdates on cid to link each update back to your submission — especially useful when placing orders in rapid succession. The r request ID is server-assigned and unknown at submit time, so it cannot serve as the correlation key. A rejected order never receives an id, so it is correlated by the nonce you signed (see Rejected order entry).

Overview

Market Channels

Account Channels

WebSocket Order Updates

Subscribing

Push envelope

Regular order entry

Field reference

Snapshot row fields

Cancel entry

Rejected order entry

Conditional (TP/SL) order entry

​Subscribing

​Push envelope

​Regular order entry

​Field reference

​History snapshot on subscribe

​Snapshot row fields

​Cancel entry

​Rejected order entry

​Conditional (TP/SL) order entry

Subscribing

Push envelope

Regular order entry

Field reference

History snapshot on subscribe

Snapshot row fields

Cancel entry

Rejected order entry

Conditional (TP/SL) order entry