Skip to main content
4 October 2026 upgrade: the new post-only modes and conditional slippage options documented below apply after the scheduled upgrade. WebSocket post uses the same signed action schema as POST /order.
All trading operations require Ed25519 signatures and a unique nonce for replay protection. See Transaction Signing for the canonical message format and Place & Cancel Orders for the full transaction envelope.

Post Request Format

All order and trading-related operations use the post method with the unified transaction payload:
Transaction fields: Signing: The signed message is bincode_serialize(commission_signable_actions) + nonce_le_u64 + account_pubkey_bytes + signature_domain_u8, where the domain is 1 = mainnet, 2 = testnet, or 3 = devnet. Signer is not part of the signed message. See Transaction Signing for details. Offchain signing (optional): the server also accepts transactions signed with the v0 Solana offchain envelope for any action shape. Set the WebSocket handshake header x-bulk-sig-mode: offchain on the upgrade and then send post actions normally - the payload JSON shape is unchanged, only the signature bytes differ. See Optional Handshake Headers.

Action Types

Each action in the actions array is a single-key object. The key is the action tag, the value is the action payload. Order and conditional actions: The i flag is part of the canonical wincode message for l, m, st, tp, rng, and trl, and must be included explicitly. i=true routes the action via the implicit per-instrument isolated account; i=false trades from cross margin on the transaction’s account. A trig basket has no top-level i; each nested action controls its own routing. Builder codes are optional builder-code fees on m and l only. Encode them with builderCode: { "to": "recipient_pubkey_base58", "fee": 5 }, where fee is 1..=15 bps and must be pre-approved with abc. Submit orders without builder codes by omitting builderCode; "builderCode": null is rejected by the JSON API.
abc and rbc are master-account-only actions. Agent wallets cannot approve or revoke builder-code recipients.
Account management actions: For per-instrument isolated-account top-ups, set transfer.to to the isoPubkey from an iso=true open-position row on the Account Stream:
k="external" recipient auto-create applies only to on-curve pubkeys; unknown off-curve recipients are rejected.
  • createSubAccount.marginAmount and transfer.marginAmount must be JSON numbers (unquoted), e.g. 0 or 100.0, not "0" or "100.0".
See Manage Sub-Accounts and Transfer for full envelope and result-row references; Manage Agent Wallet, Update User Settings, and Request Faucet cover the other shared envelopes. updateUserSettings uses m as an object map (e.g. "m": {"BTC-USD": 10.0}).

Place Limit Order

Limit order (l) fields: c (symbol), b (true = buy), px (limit price), sz (size), tif (time in force), r (reduce-only), i (isolated routing flag, required), optional builder-code fee in builderCode ({to, fee}; omit when absent). With builder code:
Time in force: GTC (good till cancel), IOC (immediate or cancel), ALO (strict post-only; rejects if crossing), ALO_SLIDE (crossing price slides to the nearest non-crossing display tick), and ALO_JOIN (crossing price joins the same-side best quote, falling back to Slide if that side is empty). For example, the signed payload.actions may contain:
Use "ALO_JOIN" to choose Join. JSON requests use these names, not numeric enum indices. Account/order update responses use postOnlySlide and postOnlyJoin. Resting buy prices round down and sell prices round up to the display tick; IOC retains native precision. Market-executing conditional legs support basis-point slippage overrides: slippage on st, tp, and trl; slSlippage / tpSlippage on rng. Use the updated SDK signing encoder for conditional actions, including mixed batches. See Place & Cancel Orders.

Place Market Order

Market order (m) fields: c (symbol), b (true = buy), sz (size), r (reduce-only), i (isolated routing flag, required), optional builder-code fee in builderCode ({to, fee}; omit when absent). With builder code:

Modify Order

Change the size of an existing order:
Modify (mod) fields: oid (order ID, base58), symbol, amount (new size).

Cancel Order


Cancel All Orders

Cancel all in one or more symbols: use cxa with c = array of symbols. Cancel all across all symbols: use cxa with c = [].

Stop Order (st)

Stop order (st) fields: c (symbol), d (trigger direction: true = above/equal, false = below/equal), sz (size), tr (trigger price), lim (optional limit after trigger; omit for market-style).

Take Profit (tp)

Same fields as Stop Order (st).

Range / OCO (rng)

Range/OCO (rng) fields: c (symbol), d (position direction: true = long collar, false = short), sz (size), pmin/pmax (lower/upper trigger), lmin/lmax (optional limits for each leg). When one leg triggers, the sibling leg is auto-cancelled with status siblingCancelled.

Trigger Basket (trig)

Trigger basket (trig) fields: c (symbol), d (trigger direction: true = above/equal), tr (trigger threshold), actions (nested actions executed when trigger fires). Nested actions support: m, l, mod, cx, cxa, st, tp, rng, trl.

Trailing Stop (trl)

Trailing stop (trl) fields: c (symbol), b (protected direction: true = long), sz (size), trb (trailing distance in bps), stb (favorable reset step in bps), lim (optional limit; null for market-style).

On-Fill (of)

On-fill (of) fields: trigger (an embedded m or l action), actions (one-shot consequents executed on the trigger’s first fill). An embedded trigger or consequent m / l may carry builderCode under the normal order rules. Nested actions support: m, l, mod, cx, cxa, st, tp, rng, trig, trl.
Cancelling conditional orders: Use cx with the conditional order ID or cxa to cancel all orders including conditionals.

Batch Actions

Multiple actions can be combined in a single transaction (same nonce, account, signer, signature). One status is returned per action/event. Example: cancel one order and place two new limit orders

Response Format

Size fields in responses (totalSz, filledSz, remainingSz) are signed: negative values indicate sell-side. For example, a fully-filled sell of 0.1 BTC returns totalSz: -0.1.

Status Types

Non-Terminal (Order Still Active)

Terminal (Order Complete)


Response Examples


Order Updates (Account Stream)

In addition to the inline post response, all order state changes are delivered as orderUpdate messages on the Account Stream. These carry the full order state with signed sizes.
origSz and sz are signed: negative values indicate sell-side intent. For example, a sell order for 0.25 BTC has origSz: -0.25. For ot: "trigger" baskets, origSz and sz are 0 (trigger baskets carry nested actions, not a direct sized order).

orderUpdate Fields

Trigger Metadata

When trigger is present (conditional orders):

orderUpdate Examples

Fill Event

Emitted separately on each trade execution (in addition to orderUpdate):
See Account Stream for the full account stream reference.

Error Handling

Ensure you’re using the correct serialization format including nonce. Use official SDKs when possible.
signer must be one of: the account itself, an agent wallet registered on account, or (when account is a sub-account) an agent wallet registered on the parent master. Agents registered on a master can sign for the master and for any of its sub-accounts and per-instrument isolated accounts. Sub-accounts can also register their own agents. Isolated accounts are never used as account; their margin and orders are reached via i=true on order actions and the to field of a transfer. See Manage Agent Wallet.
Check your available balance before placing orders. Consider position size and leverage.
Each nonce can only be used once. Use nanosecond timestamps: BigInt(Date.now()) * 1_000_000n.
Verify order parameters meet market requirements (min size, tick size, etc).