Cancel all orders

OrdersService.CancelAllOrders (POST /v1/orders/cancel-all) cancels every open order of an account that matches a filter. Use it as a kill switch, or to clear a Pair or Side before requoting.

Which orders are canceled

The filter selects:

• the account: the Subaccount in subaccount_id; when it is omitted, the caller's Main Account, or the bound Subaccount for a Subaccount-scoped API key
• optional Pairs, up to 100; an empty list matches every Pair
• optional side; when it is omitted, both sides match

An unknown Pair rejects the request. Cancel-all accepts every Pair status, so you can clear your orders on a disabled or halted Pair.

Polyester fixes the set of matching orders when it accepts the request. Every order that is pending or open at that moment is canceled, including orders whose cancellation is already in progress. An order modified after that moment is still canceled.

Orders that Polyester accepts after that moment are not affected, even if they were sent shortly before the cancel-all.

What happens to triggers

The triggers themselves keep their reserved funds and behave as follows after a cancel-all:

• A stop-loss, take-profit, or trailing stop that has not fired stays armed and places its order when its condition is met.
• A TWAP keeps running and places its next slice when it is due.
• A ladder ends once none of its levels remains open: STATUS_CANCELED with TRIGGER_CANCEL_REASON_USER_REQUEST when none of them filled, STATUS_COMPLETED when any did.
• An attached leg whose working exit is canceled ends STATUS_CANCELED with TRIGGER_CANCEL_REASON_USER_REQUEST. Attached legs without a working exit keep protecting the parent's filled position, even when the parent order is canceled; they end only if the parent is canceled before any fill.
• A paused trigger stays paused.

Stop all automated trading

To stop every order and trigger, cancel each live trigger first, then cancel all orders. A trigger that fires before its cancel places an order that the cancel-all then cancels.

1. List the live triggers, attached legs included, with TriggersService.ListTriggers and the statuses STATUS_CREATED, STATUS_ARMED, STATUS_RUNNING, and STATUS_PAUSED. Over REST, use GET /v1/triggers?status=CREATED,ARMED,RUNNING,PAUSED. Follow the next page token until it is empty.
2. Cancel each one with TriggersService.CancelTrigger, or DELETE /v1/triggers/{trigger_id} over REST. Canceling a TWAP or a ladder also cancels its open child orders.
3. Send the cancel-all.

The dead-man switch cancels what a cancel-all with the same scope cancels, so a client that stopped responding leaves its triggers live.

Request examples

{
	"symbols": ["BTC-USDT"],
	"side": "BUY",
	"requestId": "ca-1"
}

{
	"symbolIds": [1],
	"side": "BUY",
	"requestId": "ca-1"
}

Response fields

Polyester answers as soon as it has durably recorded the cancel-all, before the orders are canceled. A matched order can still execute before its cancel takes effect, so read order updates or order reads for each final outcome. The full schema is in the API reference; these are the rules behind each field.

REST returns the same fields in camelCase, such as matchedOrders and cancelledOrders, with each orderId as a public ID.

{
	"status": "SUBMITTED",
	"matchedOrders": 2,
	"submittedCancels": 2,
	"failedCancels": 0,
	"cancelledOrders": [
		{ "orderId": "2NEpo7TZRRrLZSi2U", "clientOrderId": "mm-bid-17" },
		{ "orderId": "2NEpo7TZRRrLZSi2V", "clientOrderId": "mm-ask-17" }
	],
	"totalCancelled": 2,
	"truncated": false,
	"listingStatus": "INCLUDED"
}

When truncated is true, read the remaining state with GET /v1/orders/open. A retry with the same request_id and filter within 120 seconds returns the original status, counts, and timestamp, but not the list: cancelled_orders is empty and listing_status is NOT_RETAINED_READ_OPEN_ORDERS. An empty list on a retry does not mean nothing was canceled; read open orders for the current state.

Completion

Each submitted order then moves to CANCELED asynchronously, unless it fills first. Observe the result through the private WebSocket or GetOpenOrders.

An accepted cancel-all completes even if the service restarts.

Retries and idempotency

request_id is required and makes the call idempotent. It contains 1 to 64 ASCII letters, numbers, ., _, :, /, or -, and is scoped to the account.

• A retry with the same request_id and the same filter returns the original outcome and counts and does not cancel again. Polyester retains the result for at least two minutes.
• Reusing a request_id with a different filter, or with a different dry_run value, is rejected with CONFLICT_IDEMPOTENCY_KEY_REUSE.
• A request_id reused after the retention window starts a new cancel-all. Use a new request_id for every new cancel-all.

Errors

Each entry gives the stable code and the ConnectRPC code, then the condition and what to do.

• UNAVAILABLE · Unavailable
  The service is busy. The cancel-all may still be processed. Retry with the same request_id, then confirm the result.
• ORDER_CANCEL_OUTCOME_UNKNOWN · DeadlineExceeded
  The cancel-all was not confirmed in time. Some or all matching orders may be canceled. Read open orders, then retry with the same request_id if needed.
• CONFLICT_IDEMPOTENCY_KEY_REUSE · AlreadyExists
  Same request_id, different filter. Use a new request_id for a different cancel-all.
• UNKNOWN_SYMBOL · InvalidArgument
  Unknown Pair. Correct the filter.
• VALIDATION_ERROR (REST) · InvalidArgument
  More than 100 Pairs. Split the request, or omit Pairs to match every Pair.
• RATE_LIMIT_EXCEEDED · ResourceExhausted
  Rate limited. Retry with the same request_id after backoff.

REST returns 503, 504, 409, 400, and 429 for these conditions.

If the request can be recorded for only some Pairs, the call succeeds and the orders it could not submit are counted in failed_cancels.

Dry run

With dry_run set, the response counts the matching orders in matched_orders and nothing is canceled. A dry run uses its request_id; send the live cancel-all with a new one.

Related Topics