Skip to main content
Orders are placed over the Order Management Stream, or over the HTTP order endpoints. Both reach the same matching engine and accept the same order types and flags; they differ in how you learn the outcome.

​
Order Types

Only limit and market orders are supported — there are no trigger (stop-loss / take-profit) orders, and leverage and margin-mode updates do not apply. Attempting these is rejected.

​
Order Flags

​
Lifecycle

A successful order moves through the same states on either transport. You can correlate every message for one order using its clientRequestId.

​
Placing Orders over WebSocket

1

Create

Submit a Create Order request via the Order Management Stream. You receive an acknowledgment that the request was received and validated. You may send your own orderId, a ULID; one is generated if you do not.
2

Accept

The matching engine accepts the order and it becomes active on the book (for a limit order) — confirmed by a follow-up response.
3

Fill

As the order matches, you receive Order Filled notifications on the Order Management Stream (partial and complete), and your Positions Stream and Account Summary Stream update.
4

Modify or cancel

Adjust an open order with a Modify Order request, or remove it with a Cancel Order By ID request, both via the Order Management Stream.

​
Placing Orders over HTTP

The HTTP endpoints suit a client that does not hold a WebSocket connection open. Create, modify and cancel are asynchronous: a 202 means the request was queued, not that the engine accepted it, so every one of them answers queued: true and accepted: false. The engine’s decision is read back separately.
1

Submit

Call Create Order, Modify Order or Cancel Order. Each answers with the orderId to poll. On create you may send your own orderId; one is generated if you do not. Cancel All Orders queues one cancel per open order — for every contract, or one contract — and answers with the list of cancels queued, each with its own orderId and clientRequestId.
2

Poll

Call Get Order Status with that orderId until the status is terminal — completed, cancelled, rejected or not_found. A rejected order carries a reason.
3

List

Get Open Orders returns your resting orders across every contract, most recently created first, 200 per page by default. Set pageSize to request up to 1,000 orders per page and follow nextPageToken until it is absent.
Behavior worth knowing before you build against these endpoints:
  • Order state expires. Get Order Status answers 404 one hour after an order’s last update. Track anything you need for longer yourself.
  • clientRequestId correlates a request with its outcome. Send your own — it is echoed on the 202 and on every status read. One is generated if you omit it.
  • A modification changes price and quantity only. Side, type, and the postOnly and reduceOnly flags are kept from the order being replaced, and the new quantity may not be below the quantity already filled.
  • A 502 or a 504 leaves the outcome unknown. Neither answer tells you whether the request reached the matching engine, so resubmitting can duplicate an order. Send your own orderId on create and check it with Get Order Status, or look for the order on Get Open Orders, before retrying.
  • quantity is the full order quantity. On Get Open Orders the unfilled amount is quantity minus filledQuantity; Get Order Status reports it directly as remainingQuantity.
  • Cancel All Orders is a batch of independent cancels. Each entry in cancels settles on its own: poll Get Order Status per orderId, or watch the Open Orders Stream drain. An order that fills before the engine reaches its cancel reports not_found. The sweep costs one unit of its own budget however many orders it cancels, separate from single cancels, so a caller that has spent the cancel budget can still close out; see Rate Limits. If the queue refuses part-way, the response still lists what was queued in cancels (and counts only those in count), and names the orders it could not reach in unqueued. Those orders are still open, so send the sweep again: the ones already queued then report not_found. The same request is available over WebSocket — see Releasing Capital on Disconnect for when to use which.
The Order Management Stream remains the lower-latency path, and pushes fills without polling.

​
Order Statuses

​
Tracking Orders

Track open orders on the Open Orders Stream and recent order history on the Recent Orders Stream. Over HTTP, Get Open Orders returns what is still resting on the book, and Get Recent Orders returns orders that were filled or cancelled (selected with status). Filled orders carry a fillType of complete or partial. If a request times out or you miss an acknowledgment, verify the outcome before retrying. See FAQs for safe-retry guidance and Rate Limits for how to back off when throttled.