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

# Order types

The eight order types and four time-in-force policies, and what each one requires.

The exchange supports **eight order types** and **four time-in-force policies**. Two of the eight are unconditional and act the moment they are accepted. The other six are **conditional**. They rest inert until the mark price satisfies a trigger, then fire as either a limit or a market order.

This page is the trader's view. For the exact request shape, meaning which fields each type requires and the wire types, see [Order Types](https://docs.nexus.xyz/api-reference/guides/order-types) and the per-endpoint pages in the API Reference section, which are generated from the contract.

### Unconditional

* **Market.** Executes immediately against resting liquidity. Any unfilled size is cancelled.
* **Limit.** Rests on the order book at your chosen price until filled or cancelled, and fills at that price or better.

### Conditional

All six trigger off the **mark price**, not the last trade. See [Price oracles](/trading/trading/perpetuals/price-oracles.md). Each pairs a trigger with what it fires, so the choice is two decisions: *when* and *as what*.

| Order type             | Triggers when the mark…                                   | Fires as |
| ---------------------- | --------------------------------------------------------- | -------- |
| **Stop Limit**         | crosses your trigger price in the **adverse** direction   | Limit    |
| **Stop Market**        | crosses your trigger price in the **adverse** direction   | Market   |
| **Take Profit Limit**  | crosses your trigger price in the **favorable** direction | Limit    |
| **Take Profit Market** | crosses your trigger price in the **favorable** direction | Market   |
| **Trailing Stop**      | retraces from its best-seen extreme by your offset        | Market   |
| **Trailing Limit**     | retraces from its best-seen extreme by your offset        | Limit    |

**Stop and take-profit orders differ only in trigger direction.** Both take a `trigger_price`; a stop fires when the market moves against your position, a take-profit when it moves in your favour. Use a stop to cap a loss, a take-profit to realize a gain without watching the book.

**Trailing orders take an offset instead of a fixed trigger.** Set `trailing_offset_bps` and the trigger follows the mark price at that distance, tightening as the market moves your way and never loosening when it moves against you. It fires once the mark retraces from its best-seen extreme by the offset. `TrailingLimit` also takes `limit_offset_bps`, which prices the limit order relative to the price that fired it.

The limit-firing types (`StopLimit`, `TakeProfitLimit`) also require a limit `price`; the market-firing types do not take one.

> Use `trigger_price` for the trigger threshold. The older `stop_price` field is deprecated. It is still accepted as a fallback when `trigger_price` is absent, and ignored when both are sent.

### Time in force

Required on every order.

| Value                         | Meaning                                                                                                                          |
| ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| **GTC** (Good-Till-Cancelled) | Rests on the book until filled or cancelled.                                                                                     |
| **IOC** (Immediate-or-Cancel) | Fills what it can immediately, cancels the remainder.                                                                            |
| **FOK** (Fill-or-Kill)        | Fills in full immediately, or is cancelled entirely.                                                                             |
| **PostOnly**                  | Rejected if it would take liquidity on entry, so a filled order is **guaranteed to be a maker fill** and earns the maker rebate. |

`PostOnly` is the policy market makers should quote with, because it makes an accidental taker fill impossible. See the [Market maker guide](/apis-and-rates/apis-and-rates/market-maker-guide.md).

### Modifiers

* **Reduce-only.** Set `reduce_only: true` and the order can only decrease your current position, never increase or flip it.

### Before you send

* **Preview an order** with `POST /orders/preview` to see the margin, equity, fee and liquidation-price impact without submitting it.
* **Amend a resting order** with `PATCH /orders/{order_id}`, an atomic cancel-replace of price and/or size. The replacement carries a **new order id**.
* **Submit in bulk** with `POST /orders/batch`. Orders are processed sequentially and **non-atomically**: an earlier order consuming margin can cause a later one in the same batch to fail, and the batch returns a per-order result you must inspect.

### Planned

* **GTD (Good-Till-Date).** Rests until a chosen expiry or until the order fills.
* **Market-close orders.** Sized automatically to fully close your current position.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.nexus.xyz/trading/trading/perpetuals/order-types.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.