> ## Documentation Index
> Fetch the complete documentation index at: https://docs.limitless.exchange/llms.txt
> Use this file to discover all available pages before exploring further.
# Maintenance Mode
> How integrations should handle temporary trading restrictions and maintenance notices
Maintenance mode lets Limitless temporarily restrict trading actions during planned maintenance, incidents, or other operational events. Integrations should treat it as part of normal exchange availability and check it before placing or cancelling orders.
Maintenance mode is public status information. It does not require authentication.
## When to check status
Call [`GET /maintenance/status`](/api-reference/system/maintenance-status) when your app starts and refresh it before submitting trading actions. Bots and partner backends should also handle `503 Service Unavailable` responses from trading endpoints, because active restrictions can change after your last status check.
## Trading modes
Maintenance status is reported through `effects`. For trading, the possible `mode` values are:
| Mode | What to expect |
| ------------- | -------------------------------------------------------------------------------------------------------------------------- |
| `normal` | Trading is open. This is represented by no active trading restriction in the status response. |
| `post_only` | Only post-only order creation and cancellations are expected to succeed. Orders that would take liquidity may be rejected. |
| `cancel_only` | New order creation is unavailable. Cancellations are expected to remain available. |
| `disabled` | Order creation and cancellation are unavailable. |
## Trading behavior by mode
Use the active trading effect to decide which actions your integration should attempt.
| Active trading mode | Create regular orders | Create post-only orders | Cancel orders |
| --------------------------- | --------------------- | ----------------------- | ------------- |
| No active effect (`normal`) | Allowed | Allowed | Allowed |
| `post_only` | Blocked | Allowed | Allowed |
| `cancel_only` | Blocked | Blocked | Allowed |
| `disabled` | Blocked | Blocked | Blocked |
When an action is blocked by maintenance mode, trading endpoints can return `503 Service Unavailable`. Do not retry the same blocked action in a tight loop. Refresh maintenance status and wait until the active mode allows the action again.
If a market uses taker delay, a taker order may already be accepted with `execution.settlementStatus: "DELAYED"` before maintenance starts. Active maintenance can postpone the delayed fill past its `eligibleAt` timestamp. Do not treat that gap as a failed order; keep listening for order events and reconcile on the terminal `MINED` or `FAILED` event.
## Active vs scheduled maintenance
The status response has two arrays:
| Field | Meaning |
| ----------- | ------------------------------------------------------------------------------------------- |
| `active` | Restrictions currently in effect. Integrations should apply these immediately. |
| `scheduled` | Future maintenance notices. These help you warn users or adjust bot behavior ahead of time. |
Scheduled entries are notices. They tell you what is planned and when, but your integration should still rely on `active` and trading endpoint responses for the current enforced state.
## Recommended integration behavior
Call `GET /maintenance/status?target=trading` to get trading-specific maintenance information.
If `active` contains a trading effect, adjust your UI or bot behavior to the reported mode.
If `scheduled` contains entries, surface the `publicMessage`, `startsAt`, and `endsAt` values to users or operators.
If a trading request returns `503`, stop retrying the same action immediately and refresh maintenance status. Retry only when the mode allows that action again.
## Example
```json theme={null}
{
"active": [
{
"startsAt": "2026-06-22T15:00:00.000Z",
"endsAt": "2026-06-22T18:00:00.000Z",
"publicMessage": "Trading is temporarily limited to cancellations.",
"effects": [{ "target": "trading", "mode": "cancel_only" }]
}
],
"scheduled": [
{
"startsAt": "2026-06-22T18:00:00.000Z",
"endsAt": "2026-06-22T19:00:00.000Z",
"publicMessage": "Trading will be post-only during the next maintenance stage.",
"effects": [{ "target": "trading", "mode": "post_only" }]
}
]
}
```
## Error handling
When a trading action is blocked by maintenance mode, trading endpoints can return `503 Service Unavailable`. Treat this as an exchange state signal, not as a malformed request.
### `503` examples
`post_only` blocks non-post-only order creation. Cancellations and post-only orders are expected to remain available.
```json theme={null}
{
"code": "post_only_mode",
"message": "Trading is currently post-only. Only post-only orders and cancels are allowed.",
"mode": "post_only",
"resumeAt": "2026-06-22T18:00:00.000Z"
}
```
`cancel_only` blocks new order creation. Cancellations are expected to remain available.
```json theme={null}
{
"code": "cancel_only_mode",
"message": "Trading is currently cancel-only. New orders are not accepted, but cancels are allowed.",
"mode": "cancel_only",
"resumeAt": "2026-06-22T18:00:00.000Z"
}
```
`disabled` blocks both order creation and cancellations.
```json theme={null}
{
"code": "trading_disabled",
"message": "Trading is currently disabled.",
"mode": "disabled",
"resumeAt": "2026-06-22T18:00:00.000Z"
}
```
`resumeAt` may be omitted if no expected end time is available.
Recommended behavior:
* Refresh [`GET /maintenance/status?target=trading`](/api-reference/system/maintenance-status).
* Do not keep submitting blocked order actions in a tight loop.
* Continue actions that are allowed by the current mode, such as cancellations during `cancel_only`.
* For delayed taker orders, keep waiting for order events if maintenance is active when `eligibleAt` passes.
* Resume normal trading only after status and endpoint responses indicate trading is available again.