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 rejected, when a conditional (TP/SL) order changes state, and when a resting order is filled by another order. Entries come in five kinds, each with its own field set, and one frame can mix several kinds — see Telling the entry kinds apart. 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, in lowercase 0x + 40 hex form. The address must belong to a registered account.

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",
  "os": "10",
  "st": "Open",
  "tp": {"isSet": false, "triggerPrice": "0", "price": "0", "triggerType": 0, "size": "0"},
  "sl": {"isSet": false, "triggerPrice": "0", "price": "0", "triggerType": 0, "size": "0"}
}

This entry is sent for an order you place, including when it fills on arrival as the taker.

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
`os`	string	Original order size (raw) — the size submitted at placement; it does not change as the order fills. Corresponds to `originalSize` in REST `userOrders`. Filled size = `os` − `s`, so you do not need to track fills yourself. Also carried by the cancel, rejected, and passive fill entries; the conditional entry has none
`st`	string	Order status, one of three values: `"Open"` — resting on the book, unfilled or partially filled (`Gtc` and `Alo` orders only); `"Filled"` — fully filled; `"Canceled"` — an `Ioc` or `Fok` order that partially filled, with the unfilled remainder cancelled during matching. `Canceled` here is final: no further entry follows for this order, `s` is the cancelled unfilled size, and filled size is still `os` − `s`
`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".

{
  "id": "15",
  "r": "144115188075856500",
  "si": 0,
  "cid": "1778844423064",
  "a": "5",
  "c": 1,
  "b": "B",
  "s": "0",
  "cq": "700",
  "os": "1000",
  "st": "Canceled"
}

Field	Type	Description
`id`	string	Order ID of the cancelled order
`r`	string	Request ID, for debugging only — do not correlate on it
`si`	number	subIndex within the submitted batch, as on the regular entry. You know which `o` / `cloid` you cancelled, so matching on `id` / `cid` is sufficient for a successful cancel
`cid`	string	Client order ID — present only if one was set on the order
`a`	string	Account ID
`c`	number	Contract ID
`b`	string	Direction, `"B"` or `"S"`. Conditional: present only when the order’s direction is known; otherwise the key is omitted — no default direction is substituted
`s`	string	Always `"0"` on a cancel entry. It is the size remaining after the cancel, not the size cancelled
`cq`	string	The cancelled size (raw) — the unfilled remainder at the moment of cancellation. Read the quantity from `cq`, not from `s`
`os`	string	Original order size (raw), as submitted. Filled size = `os` − `cq`. Conditional: omitted when the original size is not known — never sent as `"0"`
`st`	string	Always `"Canceled"`

A cancel entry has no t or tif. In the example, an order of 1000 filled 300 before the remaining 700 was cancelled.

Rejected order entry

If an order placement or a cancel is rejected (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",
  "si": 0,
  "r": "144115188075856500",
  "a": "5",
  "c": 1,
  "b": "B",
  "os": "1000",
  "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
`os`	string	The size of the rejected order (raw), as submitted. Conditional: present only on a rejected placement; a rejected cancel or modify has no size and omits it
`code`	number	Rejection error code. One code can cover several distinct business errors, so use it to classify the rejection, and keep a default branch for codes you do not handle. See Error codes
`reason`	string	Rejection reason, at most 160 bytes; longer text is truncated at the byte limit. The wording is not a stable contract — branch on `code`, not on `reason`
`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. Rejected placements and rejected cancels share this entry kind.

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,
  "ts": 1700000000000,
  "st": "Untriggered",
  "isPositionTpsl": true,
  "parentOrderId": "0"
}

Additional fields for conditional orders:

Field	Type	Description
`cond`	boolean	Always `true`; identifies this as a conditional order
`p`	string	Limit price after triggering (raw); `"0"` means the order executes as a market IOC order after triggering
`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. Corresponds to `timestamp` on conditional orders in REST `userOrders`
`isPositionTpsl`	boolean	Always present. `true` — a position-level TP/SL, whose closing direction is determined by the position; `false` — a standalone trigger order. Same meaning as the field of the same name on `tpSl` and REST `userOrders`
`parentOrderId`	string	Always present. When the conditional order was created from the TP/SL attached to an opening order, the order ID of that opening order; otherwise `"0"`
`otp` / `otpp` / `otps` / `otpt` / `otpo`	string / string / string / number / number	Conditional: present only when this conditional order carries an opening take-profit; otherwise the whole group is omitted. They describe the take-profit attached to the order placed on trigger: trigger price, execution price, close size (`"0"` = close all), trigger price type (`0` = mark, `1` = oracle), and order type (`1` = limit, `2` = market). They correspond to the `openTp*` parameters of `tpSl`
`osl` / `oslp` / `osls` / `oslt` / `oslo`	string / string / string / number / number	Conditional: present only when this conditional order carries an opening stop-loss; otherwise the whole group is omitted. Same meanings as the row above, for the stop-loss; they correspond to the `openSl*` parameters

otp* / osl* describe the TP/SL of the order created after triggering. They are a separate layer from this entry’s own trigger price tp and trigger type tpt.

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 conditional order is removed and the resulting order follows as a regular entry (no `cond`) with status `Open`, `Filled`, or `Canceled`
`Rejected`	Trigger price was reached, but the resulting order was rejected. No regular entry follows for this order

A market order created by a trigger executes as IOC, so if it fills only partially, its regular entry arrives with the final status Canceled.

Passive fill entry

When another order fills one of your resting orders, you — the maker — receive this entry:

{"id": "15", "a": "5", "c": 1, "b": "S", "t": "L", "p": "50", "s": "4", "os": "10", "st": "Open"}

Field	Type	Description
`id`	string	Order ID of the resting order that was filled. The only correlation key on this entry
`a`	string	Account ID
`c`	number	Contract ID
`b`	string	Direction: `"B"` or `"S"`
`t`	string	Order type, as on the regular entry
`p`	string	Resting order price (raw)
`s`	string	Remaining size after the fill (raw)
`os`	string	Original order size (raw). Filled size so far = `os` − `s`
`st`	string	`"Open"` — partially filled, still on the book; `"Filled"` — fully filled

This entry carries no r, si, cid, tif, tp, or sl. Match it to your order by id (available from the regular entry after placement, or from userOrders). The taker does not receive this entry; it receives a regular entry. For fill price, size, and fee, use the userFills channel.

Telling the entry kinds apart

Check the conditions in this order:

Entry kind	How to identify it
Conditional (TP/SL)	Has `"cond": true`
Rejected	`st` is `"Rejected"` and there is no `cond` (carries `n`, `code`, `reason`)
Cancel	`st` is `"Canceled"` and there is no `t` (a regular entry with `Canceled` always carries `t` and `tif`)
Regular — placement or taker fill	Has `tif`
Passive fill	None of the above: no `cond`, no `tif`, no `r`

tp is an object on a regular entry and a string (trigger price) on a conditional entry. The entry-level ts (conditional entries only, creation time) differs from the envelope ts (send time). Identify the entry kind first, then read its fields.

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

Passive fill entry

Telling the entry kinds apart

​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

​Passive fill entry

​Telling the entry kinds apart

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

Passive fill entry

Telling the entry kinds apart