Skip to main content
Orders are placed over the Order Creation Stream, or over the REST 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 Creation Stream. You receive an acknowledgment that the request was received and validated.
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 Creation 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 Creation Stream.

​
Placing Orders over REST

The REST 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.
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 everything you still have resting on the book, across every contract.
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.
The Order Creation 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 REST, 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.