--- title: Placing Orders description: Place, confirm, amend, and cancel an order over REST or WebSocket, with private streams for its lifecycle and fills. --- An order is an instruction to buy or sell YES contracts at a limit price. For time in force, post-only, self-trade prevention, and what each status means, see [Order Entry](/concepts/order-entry). This walkthrough shows the operations. It assumes the environment and API key from the [Quick Start](/quick-start). Every order write is [asynchronous](/reference/asynchronous-writes): the response confirms the exchange accepted the submission, and the outcome is read from the order afterward. ## Place an Order **REST** [Place the order](/api-reference/rest/orders/create-order) with the market's `ticker`, your `client_order_id`, a `side`, a `price` on the market's tick, a `quantity` in contracts, and a `time_in_force`: ```json { "ticker": "UDX-EXAMPLE-MARKET", "client_order_id": "my-order-1", "side": "buy", "price": "0.55", "quantity": "100", "time_in_force": "gtc" } ``` Add `post_only: true` to be rejected rather than fill on arrival, `self_trade_prevention_type` to choose which of your own orders gives way, and `account_id` when the key is not restricted to one account. The `202 Accepted` response carries the exchange-assigned `order_id` and echoes your `client_order_id`. The [Quick Start](/quick-start#place-an-order) shows the signed request end to end. **WebSocket** Subscribe to the private `orders` channel before you place the order, so the order's lifecycle lands on the same connection. Then [place the order](/api-reference/websocket/orders/receive-create-order-command) with `create_order`, carrying the same fields as the REST body: ```json { "id": 2, "cmd": "create_order", "params": { "ticker": "UDX-EXAMPLE-MARKET", "client_order_id": "my-order-1", "side": "buy", "price": "0.55", "quantity": "100", "time_in_force": "gtc" } } ``` The same optional fields apply: `post_only`, `self_trade_prevention_type`, and `account_id` when the key is not restricted to one account. The `order_create_submitted` response carries the exchange-assigned `order_id` and echoes your `client_order_id` — the exchange accepted the submission, not the outcome: ```json { "id": 2, "type": "order_create_submitted", "msg": { "order_id": "45c48cce", "client_order_id": "my-order-1" } } ``` The order's committed state — resting, filled, or rejected — arrives on the `orders` subscription, which is independent of the command reply: correlate by `order_id` and `client_order_id`, never by frame order. [Asynchronous Writes](/reference/asynchronous-writes) covers reading outcomes, error frames, and retrying safely. ## Confirm an Order and Its Fills **REST** [Poll the order](/api-reference/rest/orders/get-order) by its `order_id` until it reaches the status you expect: | Status | Meaning | | ------------------ | ---------------------------------------------------- | | `resting` | On the book with nothing filled yet. | | `partially_filled` | On the book with some quantity filled. | | `filled` | Completely filled. | | `canceled` | Canceled before filling completely. | | `expired` | Its time in force ended before it filled completely. | | `rejected` | Rejected by the exchange. | [List your orders](/api-reference/rest/orders/list-orders) filtered by `client_order_id`, `ticker`, or `status` to see every order with working orders first. Choose one status; `resting` with `partially_filled`; or all four terminal statuses together. Repeat `status` for each selected value; other combinations return `400`. A short or empty page can still carry `next_page_url`, so continue until it is `null`. [List your fills](/api-reference/rest/portfolio/get-fills) for executions, correlated by `client_order_id`. **WebSocket** Subscribe to `orders` and `fills` in one command before placing the order. The private channels contain only the authenticated caller's data. Filter both channels to a catalog ticker when appropriate; omit `tickers` to receive every order and execution you can see, including combination orders. ```json { "id": 1, "cmd": "subscribe", "params": { "channels": [ { "channel": "orders", "tickers": ["UDX-EXAMPLE-MARKET"] }, { "channel": "fills", "tickers": ["UDX-EXAMPLE-MARKET"] } ] } } ``` Each channel receives its own `subscribed` response and `sid`. ## Amend the Order An amendment replaces the order's `price` and `quantity` (totals, not deltas) and keeps its `order_id`; only a quantity decrease at an unchanged price keeps queue priority. **REST** [Amend the order](/api-reference/rest/orders/amend-order) by its `order_id`: ```json { "ticker": "UDX-EXAMPLE-MARKET", "quantity": "80", "price": "0.55" } ``` The `202 Accepted` response echoes the `order_id`; poll the order for the new values. **WebSocket** [Amend the order](/api-reference/websocket/orders/receive-amend-order-command) with `amend_order`, naming its `order_id`: ```json { "id": 3, "cmd": "amend_order", "params": { "order_id": "45c48cce", "ticker": "UDX-EXAMPLE-MARKET", "quantity": "80", "price": "0.55" } } ``` The `order_amend_submitted` response echoes the `order_id` — the exchange accepted the submission, not the outcome. An `order_id` that is unknown, or not yours, answers an `order_not_found` error, exactly as over REST. ## Cancel the Order A cancellation addresses the order by its `order_id` and names its `ticker`. An order that fills while the cancellation is in flight is unaffected. A WebSocket `orders` subscription delivers an `order_canceled` frame for each order as its cancellation lands. **REST** [Cancel the order](/api-reference/rest/orders/cancel-order) by its `order_id`, naming its `ticker` in the query: ```http DELETE /orders/{order_id}?ticker=UDX-EXAMPLE-MARKET ``` The response echoes the `order_id`; poll the order until it reads `canceled`. **WebSocket** [Cancel the order](/api-reference/websocket/orders/receive-cancel-order-command) with `cancel_order`: ```json { "id": 4, "cmd": "cancel_order", "params": { "order_id": "45c48cce", "ticker": "UDX-EXAMPLE-MARKET" } } ``` The `order_cancel_submitted` response echoes the `order_id` — the exchange accepted the submission, not the outcome. An `order_id` that is unknown, or not yours, answers an `order_not_found` error, exactly as over REST. Bulk cancellation is a REST request: [cancel every open order](/api-reference/rest/orders/cancel-orders) the credential can act for, narrowed by `ticker` or `account_id` if you wish. It returns no body; poll [your working orders](/api-reference/rest/orders/list-orders) with `status=resting&status=partially_filled` and the same filters until none remain, or watch the `orders` subscription.