Coming soon: order placement over WebSocket becomes available on September 2, 2026, on the global platform only. The EU platform is not yet supported.
Authorization
Every order method requires an authorized connection. Sendauthorize as the first frame after connecting — see Authorize for the token flow. An order method sent on an unauthorized connection is rejected with error 6.
Authorization holds for the lifetime of the connection. No re-authorization or refresh call exists.
Request and response envelope
Order methods follow the JSON-RPC structure used across the WebSocket API, with one difference from the subscription channels:params carries a single object rather than positional values.
Client → server
Server → client
Exactly one of
result and error carries meaning. Responses arrive interleaved with subscription pushes, which carry no id, so correlate each answer by id rather than by arrival order. The same operations are available over REST — see Create Limit Order for the equivalent endpoint family.
Decimal values are strings
Every price, amount, and fee travels as a decimal string, which avoids floating-point rounding. The engine normalizes trailing zeros on the way out: a price sent as"1916.40" returns as "1916.4". Compare decimal values numerically, never by string equality.
Timestamps are the exception. The ctime and mtime fields are JSON numbers — Unix seconds with a microsecond fraction.
Order methods
Spot markets
Margin and futures markets
All markets
The
collateral_* family targets margin and futures markets and is rejected with error 19 on a spot-only market. A spot order_* method on a futures market is rejected with error 1.
Order object
Every placement, modification, and cancellation returns the same order object. Field-by-field descriptions are in Orders Pending. Three groups of fields appear conditionally:- Conditional orders add
activation_price,activation_condition, andactivated. - Margin and futures orders add
reduce_onlyandposition_side. - Group placements return legs under
take_profit,stop_loss, ortrigger_orderinstead of a single flat object.
activation_condition field is derived by the engine rather than sent as a parameter. It reports gte when the activation price sits above the market at placement, and lte when below.
The
side field inverts between request and response. A request sends "buy" or "sell" as a string; the response reports 1 for sell and 2 for buy.Order type codes
The numerictype values are listed in the order types table. Three notes on reading the codes: the same code can come from more than one method, because a BBO order becomes an ordinary limit order once it is priced; a TPSL leg is internally a margin stop-market order, so collateral_order_tpsl_place reports type 10 alongside collateral_order_stop_market_place; and a stop order that converts into a market or BBO order carries price "0" until it activates.
Order status
Self-trade prevention
Thestp parameter decides what happens when an order would match against another order from the same account. It defaults to no when omitted.
See Self-Trade Prevention for the platform-level behavior.
Shared enums
Execution flag combinations
The execution flags constrain each other, and an illegal pair is rejected with error1 rather than silently dropped.
Only
order_limit_place and collateral_order_limit_place accept rpi.
While a market runs in post-only mode, only limit orders carrying the post-only flag are accepted; every market and stop method is rejected with error 51. When trading is disabled entirely, all methods return error 51.
Error codes
A failure setsresult to null and fills error with a numeric code and a message. Branch on the code and treat the message as diagnostic text that may change.
6 means order not found in a cancel or modify context, and authentication required when the connection has not authorized. Code 11 means amount too small on placement, and carries the authorization server message when authorization itself fails.
Validation — code 1
Every malformed request returns code1; the message identifies the parameter.
Engine rejections
Conditional orders and positions
Account and rate limits
See WebSocket Rate Limits for connection and request limits.
Regional availability
At launch on September 2, 2026, order placement over WebSocket is available on the global platform only; the EU platform is not yet supported. Once available in a region, the region of the authorized connection decides which trading types — spot, margin, futures — and which individual markets are reachable. On this transport the region is carried by the authorization token; no per-request override exists. Region checks run before market and balance validation, so a region error masks any other problem with the request. When an order is rejected with one of the codes below, nothing else about it was evaluated.
The available order types also vary by region. In the EU region the spot order types are restricted and margin and futures are unavailable; that policy will apply here once EU support for this transport is added — see Order types — Regional restrictions.
Related resources
- Authorize — token flow required before any order method
- Orders Pending — stream of order lifecycle events, and the order object reference
- Deals — stream of individual fills
- Order Types — order type concepts and regional restrictions
- WebSocket Rate Limits — connection limits, request limits, and standard error codes
Used in these guides
- Market Maker integration — placing and canceling quotes over the WebSocket order methods.
- Partner Solutions — the partner router’s REST-versus-WebSocket transport guidance.
- Crypto-as-a-Service integration — the trade surface composed into a white-label exchange.