200 even when nothing was cancelled, so a 200
alone never confirms an order is off the book — you have to check the response body, and what the
body can tell you differs by route:
Cancelling asynchronously
Cancel by id is synchronous. The route waits up to 5 seconds for the matching engine to act before responding, and reportscancelled or notCancelled per order — plus a third bucket,
unconfirmed, for when the matching engine’s answer doesn’t arrive within that window.
Cancel-all and cancel-by-event are asynchronous. Both routes return as soon as the matching
engine accepts the cancel commands, before your orders are actually off the book. The response’s
cancelledSubmitted list names which commands were accepted; nothing in the response confirms the
orders are gone.
Choosing a route
Use cancel by id when you know what you want gone: repricing a level, pulling one side, reacting to a fill. Use cancel by event for reacting to event-level changes Use cancel-all as a circuit breaker in case everything needs to be immediately cancelled.Watching cancels land
For the asynchronous endpoints, the direct signal is theaccount:orders_v3_#{address} channel: when the
matching engine removes your order, you get an update with status: "INACTIVE" and
inactiveReason: "USER_REQUESTED".
See Real-time data and Tracking your orders.
Cancels from elsewhere
Orders sometime leave the book without you cancelling them, andinactiveReason says why. See the full table
Related
Cancel orders by id
Cancel all orders
Cancel orders by event
Heartbeat
Arming the switch that cancels for you when your process stops.