Skip to main content

​
Cancel Order via WebSocket

To cancel orders on Rails platform, use the WebSocket API and subscribe to the Order Creation Stream. The specifications and behavior remain the same.

​
Order Cancellation Workflow

Order cancellation is done by submitting a Cancel Order By ID request via the Order Creation Stream. 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: Note that a unique clientRequestId can be used to correlate acknowledgment, confirmation, and any error responses.

​
Order Status During Cancellation

Once the request is submitted, you will first receive a cancelling status, followed by a cancelled status. The key points are:
  • cancelling means the cancel request has been accepted and the order is entering cancellation processing.
  • Once an order is cancelling, it is excluded from future matching cycles.
  • You can still receive fills after cancelling if they came from an in-progress matching cycle that started before the status changed.
  • cancelled means cancellation is fully completed and the order is removed from the system.

​
Cancellation via REST

While we recommend using a Cancel Order By ID request via the Order Creation Stream 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 HTTP call and subscribe to the Order Creation Stream 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

A refused cancel carries one of three error codes, and each asks for something different (see the Error Codes):
  • CANCEL_ORDER_CONFLICT_ERROR (2001, 409): the cancel lost a race with a fill or another update and was not applied. Send the same request again after a short backoff.
  • CANCEL_ORDER_ALREADY_CANCELLING (2002, 409): another cancel of this order is already in flight. Do not resend; the confirmation, or the error, of that earlier request follows.
  • CANCEL_ORDER_NOT_CANCELLABLE (2003, 400 or 409): the order is a liquidation order, or is already filled, cancelled or rejected. There is nothing left to cancel.