DELETE /orders
Cancel all orders
Cancel all orders.
operationId: cancelAllOrders · CCXT method: cancelAllOrders · Rate-limit class: trading
Declared server:
https://api.testnet.nexus.xyz/v1. See Networks.
Authentication: agentAuth, hmacAuth.
Charged to the cancel budget, which is separate from the order budget that submission and amend draw on (x-nexus-rate-limit-class: trading names the class both belong to, not the bucket). A key that has spent its entire submission allowance can still cancel: exhausting one never refuses the other. It is a separate bucket rather than an exemption, so cancelling in a tight loop can still 429 — with bucket: cancel, the only refusal that means your cancel channel itself is saturated. See "Rate limits" for the full model.
HMAC API key authentication. Send three headers:
X-API-Key: your key ID (e.g.nx_a1b2c3...)X-Timestamp: current time in unix millisecondsX-Signature:hex(hmac_sha256(secret, timestamp + "\n" + METHOD + "\n" + path + "\n" + query + "\n" + sha256_hex(body)))
Timestamp must be within 30 seconds of server time.
The key is network-scoped; the signature is not. The canonical string above has no network component, so the same signed request is byte-identical on every host. What stops a testnet key from authenticating against mainnet is that the key does not exist in that host's key store — sign only for the host that minted the key, and never replay a signed payload against another network. Presented to the wrong host, a key is refused with the same opaque 401 as an unknown key and must not be retried there. See “API keys are bound to one network” in the API description.
Cancel only orders on this market
The orders that were actually cancelled, in the Order shape GET /orders serves. A cancel-all that could not reach every market still answers 200 with only the orders it did cancel, so an empty or short array is not proof that nothing rests any more.
An order and its lifecycle, as the read endpoints return it. Every placement option is echoed back, so this schema is also the record of how an order was placed: postOnly, reduceOnly, stp, max_slippage_bps, triggerPrice, the trailing anchor and offset, and the clientOrderId the caller supplied.
Field names follow CCXT's unified vocabulary wherever CCXT defines one and stay snake_case for the Nexus extensions it does not — the same rule Trade follows (ENG-13314). Money remains a decimal string rather than becoming a JSON number (EDR-012), so unlike Trade this schema pairs camelCase keys with decimal-string values. POST /orders still accepts the request vocabulary (market_id, quantity, client_id) and returns this one — the asymmetry is deliberate and is ENG-13524's to settle.
Quantities are three figures: amount is the total the order was placed for, filled what has executed, and remaining their difference — served by the venue rather than left to the caller, because these are decimal strings and the subtraction is where a client loses precision (ENG-13272). All three survive an amend, which replaces the order rather than mutating it.
The four fill aggregates — average, cost, fee and lastTradeTimestamp — are null together when the venue cannot compute them, with fill_totals_error carrying the reason. They are not per-fill detail: the individual executions are on /fills, and on OrderResponse at placement time.
Fire-time limit offset in basis points, echoed for TrailingLimit orders (see the OrderRequest.limit_offset_bps placement field); null for other order types.
The self-trade prevention mode the order was placed with, echoed back (see the OrderRequest.stp placement field for what each mode does). null for an order placed without one, which is the default and means self-matching was allowed. One of CancelNewest, CancelOldest or DecrementAndCancel.
Deliberately not a closed enum here, for the same reason as cancellation_reason: the mode set has changed before (D-026 supersedes D-014) and a mode added later must not break a client pinned to an older spec tag. OrderRequest.stp does enumerate the modes, because there the value is one you supply and the server validates it.
Slippage cap in basis points, echoed for orders placed with one (see the OrderRequest.max_slippage_bps placement field); null for orders placed without a cap.
The order's limit price, or null for an order type that has none. CCXT defines price as the limit price, so ENG-13314 renamed limit_price to it.
This is NOT the price that ENG-6776 removed from this schema. That one was a phantom — documented, and emitted by neither producer, so a client branching on it got undefined. This property is the value the response has carried all along, now under CCXT's name for it.
Stop price for a stop order, null otherwise.
The price that armed a triggered order, null for order types that are not triggered.
The trigger price of a stop-loss order — CCXT's stopLossPrice. Set only on the stop family (StopLimit, StopMarket), where it restates the order's own triggerPrice under CCXT's name; null on every other order type.
Nexus models a bracket's stop loss as its own reduce-only child order, and records no parent→child link, so this is an order stating its OWN threshold — which is also CCXT's definition of the field. A parent order does not report its bracket's price here.
Trailing types are deliberately null: their threshold is trailing_anchor offset by trailing_offset_bps, not a fixed price, so a value here would state a number the engine does not use.
DOES NOT SURVIVE THE FIRE. This field is keyed on type, and the venue rewrites type when the trigger fires (StopMarket becomes Market, StopLimit becomes Limit) while retaining triggerPrice. The same order therefore reports a price here while it is resting and null once it has fired, with triggerPrice unchanged throughout. Reconcile a stop across its whole life on triggerPrice, not on this field.
The trigger price of a take-profit order — CCXT's takeProfitPrice. Set only on the take-profit family (TakeProfitLimit, TakeProfitMarket), where it restates the order's own triggerPrice under CCXT's name; null on every other order type.
The mirror of stopLossPrice, and null under the same conditions — see that field for why a bracket parent does not report its child's price, why trailing types state nothing, and why a FIRED take profit reports null here while keeping its triggerPrice.
The extreme price a trailing order is measured from, null for non-trailing orders.
Trailing distance in basis points for a trailing order; null otherwise. Echoed from placement, like max_slippage_bps.
Whether the order may only reduce an existing position, echoed from placement (OrderRequest.reduce_only).
Read this rather than inferring it. The field was in every GET /orders response before ENG-6776 documented it — the indexer serializes the shared Order type verbatim — but absent from this schema, so a client needing it was guessing from order type and position side instead of reading the flag the venue recorded.
Whether the order was placed post-only: cancelled rather than executed if it would have taken liquidity.
Whether the liquidation engine created this order rather than the account. Liquidation fills are fee-exempt on both legs (ADR-0004), which is why a Fill.fee of "0" against such an order is a real zero and not an unstated fee.
The client-supplied identifier for the order, echoed back; null when placement supplied none.
Arbitrary-precision decimal serialized as a string (lossless). Parse with a decimal type, never a float.
Arbitrary-precision decimal serialized as a string (lossless). Parse with a decimal type, never a float.
Arbitrary-precision decimal serialized as a string (lossless). Parse with a decimal type, never a float.
Lifecycle state. Triggered is a transient engine state stamped on a stop/take-profit/trailing order at the moment it fires, before the resulting order is submitted; no client-facing response is expected to carry it, because every submit outcome overwrites it (Open/PartiallyFilled when the converted order rests, Filled, Cancelled, or Rejected). It is listed because the wire type can hold it, so a consumer that rejects unknown values would fail on it rather than degrade. Treat this set as growable and prefer tolerating an unrecognised status to hard-failing.
Why the order reached a terminal Cancelled or Rejected status. null for every other status, and for a terminal order the engine recorded no cause for. The key is always present.
Two wire shapes. The engine's reason type is an externally tagged enum, so every cause except self-trade prevention is a bare string, while self-trade prevention is a single-key object naming the mode that fired: {"Stp": "CancelNewest"}. Branch on the JSON type before reading the value.
The string form is one of User (an explicit cancel or cancel-all), SlippageCap (a market order's running fill VWAP left the max_slippage_bps band — see that field), Liquidation (cancelled ahead of a liquidation, or the unfilled remainder of one), Expired (an IOC, FOK or market remainder that cannot rest on the book), MarketHalt, AmendReplace (carried on the original order of an atomic cancel-replace via PATCH /orders/{order_id}), InsufficientLiquidity (a stop, stop-limit or trailing stop fired into an empty opposite side), BracketClosed or BracketFlipped (a bracket child whose parent position closed to zero or flipped sign), or PriceBandExceeded (the order-vs-mark price-band collar rejected it). The object form's only key today is Stp, whose value is CancelNewest, CancelOldest or DecrementAndCancel.
Treat the value as open. Causes are added as the engine gains them, and this is not a closed enum: match the ones you handle and surface anything else verbatim rather than failing to parse. A client pinned to an older spec tag will meet causes it does not know.
GET /orders/history reports the same causes in a different encoding — OrderHistoryEntry.cancellation_reason is always a string and renders the self-trade case as Stp(CancelNewest), not as an object. Do not compare values across the two surfaces.
Any cause other than self-trade prevention, as a bare string.
Unix epoch timestamp in milliseconds.
timestamp as an ISO 8601 string in UTC, to millisecond precision. Derived from that same value rather than recorded separately, so the two cannot describe different instants. CCXT declares both; read whichever suits the client.
Unix epoch timestamp in milliseconds.
Volume-weighted average price of this order's fills, as a decimal string. null when the order has not filled (fill_totals_error is then also null — nothing executed is an answer), or when the totals cannot be stated — see fill_totals_error.
Total quote value executed on this order (Σ price × size), as a decimal string. Same availability rule as average.
Total fee for this order as a signed decimal string: positive is a charge, negative a net maker rebate. null when the totals are unavailable, and also when they are available but a contributing fill stated no fee — a total is a claim about every fill, so one unstated leg makes the total unknown rather than smaller. Absent is never zero. POST /orders returns null here even alongside a populated average: that response is built from the match result, which carries no fee attribution.
Timestamp of this order's most recent fill, in epoch milliseconds. Same availability rule as average.
Machine-readable reason average / cost / fee / lastTradeTimestamp are null, or null when they are populated or when the order simply has not filled. One channel for all four because they are one aggregate with one cause.
fills_retention_exceeded — a fill of this order has aged out of the retained history, so any total would be a partial sum. A partial average is a real-looking price with nothing marking it wrong, so it is withheld.
fill_history_predates_amend — the retained fills fall short of this order's filled, on a response for an order id the venue minted answering this same request. PATCH /orders/{order_id} is an atomic cancel-replace: it mints a new order id and carries filled across, while fills stay attributed to the id that executed them, so the replacement counts executions it has no history of and the totals would describe only the post-amend portion. Served only where the amend is the sole possible cause — a read route reports fill_history_short_of_filled_qty for the same shortfall.
fill_history_short_of_filled_qty — the retained fills for this order id are complete as far as the retention window can tell, and still sum to less than its filled. Two causes produce this and they cannot be told apart here: the order descends from an amend (see fill_history_predates_amend), or its per-order aggregate was evicted from a bounded map and rebuilt from later fills alone, which is a retention drop the window test cannot see. The reason states the shortfall rather than naming a cause it would be guessing at, because the two have different remedies. As with every value here no partial total is served: the four fields stay null.
fill_history_not_retained — the producer answering this request keeps no per-order fill history, so the totals are not derivable here even though the order has executed. Distinct from fills_retention_exceeded, which means a retained history dropped a fill. Reaches a client on the responses relayed from the matching engine without a fill-history join: DELETE /orders/{order_id}, DELETE /orders, and the duplicate-client_id replay branches of POST /orders and POST /orders/batch, which return an order the request did not create. PATCH /orders/{order_id} is enriched before it leaves the venue and reports fill_history_predates_amend instead.
filled_qty_lags_fill_history — the retained fills for this order id sum to MORE than its filled, so the totals would answer for more executions than the order itself admits to. Neither a shortfall nor a retention problem: the venue folds a match's fill and the taker order's own filled from two separate events, so a read landing between them sees a fill history ahead of the order's projection. It closes itself within one event — retry the read. The four fields stay null until then, and a filled of 0 carrying this cause means the same thing rather than an order that has not executed: fills are known for the id, the order has simply not caught up yet.
Authentication failed. All 401 responses return the same opaque body to prevent information leakage. A credential minted on a different network is one of the causes it hides — by design, so that a key id cannot be probed for existence on another network. Do not retry it against another host.
Rate limit exceeded. Retryable — honour retry-after and back off; this is what separates a 429 from the permanent 403 jurisdiction refusals. Branch on the body's code, which is always RATE_LIMIT_EXCEEDED, and on bucket to learn WHICH budget bottlenecked — the buckets are independent, so a caller at its read ceiling can still submit orders and should not back off the whole client. Do not parse message: it is a diagnostic whose wording is not stable. Requests are charged by weight, so exhausting a budget takes fewer heavy calls than x-ratelimit-limit suggests. See “Rate limits” in the API description.
DELETE /v1/orders HTTP/1.1
Host: api.testnet.nexus.xyz
X-API-Key: YOUR_API_KEY
Accept: */*
[
{
"id": "123e4567-e89b-12d3-a456-426614174000",
"symbol": "text",
"account_id": "text",
"side": "Buy",
"type": "text",
"limit_offset_bps": null,
"stp": null,
"max_slippage_bps": null,
"price": "text",
"stopPrice": "text",
"triggerPrice": "text",
"stopLossPrice": "text",
"takeProfitPrice": "text",
"trailing_anchor": "text",
"trailing_offset_bps": null,
"reduceOnly": true,
"postOnly": true,
"is_liquidation": true,
"clientOrderId": null,
"amount": "text",
"filled": "text",
"remaining": "text",
"status": "Open",
"cancellation_reason": null,
"timeInForce": "text",
"timestamp": 1,
"datetime": "2026-01-01T00:00:00.000Z",
"lastUpdateTimestamp": 1,
"average": "text",
"cost": "text",
"fee": "text",
"lastTradeTimestamp": 1,
"fill_totals_error": null
}
]Test it cannot sign this request. X-Signature is an HMAC computed per call: see Authentication, or use an SDK.
API version 0.9.122
Last updated