> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rails.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Order Lifecycle

> Order types, flags, and the lifecycle of an order

Orders are placed over the
[Order Creation Stream](/latest/options/websocket-api/order-creation-stream), or over the
[REST order endpoints](#placing-orders-over-rest). Both reach the same matching engine and
accept the same order types and flags; they differ in how you learn the outcome.

## Order Types

| Type     | Behavior                                                              |
| -------- | --------------------------------------------------------------------- |
| `limit`  | Executes only at the specified price or better; may rest on the book. |
| `market` | Executes immediately against the best available prices.               |

<Note>
  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.
</Note>

## Order Flags

| Flag          | Type    | Description                                                                                             |
| ------------- | ------- | ------------------------------------------------------------------------------------------------------- |
| `postOnly`    | boolean | Maker-only. The order is rejected if it would match immediately. Limit orders only.                     |
| `reduceOnly`  | boolean | The order may only reduce or close an existing position, never open or increase one. Used when closing. |
| `maxSlippage` | string  | Market orders only — caps how far the fill price may deviate from the expected price.                   |

## 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

<Steps>
  <Step title="Create">
    Submit a Create Order request via the
    [Order Creation Stream](/latest/options/websocket-api/order-creation-stream).
    You receive an **acknowledgment** that the request was received and validated.
  </Step>

  <Step title="Accept">
    The matching engine accepts the order and it becomes active on the book (for a limit
    order) — confirmed by a follow-up response.
  </Step>

  <Step title="Fill">
    As the order matches, you receive Order Filled notifications on the
    [Order Creation Stream](/latest/options/websocket-api/order-creation-stream)
    (partial and complete), and your
    [Positions Stream](/latest/options/websocket-api/positions-stream) and
    [Account Summary Stream](/latest/options/websocket-api/account-summary-stream) update.
  </Step>

  <Step title="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](/latest/options/websocket-api/order-creation-stream).
  </Step>
</Steps>

### 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.

<Steps>
  <Step title="Submit">
    Call [Create Order](/latest/options/rest-api/create-order),
    [Modify Order](/latest/options/rest-api/modify-order) or
    [Cancel Order](/latest/options/rest-api/cancel-order). Each answers with the `orderId` to
    poll. On create you may send your own `orderId`; one is generated if you do not.
  </Step>

  <Step title="Poll">
    Call [Get Order Status](/latest/options/rest-api/get-order-status) with that `orderId` until
    the status is terminal — `completed`, `cancelled`, `rejected` or `not_found`. A rejected
    order carries a `reason`.
  </Step>

  <Step title="List">
    [Get Open Orders](/latest/options/rest-api/get-open-orders) returns everything you still have
    resting on the book, across every contract.
  </Step>
</Steps>

Behavior worth knowing before you build against these endpoints:

* **Order state expires.** [Get Order Status](/latest/options/rest-api/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](/latest/options/rest-api/get-order-status), or look
  for the order on [Get Open Orders](/latest/options/rest-api/get-open-orders), before retrying.
* **`quantity` is the full order quantity.** On
  [Get Open Orders](/latest/options/rest-api/get-open-orders) the unfilled amount is `quantity`
  minus `filledQuantity`; [Get Order Status](/latest/options/rest-api/get-order-status) reports
  it directly as `remainingQuantity`.

The [Order Creation Stream](/latest/options/websocket-api/order-creation-stream) remains the
lower-latency path, and pushes fills without polling.

## Order Statuses

| Status      | Meaning                                                                                                                                    |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| `pending`   | Request received, awaiting acceptance by the matching engine.                                                                              |
| `accepted`  | Taken by the matching engine; the terminal status follows. Reported by [Get Order Status](/latest/options/rest-api/get-order-status) only. |
| `open`      | Live on the order book (limit orders).                                                                                                     |
| `completed` | Fully filled, or a market order finished executing.                                                                                        |
| `cancelled` | Cancelled — by you, an admin, or the system.                                                                                               |
| `rejected`  | Rejected — see the accompanying error.                                                                                                     |
| `not_found` | The engine had no such order to modify or cancel. Reported by [Get Order Status](/latest/options/rest-api/get-order-status) only.          |

## Tracking Orders

Track open orders on the [Open Orders Stream](/latest/options/websocket-api/open-orders-stream)
and recent order history on the [Recent Orders Stream](/latest/options/websocket-api/recent-orders-stream).
Over REST, [Get Open Orders](/latest/options/rest-api/get-open-orders) returns what is still
resting on the book, and [Get Recent Orders](/latest/options/rest-api/get-account-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](/latest/options/guides/faqs) for safe-retry guidance and
[Rate Limits](/latest/options/guides/rate-limits) for how to back off when throttled.