Maintenance Mode

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 when your app starts and refresh it before submitting trading actions. Bots and partner backends should also handle 425 Too Early responses with a trading-mode code 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 425 Too Early with a trading-mode code. 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

Read maintenance status

Call GET /maintenance/status?target=trading to get trading-specific maintenance information.

Apply active restrictions

If active contains a trading effect, adjust your UI or bot behavior to the reported mode.

Show scheduled notices

If scheduled contains entries, surface the publicMessage, startsAt, and endsAt values to users or operators.

Handle trading endpoint failures

If a trading request returns 425 with a trading-mode code, stop retrying the same action immediately and refresh maintenance status. Retry only when the mode allows that action again.

Example

{
  "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 425 Too Early. Treat this as an exchange state signal, not as a malformed request. For POST /orders, 425 is also used by receive-window checks. Use the response body to distinguish the cases: a trading-mode code means maintenance mode; a receive-window response does not include that code.

`425` maintenance examples

post_only blocks non-post-only order creation. Cancellations and post-only orders are expected to remain available.

{
  "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.

{
  "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.

{
  "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.
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.

Getting Started

Quick Start

TypeScript SDK

Python SDK

Go SDK

Rust SDK

WebSocket

When to check status

Trading modes

Trading behavior by mode

Active vs scheduled maintenance

Recommended integration behavior

Example

Error handling

`425` maintenance examples

​When to check status

​Trading modes

​Trading behavior by mode

​Active vs scheduled maintenance

​Recommended integration behavior

​Example

​Error handling

​425 maintenance examples

When to check status

Trading modes

Trading behavior by mode

Active vs scheduled maintenance

Recommended integration behavior

Example

Error handling

`425` maintenance examples