Skip to main content
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 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:
ModeWhat to expect
normalTrading is open. This is represented by no active trading restriction in the status response.
post_onlyOnly post-only order creation and cancellations are expected to succeed. Orders that would take liquidity may be rejected.
cancel_onlyNew order creation is unavailable. Cancellations are expected to remain available.
disabledOrder creation and cancellation are unavailable.

​
Trading behavior by mode

Use the active trading effect to decide which actions your integration should attempt.
Active trading modeCreate regular ordersCreate post-only ordersCancel orders
No active effect (normal)AllowedAllowedAllowed
post_onlyBlockedAllowedAllowed
cancel_onlyBlockedBlockedAllowed
disabledBlockedBlockedBlocked
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:
FieldMeaning
activeRestrictions currently in effect. Integrations should apply these immediately.
scheduledFuture 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.
1

Read maintenance status

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

Apply active restrictions

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

Show scheduled notices

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

Handle trading endpoint failures

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

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