> For the complete documentation index, see [llms.txt](https://docs.reya.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.reya.xyz/developers/devnet/order-entry/order-types-and-tif.md).

# Order Types & Time-in-Force

What you can express in an order today, and how each maps onto the signed `OrderDetails` (see [Signatures & Nonces](/developers/devnet/authentication/signatures-and-nonces.md)).

## Order types

| Type        | `orderType`       | Description                                                                                                                           |
| ----------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| Limit       | `LIMIT` (0)       | Rests or crosses at a limit price.                                                                                                    |
| Stop-loss   | `STOP_LOSS` (1)   | Whole-position protective stop, armed at `triggerPx`. See [Trigger Orders (SL/TP)](/developers/devnet/order-entry/trigger-orders.md). |
| Take-profit | `TAKE_PROFIT` (2) | Whole-position protective stop, armed at `triggerPx`. See [Trigger Orders (SL/TP)](/developers/devnet/order-entry/trigger-orders.md). |

Trigger orders (`STOP_LOSS` / `TAKE_PROFIT`) are **natively armed and tracked** by the matching engine: they carry a required `triggerPx`, have **no quantity** (they protect the whole live position at fire time), rest until fired or cancelled, are re-priceable in place via `modifyOrder`, and survive engine restarts. While armed they do not rest in the order book; after firing, a GTC/GTT child can rest there. The full contract — request fields, the full-position signing sentinel, lifecycle, and errors — is on the [Trigger Orders (SL/TP)](/developers/devnet/order-entry/trigger-orders.md) page.

**Trigger firing and pre-trade risk checks are live on devnet1.** A trigger chooses its fired child's TIF at creation; monitor its lifecycle and re-arm protection when needed. See [Trigger Orders (SL/TP)](/developers/devnet/order-entry/trigger-orders.md).

## Time-in-force

`timeInForce` is required for every create. It governs a `LIMIT` immediately, and selects the order a trigger becomes when it fires:

| TIF | `timeInForce` | Behaviour                                                                                                                                                                 |
| --- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| IOC | `IOC` (1)     | Immediate-or-cancel: fills what it can immediately and cancels the rest. Never rests, but an order ID is still issued — use it to reconcile fills and look up executions. |
| GTC | `GTC` (0)     | Good-till-cancelled: rests on the book until filled or cancelled. Issued an order ID.                                                                                     |
| GTT | `GTT` (2)     | Good-till-time: rests like GTC, but auto-expires at a signed `expiresAfter` timestamp (which must be strictly later than the order's `deadline`). Issued an order ID.     |

GTT couples `timeInForce` and `expiresAfter`: only GTT carries a lifetime (GTC and IOC omit `expiresAfter`), and a GTT's `expiresAfter` must be a **future** timestamp **strictly greater than** the order's `deadline`. Violating the coupling is rejected with `INPUT_VALIDATION_ERROR` (e.g. *"expiresAfter is required for GTT orders (a future timestamp greater than deadline)"*). A resting GTT **LIMIT**'s `expiresAfter` can be **refreshed** via [`modifyOrder`](/developers/devnet/order-entry/order-lifecycle.md#modifying-a-resting-order).

For a GTT trigger, the armed phase and fired child share one immutable expiry and both stop early to allow time for settlement. See [Trigger expiry](/developers/devnet/order-entry/trigger-orders.md#choosing-the-fired-childs-time-in-force); changing that expiry requires cancel-and-create.

## Reduce-only

`reduceOnly` marks an order that may only **reduce** an existing position, never flip or increase it. It applies to **perp IOC orders only**: it is **required** on perp IOC, and **not supported** on perp GTC / GTT, spot, or `STOP_LOSS` / `TAKE_PROFIT` orders. For those non-supported request types, omit the REST/WS JSON field; the signer encodes the on-chain value as `false`. See the wire-field rules in [Signatures & Nonces](/developers/devnet/authentication/signatures-and-nonces.md).

## Post-only

`postOnly` marks a **maker-only** order — one intended to **add** liquidity to the book, never take it. It is valid on **GTC / GTT** orders (spot and perp) and **rejected on IOC** (taker-only — it can never rest). A `STOP_LOSS` / `TAKE_PROFIT` create may omit it or send `false`; `true` is rejected. Sign it as `false` when you don't want post-only behaviour. See the wire-field rules in [Signatures & Nonces](/developers/devnet/authentication/signatures-and-nonces.md).

Post-only is **enforced by the matching engine**: if a post-only order's entry would cross *or touch* the best opposite price it is rejected with `POST_ONLY_WOULD_CROSS_ERROR` and nothing is placed (the book is left untouched); once resting, a post-only maker fills normally when a later taker crosses it.

## Amendment

`modifyOrder` is live for a resting `LIMIT` order (`GTC` / `GTT`) and an armed `STOP_LOSS` / `TAKE_PROFIT` trigger. It is a **full restate** of the order's `OrderDetails`; the modifiable set is class-split — `limitPx`, `qty`, `postOnly`, `expiresAfter` for a `LIMIT` order, and **only `limitPx` + `triggerPx`** for a trigger — with every other signed field immutable. See [Order Lifecycle](/developers/devnet/order-entry/order-lifecycle.md#modifying-a-resting-order) for the full semantics.