Order Types & Time-in-Force

What you can express in an order today, and how each maps onto the signed OrderDetails (see Signatures & Nonces).

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).
Take-profit	TAKE_PROFIT (2)	Whole-position protective stop, armed at triggerPx. See Trigger Orders (SL/TP).

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) page.

Trigger firing and pre-trade risk checks are live. A trigger chooses its fired child's TIF at creation; monitor its lifecycle and re-arm protection when needed. See Trigger Orders (SL/TP).

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.

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

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.

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 for the full semantics.