# Market and order status


Source: https://docs.stxapp.io/concepts/market-status/

A market has one of **seven** stored statuses. These are the values `?status=`
accepts, lowercase, comma-separated, e.g. `?status=open,pre_open`.

| Status | Meaning |
| --- | --- |
| `scheduled` | Created and ready to pre-open. No orders accepted yet. |
| `pre_open` | Accepts limit orders ahead of open. No trades, and no market orders. |
| `open` | Open for all orders and trades. |
| `closed` | The result is known. No new orders; pending orders are cancelled. Awaiting confirmation by STX, or a delayed feed. |
| `resulted` | Result confirmed. Settlements generated for all trades. |
| `cancelled` | Cancelled. No new orders; pending orders are cancelled. Awaiting confirmation. |
| `voided` | Cancellation confirmed. Void settlements generated. |

An uppercase value returns `400`. Omit the parameter entirely and you get every
non-archived market, not just the open ones.

## `suspended` is not one of them

A response's `status` field can read **`suspended`**, which is not in the list
above and cannot be filtered on. It is derived at render time:

```text
trading == false  AND  status in (open, pre_open)   ->   suspended
```

So a market returned by `?status=open` can report `"status": "suspended"`. The
filter is not wrong, that market genuinely *is* open, it simply is not taking
trades at this moment.

The two fields answer different questions:

| Field | Answers |
| --- | --- |
| `status` | Where the market is in its lifecycle |
| `trading` | Whether it is accepting orders **right now** |

A market you can actually trade against has `status: open` **and**
`trading: true`.

Ask for exactly those with both filters:

```python
tradeable = get("/api/v1/markets?status=open&trading=true")["markets"]
```

`?status=pre_open&trading=true` gets you the markets that are not matching yet
but do accept resting limit orders.

:::tip[Tradeable markets come back first]
`GET /api/v1/markets` orders its results tradeable-first (`open` and trading,
then `pre_open` and trading, then suspended markets, `scheduled`,
`closed`/`cancelled`, and finally settled markets), with the soonest event first
within each tier. So the first page is the tradeable one even without a filter.
:::

## Order statuses

An order has one of **nine** statuses. They are a different set from the market
ones above. In practice you mostly see the last five, because the first four are
normally transient.

| Status | Meaning |
| --- | --- |
| `created` | Stored, but not yet checked against your limits or available balance. |
| `requested` | Passed the account checks and handed to the market. |
| `accepted` | The market accepted it; not yet run against the book. |
| `delayed` | Accepted, but held before further processing, see the in-play delay on the market. |
| `open` | Resting on the book and available to be filled. |
| `filled` | The entire quantity has been filled. |
| `rejected` | Refused, either on the account checks or by the market. Read `rejection_reason`. |
| `cancelled` | Cancelled with no quantity filled. |
| `partially_cancelled` | Cancelled after part of the order had already traded. The trades it already created stand. |

`created`, `requested`, `accepted` and `delayed` are normally transient, an order
moves through them in the time it takes the request to return, so a resting order
you placed will usually read `accepted` in the `POST` response and `open` by the
time you query it.

`filled`, `rejected`, `cancelled` and `partially_cancelled` are terminal.

### Which statuses mean the order is still live

Branch on this rather than on `open` alone:

| | Statuses |
| --- | --- |
| **Live**: working, cancellable, holding liability | `created`, `requested`, `accepted`, `delayed`, `open` |
| **Done**: no longer working | `filled`, `rejected`, `cancelled`, `partially_cancelled` |

:::caution[`accepted` is not transient on a `pre_open` market]
A `pre_open` market takes limit orders but has no live book for them to rest on,
so an order stays `accepted` until the market opens rather than moving to `open`
in the next moment.

That breaks the obvious reconciliation. `GET /api/v1/orders?status=open` returns
an empty list while the account holds live, cancellable orders consuming
balance, which reads as flat. A strategy that places its orders again on that
answer doubles its position. Treat every status in the **Live** row as working, and do not use
`status=open` to mean "my resting orders".
:::
`partially_cancelled` is the one to handle explicitly: it means you have trades
from an order you cancelled, so reconcile the fills rather than assuming a
cancel left you flat.

## Events have their own statuses

Do not confuse these with event status, which is a separate, shorter set:
`scheduled`, `in_progress`, `completed`, `cancelled`. A market carries its
event's status alongside its own as `event_status`.