Track, cancel and reconcile orders

Four pushes say what happens to your orders and their CETs, and one read says where an order stands whatever the pushes delivered.

Message	What it is	When
`order_updated`	The order as it stands: a snapshot, not a delta	Pushed once per change: accepted, partially filled, filled, cancelled, expired
`trade_updated`	One execution, as a ledger row with amounts and settlement date	Pushed once per execution
`mint_updated`, `burn_updated`	A mint or a burn, with the shape `get_mints` and `get_burns` return	Pushed once the CETs are on chain, or gone. A mint is usually pushed up to three times, its `txHash` arriving in a later push; a burn again only when the executions behind it complete later. Apply each by overwriting the one with the same `traceId`
`get_order`	The order as it stands now, with its mints and burns, and its executions on request	When you ask

The stream is not a record

Updates are delivered at most once, and nothing is queued for a socket that is not open. There is no backlog and no replay on reconnect: an update sent while you were disconnected is gone. get_order is what tells you where an order stands. A push carries no requestId: that is how you tell it from a reply. Two order_updated frames for one order can arrive close together; occurredAt, the broker’s time for the change, orders them. order_updated leaves out orderType, timeInForce, limitPrice, fills, mints, burns, fees and feeTotal; get_order returns them.

After a disconnect

Reconnect with backoff and open a new session.
For every order you hold as not finished, send get_order by orderId.
Update your state from status and leavesQuantity.
For orders that filled while you were away, read their CETs: each get_order answer carries mints and burns, or ask get_mints and get_burns by regulatoryId.

{
  "type": "get_order",
  "requestId": "e4404b2d7c9a4e158f3b1a6d0c5e9b72",
  "payload": { "orderId": "3396877" }
}

When an order is UNKNOWN

An ack with status: UNKNOWN means the broker never acknowledged the order. Before answering, the service already looked for it by your reference for a few seconds, and answers ACCEPTED if it turns up. What reaches you as UNKNOWN either does not exist or took longer to appear. You have no orderId, so look it up by externalRef:

{
  "type": "get_order",
  "requestId": "e4417d3e1b8f4a269c045e2a7f6b3d81",
  "payload": { "externalRef": "ref-2026-09-01-0001" }
}

Answer	Meaning	What to do
`ack` with the order	The order exists	Carry on with its `orderId`. Do not resend
`error` `ORDER_NOT_FOUND`	The broker has no order under that reference	Resend the identical `place_order`, same `externalRef`. It stays safe even if the read was behind: a reference the broker has seen is refused, never duplicated

Do the same after an error with UPSTREAM_UNAVAILABLE: the broker could not be reached and the order’s fate is unknown. get_order takes exactly one of orderId or externalRef; both, or neither, is refused. An order on another account answers ORDER_NOT_FOUND, like one that does not exist.

Cancel an order

cancel_order is a request, not a deletion: it can arrive after the order has filled. The ack says whether the request was taken; the outcome arrives as order_updated.

{
  "type": "cancel_order",
  "requestId": "b19f3a7c6e2d4f81a5b09c4e7d1f2a38",
  "timestamp": 1787900140,
  "payload": { "orderId": "3396877" },
  "signature": "Lm4x…"
}

Answer	Meaning	What to do
`ack` `PENDING_CANCEL`	Taken; the venue has not confirmed yet	Wait for `order_updated`: `CANCELLED`, or `FILLED` if the fill came first
`ack` `REJECTED`	Refused; `message` says so	Read the order
`ack` `UNKNOWN`	Never acknowledged; the cancellation may or may not be in flight	Read the order with `get_order` instead of asking again
`error` `ORDER_NOT_CANCELLABLE`	The order’s state does not allow it: already filled or cancelled	Read the order

leavesQuantity of zero means nothing is left to cancel. In sandbox every order fills at once, so every cancellation answers ORDER_NOT_CANCELLABLE.

Executions

executedQuantity says how much filled, not in how many pieces, at what prices or when. Ask for the executions with include:

{
  "type": "get_order",
  "requestId": "e442c1f08a3d4b579e264f1d7b0c3a89",
  "payload": { "orderId": "3401509", "include": ["fills"] }
}

"fills": [
  {
    "executionId": "3401509RQDCU2",
    "sequence": 2,
    "quantity": "100",
    "price": "316.85",
    "amount": "31685.00",
    "executedAt": "2026-09-02T12:04:38.192Z",
    "type": "NEW",
    "effective": true
  }
]

Ask only when you need them. A large order can have a hundred executions. Without include the field is absent, which is not the same as an empty list: an empty list means you asked and nothing has executed yet.
sequence starts at 2, not 1. Nothing is missing: the broker numbers an order’s first execution 2, and the number is part of executionId.
A busted execution stays in the list with effective: false and the broker’s word in type. The effective executions sum to executedQuantity; keep the others for the audit trail. Branch on effective, not on type.
price is what one execution filled at; the order’s executedPrice is the average across all of them.

Trades

trade_updated is the same executions seen from the broker’s ledger, where fees and settlement live.

Deduplicate on tradeId. Treat it as an opaque string: it is not a dense sequence, so a gap in it does not mean a missing trade.
Join to the order on orderRegulatoryId = the order’s regulatoryId. It is absent on a ledger row that carries no order reference.
Order by executedAt, never by arrival or occurredAt. Executions of one order arrive out of order, and the broker records an order’s executions in one batch with the same occurredAt.
price is the broker’s figure, not grossAmount divided by quantity. Amounts carry the ledger’s signs, which do not follow the trade’s direction: side says which way it went.
A correction is a new frame with brokerStatus C, not a change to the first one.
Settlement is never pushed. settled is false on arrival and no frame updates it. Use settleDate, and read cash on or after that date.

When the quantities do not add up

Every quantity is the broker’s arithmetic, passed through unchanged. If quantity, executedQuantity and leavesQuantity do not reconcile (for example, more executed than ordered), do not act on the order: treat it as a fault, stop, and contact Securitize with the traceId.

Get started

Sandbox only

Guides

Concepts

Help

API reference