Order lifecycle

Understanding how an order moves through states is critical for systematic trading. This page documents every state, what triggers each transition, and how to observe them across the three API protocols.

State machine

                    ┌─────────────────────────────┐
                    │           PENDING            │
                    │  Order received, not yet     │
                    │  validated by trading engine │
                    └──────────────┬──────────────┘
                                   │
                    ┌──────────────▼──────────────┐
                    │             OPEN             │
                    │  Resting in the order book   │
                    └──────────────┬──────────────┘
                                   │
              ┌────────────────────┼────────────────────┐
              │                    │                    │
  ┌───────────▼────────┐ ┌────────▼────────┐ ┌────────▼────────┐
  │  PARTIALLY FILLED  │ │     FILLED      │ │    CANCELED     │
  │  Some qty matched  │ │  Fully matched  │ │  Canceled by    │
  │  remainder rests   │ │                 │ │  user or system │
  └───────────┬────────┘ └─────────────────┘ └─────────────────┘
              │
  ┌───────────▼──────────────────────────────────────────────┐
  │  CLOSED (fully filled from partial, or canceled partial) │
  └──────────────────────────────────────────────────────────┘

States

State	Description
`pending`	Order has been accepted but not yet processed by the trading engine
`open`	Order is live in the order book, awaiting a match
`partially_filled`	One or more partial fills have occurred; remainder is still open
`filled` (closed)	Order has been fully matched
`canceled` (closed)	Order was canceled — by the user, by COD, by `cancelAllOrdersAfter`, or by the system
`expired` (closed)	GTD (Good Till Date) order whose expiry time was reached

State transitions

From	To	Trigger
—	`pending`	Order accepted by OES/FIX Gateway
`pending`	`open`	Validated and placed in the order book
`pending`	`canceled`	Validation failure (insufficient funds, invalid params, rate limit)
`open`	`partially_filled`	Partial match in the trading engine
`open`	`filled`	Full match in the trading engine
`open`	`canceled`	User cancel, COD disconnect, `cancelAllOrdersAfter` deadline, `cancelAll`
`open`	`expired`	GTD order expiry reached
`partially_filled`	`partially_filled`	Additional partial fill
`partially_filled`	`filled`	Final fill clears remaining quantity
`partially_filled`	`canceled`	Remaining quantity canceled (IOC residual, user cancel, reduce-only limit)

Observing state by API

REST

Use OpenOrders to see live orders and ClosedOrders / QueryOrders for historical state. The status field returns the current state string.

# All open orders
POST /0/private/OpenOrders

# Specific order (open or closed)
POST /0/private/QueryOrders
# body: txid=ORDERTXID1

Response includes:

status: open, pending, closed, canceled, expired
vol_exec: volume filled so far
reason: populated on cancellation (e.g. "User requested", "Order would trigger immediately")
amended: boolean, true if the order was ever amended

WebSocket v2

Subscribe to the executions channel for real-time state changes. Every state transition produces a message.

{
  "channel": "executions",
  "type": "snapshot" | "update",
  "data": [{
    "exec_type": "new" | "trade" | "canceled" | "expired" | "amended" | "status" | "restated" | "liquidated",
    "order_status": "new" | "partially_filled" | "filled" | "canceled" | "expired",
    "order_id": "ABCDE-12345-XXXXX",
    "qty": 1.0,
    "filled_qty": 0.5,
    "reason": "..."
  }]
}

Key exec_type values:

`exec_type`	Meaning
`new`	Order placed in the book
`trade`	Partial or full fill
`canceled`	Order canceled
`expired`	GTD expiry
`amended`	Order was amended (price, quantity, or both)
`status`	State confirmation with no change (e.g. on reconnect snapshot)
`restated`	Order state was restated, typically after a system event
`liquidated`	Order was forcibly closed by the risk system

WebSocket v1

Subscribe to openOrders for live state updates. The feed sends a snapshot on subscribe, then incremental updates.

[
  { "ORDERTXID": { "status": "open", "vol_exec": "0.50000000" } },
  [{"sequence": 4}]
]

FIX

ExecutionReport (MsgType=8) is the primary message for order state. Key tags:

Tag	Field	Values
39	`OrdStatus`	`0`=New, `1`=Partial fill, `2`=Filled, `4`=Canceled, `6`=Pending cancel, `8`=Rejected, `C`=Expired
150	`ExecType`	`0`=New, `1`=Partial fill, `2`=Fill, `4`=Canceled, `8`=Rejected, `C`=Expired, `D`=Restated, `G`=Trade correct
58	`Text`	Human-readable reason on rejection or cancellation
14	`CumQty`	Total quantity filled
151	`LeavesQty`	Remaining open quantity

Amendment and queue priority

When you amend an order, queue priority behaviour depends on what changed:

Amendment type	Queue priority
Reduce quantity only	Preserved — the order keeps its time priority
Increase quantity	Lost — order moves to back of queue at that price
Change price	Lost — order moves to back of queue at the new price

For market-making strategies: reducing size without changing price preserves priority. This is a key advantage of AmendOrder over cancel-replace (CancelOrder + AddOrder).

Special cancellation triggers

Cancel on Disconnect (COD) — FIX only When a FIX session disconnects, all orders placed on that session are automatically canceled. COD is configured at the session level during onboarding. Dead Man’s Switch — all APIs CancelAllOrdersAfter sets a countdown timer. If not refreshed before expiry, all open orders are canceled. Use this as a safety net against connectivity issues.

POST /0/private/CancelAllOrdersAfter
# body: timeout=60  (seconds)

Refresh it periodically from your trading loop. Cancel it by setting timeout=0. IOC — Immediate or Cancel Orders with time_in_force=IOC fill immediately at the available best price and the unfilled remainder is instantly canceled with reason: "Immediate or cancel". Reduce-only cancellation If a reduce-only order would flip a position, it matches as much as possible and the remainder is canceled with EOrder:Reduce only:Position is closed.

Self-trade prevention

Self-trade prevention (STP) prevents your orders from matching against each other. Configure at the order level:

Mode	FIX Tag 7928	REST `stp_type`	Behaviour
Cancel newest (default)	`1`	`cancel-newest`	Arriving order is canceled
Cancel oldest	`2`	`cancel-oldest`	Resting order is canceled
Cancel both	`0`	`cancel-both`	Both orders are canceled

API comparison

Choose between REST, WebSocket, and FIX for order management

Error reference

Order error codes and cancellation reason strings

WebSocket reconnection

Reconcile order state after a disconnect

Order amends

Amend price or quantity without losing queue priority

Rate limits

How order placement and cancellation consume rate limit

FIX ExecutionReport

FIX MsgType=8 — full field reference for order state messages

Getting started

Authentication

Integration

Futures

Production

Advanced

State machine

States

State transitions

Observing state by API

REST

WebSocket v2

WebSocket v1

FIX

Amendment and queue priority

Special cancellation triggers

Self-trade prevention

API comparison

Error reference

WebSocket reconnection

Order amends

Rate limits

FIX ExecutionReport

​State machine

​States

​State transitions

​Observing state by API

​REST

​WebSocket v2

​WebSocket v1

​FIX

​Amendment and queue priority

​Special cancellation triggers

​Self-trade prevention

​Related guides

API comparison

Error reference

WebSocket reconnection

Order amends

Rate limits

FIX ExecutionReport

State machine

States

State transitions

Observing state by API

REST

WebSocket v2

WebSocket v1

FIX

Amendment and queue priority

Special cancellation triggers

Self-trade prevention

Related guides