Exchange API trading modes: what each status permits

Exchange API trading modes and status determine which operations a venue or instrument currently permits. Read new-order admission, cancellation and matching as separate capabilities, then check the exact venue, product and status source. Online does not guarantee that a particular account can trade, and similarly named cancel-only, post-only or limit-only states can have different documented behavior across exchanges.

Identify what the status describes

A system status, a product status and an order status answer different questions. The first describes an engine or service; the second describes an instrument; the third describes a particular instruction already submitted. Keep their scopes attached when storing or displaying them.

Kraken's WebSocket v2 engine status lists online, maintenance, cancel_only and post_only. Its instrument channel separately publishes a pair status, whose documented values also include limit_only, reduce_only and delisted. A client that reads only the engine message has not checked every instrument restriction. Kraken engine status, Kraken instrument reference data.

Account permissions, available funds and valid order parameters remain separate admission conditions. A normally operating engine cannot make an unsupported account action valid. The connection-health guide explains how to record the account, environment and age of the observations supporting a decision.

This article focuses on interpreting the current capability state. Use the established exchange-maintenance restart plan for preparation, interrupted signals and reconciliation after an outage.

Compare capabilities instead of translating labels

The following matrix preserves the source and scope of each definition. “Available” means permitted by the described mode, subject to the venue's other rules; it does not promise that an individual request succeeds.

The Kraken rows follow its published trading-mode definitions. The Coinbase row follows its Exchange product-mode documentation.

That last distinction matters operationally. “Limit only” cannot safely become a shared internal rule meaning “accept orders but expect no fills.” Store what the documented venue state permits. Keep an unfamiliar state unresolved until the relevant interface and current venue guidance explain it.

Kraken's support table includes limit-only, while the WebSocket engine enum above does not list that value. The pair-status enum does. Do not add an undocumented engine enum merely because a support article describes the mode; identify the surface actually reporting the restriction.

A post-only market phase also differs from a post-only order option during normal trading. The phase can suspend matching across the affected market. The individual option constrains how one order may enter. The post-only and time-in-force guide covers order-level behavior and remaining quantities.

Read the full product record before allowing an order

Coinbase Exchange exposes product mode flags alongside its status field. Its documentation says at most one of trading_disabled, cancel_only, post_only and limit_only can be true; when none is true, it describes the product as trading normally. It separately exposes auction_mode. A decoder should preserve these fields rather than reducing the record to one green label. Coinbase Exchange product fields.

Use that documented exclusivity as a consistency check for this API. If a supposedly complete record contains two active mode flags, mark the interpretation invalid and refresh through a supported source. Do not invent precedence rules that silently choose the least restrictive flag. Equally, do not let all-false flags override an offline or unresolved product status.

Likewise, a missing flag is not automatically false. Establish whether that endpoint promises a full record, an update containing only changed fields, or an optional property. The separate missing, null and zero field guide explains why defaulting an absent field can change the meaning of a response.

An auction indication also needs its own treatment. A mode adapter should preserve that phase rather than assuming every permitted order immediately enters continuous matching. The call-auction guide covers indicative prices, cancellation cutoffs and allocation.

Worked example: limit-only can still produce exposure

Consider an illustrative spot product using the Coinbase Exchange limit-only definition above. Assume continuous matching is active, with four fictional ABC available at 100.10 USD and the next ask at 100.40. A valid, funded good-till-canceled buy seeks five ABC with a limit of 100.20. Ignore fees, hidden liquidity, other traders and all additional restrictions.

The instruction is a limit order, so it meets the mode's order-type condition. In this frozen example, four ABC can execute at 100.10. Their gross cost is 4 × 100.10 = 400.40 USD. The remaining 5 − 4 = 1 ABC stays working at 100.20 under the stated good-till-canceled assumption.

The account therefore has both an acquired holding and a continuing order commitment. Limit-only did not mean maker-only, zero fills or a completed five-unit purchase. The fifth unit's limit price is also not evidence that it already traded at 100.20.

Now apply Kraken's published limit-only definition instead: matching is paused, so that immediate four-unit execution must not be inferred. These are separate modeled outcomes under separate venue definitions, not predictions about a live order book.

An application should retain the observed mode with the attempted order, then reconcile actual execution evidence. An acknowledgement does not supply the missing fills; see ACK, RESULT and FULL response distinctions for the separate question of what a submission response proves.

Build an action decision from scoped evidence

A useful local policy evaluates the proposed operation explicitly: cancel, amend, submit a passive limit, submit a crossing limit or submit a market order. Amendments need their own documented mapping. Permission to cancel and permission to place a new order do not establish that an amend endpoint is available or atomic.

For each decision, preserve:

• Venue, environment, product and instrument identity.
• Raw mode fields, their source, receipt time and any source timestamp.
• The proposed operation, order type and relevant options.
• The adapter rule that interpreted those fields.
• The resulting allow, block or unresolved decision and its reason.

Combine applicable restrictions. A system allowing normal operation cannot override a pair restriction. A permissive pair observation cannot override an account block. Contradictory or incomplete evidence should prevent new exposure until it is resolved; keep cancellation and protective-action decisions separate so a broad “paused” flag does not accidentally suppress an available risk-control path.

Define freshness for the actual source. Kraken generates its WebSocket status on successful connection and when engine status changes; clients cannot request a status-channel update directly. Coinbase Exchange's status channel sends products and currencies on a preset interval. Their update patterns differ, so the absence of a recent mode change has different meaning from a failed subscription or broken connection. Kraken status delivery, Coinbase Exchange status channel.

Choose explicit freshness and continuity requirements for each source; there is no universal timeout in this example. When required evidence becomes stale, block new exposure and refresh it rather than extending an old online observation indefinitely.

Recheck the decision immediately before dispatch when newer applicable evidence has arrived. A command approved under an earlier mode does not carry an exemption from the exchange's current rules. The exchange remains the authority when processing the request, and a local check cannot remove the race between observation and arrival.

Validate transitions without assuming a restart schedule

Use recorded fixtures or a supported test environment to exercise the decision rule. Here is an invented sequence based on Kraken's documented capabilities; the times and sequence are teaching inputs, not a promised recovery path.

Check the transitions as well as the rows. The 10:01 cancellation is still pending until its outcome is confirmed. The return to online does not prove it succeeded. Likewise, an order accepted during post-only has not filled merely because the engine later permits matching.

Include fixtures for a missing required flag, an unknown enum, conflicting active flags, a restrictive pair under an online engine and a mode change between approval and dispatch. Confirm that each produces a readable reason rather than an automatic fallback to a different order type. Removing post-only or replacing a blocked market order with a crossing limit changes the instruction's permissions.

Start with one pending operation and write down the exact evidence that permits it, blocks it or leaves it unresolved. That record turns exchange status into a reviewable action decision while preserving the separate evidence needed to establish actual orders and fills.