Skip to main content

​
Cancel Order via WebSocket

To cancel orders on Rails platform, use the WebSocket v2 API and subscribe to the Order Creation Stream. This new WebSocket API supports every request and notification from the legacy Order Creation WebSocket. The specifications and behavior remain the same.

​
Order Cancellation Workflow

Order cancellation is done by submitting a Cancel Order By ID request. You will receive two responses in sequence:
  • Acknowledgment: Confirms the request was received and processing started
  • Confirmation: Confirms the order was successfully cancelled
Key differences:
AcknowledgmentConfirmation
Bodycancelling orderorder cancelled
Order Statuscancellingcancelled
Status Code202200
API Quota UsedIncludedNot included
Note that a unique clientRequestId can be used to correlate acknowledgment, confirmation, and any error responses.

​
Cancellation via REST

While we recommend using the Cancel Order By ID WebSocket request for faster, prioritized processing and clearer confirmations, you can also use the Cancel Orders REST endpoint to cancel orders in bulk. A 200 response indicates your cancellation request was received and processing has begun; it does not guarantee that all targeted orders have been cancelled. If you prefer the REST endpoint for convenience, here are reliable ways to verify that all orders were cancelled:
  1. Call the endpoint again and confirm the response body includes Cancelling 0 orders.
  2. Use Get Open Orders to verify the orders are gone.
  3. Include an optional clientRequestId query parameter in the REST call and subscribe to the Order Creation WebSocket for notifications (one per order). Each notification will include the same clientRequestId plus a suffix — for example, 0835bf3e-4a20-41f0-908d-8213f2b7a285#0 and 0835bf3e-4a20-41f0-908d-8213f2b7a285#1 for two orders, in no particular order.

​
Priority of Cancellations

Order cancellations receive the highest priority in our system processing queue:
  • Skip margin checks
  • Bypass the standard queue to go directly to the matching engine
  • Are prioritized over all other requests to ensure fast execution
This provides strong cancellation guarantees: if an order exists and can be cancelled, it will be cancelled as fast as possible regardless of system load. You may receive 404 responses if the order no longer exists (for example, already fully filled or previously cancelled).

​
Status Transitions & Partial Fills

  • Typical flow: active → cancelling → cancelled
  • If the order had fills, filledQuantity and avgFillPrice may be present in confirmation responses
  • Concurrent fills during cancellation are reflected in the final filledQuantity

​
Conflict And Retry

If you receive a 409 Conflict during cancellation, it indicates the order is in the process of being filled at the time of the cancel request. This is a transient state — implement a short backoff and retry the request until you receive either confirmation or a definitive error.