Skip to main content
POST
Cancel and replace orders sequentially and non-atomically
Submit multiple cancel-and-replace operations in one request. Each executed operation has the same non-atomic behavior as POST /orders/cancel-replace, and one operation result does not stop later operations.

​
Request

Send operations as an array of 1 to 4 cancel-and-replace operations. Each item contains cancel, replacement, mode, and optional onBehalfOf fields as described in the single-operation reference. Use HMAC authentication with the trading scope and sign the exact JSON body with the path /orders/cancel-replace/batch. Each signed replacement remains a normal EIP-712 order; delegated body onBehalfOf operations follow the same authorized-owner and delegated-signing rules. The x-on-behalf-of header is not supported.
A request-level validation, authorization, market, signature, maintenance-mode, or receive-window error rejects the batch without a results array; maintenance-mode and receive-window failures return 425 Too Early. Duplicate cancellation targets and duplicate normalized replacement clientOrderId values also reject the entire request. Accepted operations then report independent cancellation and replacement outcomes.
The order values below illustrate the request shape. Generate each order.signature from its complete replacement payload instead of copying the placeholder signatures.

​
Ordering and partial failures

Accepted operations execute sequentially and the response preserves request order: every result has the zero-based index of its input operation. Operations produce independent outcomes, so inspect both cancel and replacement for every index rather than treating the HTTP status as an item-level result. A failed operation does not stop later operations. If all items have top-level cancel.status: "SUCCESS" and replacement.status: "SUCCESS", the endpoint returns 200 OK. If any item has another top-level status, it returns 207 Multi-Status with every result, including successful items.
STOP_ON_FAILURE produces NOT_ATTEMPTED only for the affected operation. ALLOW_FAILURE still attempts that operation’s replacement. Cancellation and replacement outcomes can also be UNKNOWN when the final result cannot be determined. Insufficient balance or allowance can produce a successful cancellation with an item-level replacement FAILURE and an HTTP-status error code such as "400". The batch continues and returns 207 Multi-Status with all results. A receive-window or trading-availability rejection can likewise produce a successful cancellation with an item-level replacement FAILURE and error.code: "425". Operation error codes are strings, not a closed enum. A missing cancellation target uses ORDER_NOT_FOUND; request failures use decimal HTTP status strings such as 400, 404, 409, 425, or 500; other failures use INTERNAL_ERROR. FAILURE identifies a known failure and UNKNOWN an inconclusive outcome. Cancellation authorization failures remain request-level 401 or 403 responses. Request-level errors use their ordinary HTTP status instead of 207 Multi-Status. A 207 is returned when at least one operation has a non-success top-level result.
HTTP 200 versus 207 follows the top-level cancellation and placement statuses. An accepted replacement stays top-level SUCCESS even if its nested execution.settlementStatus is FAILED; the nested reason carries the settlement failure.

Authorizations

​
lmts-api-key
string
header
required

Scoped API token with HMAC-SHA256 signing. Requires three headers: lmts-api-key (token ID), lmts-timestamp (ISO-8601), lmts-signature (Base64-encoded HMAC). See Authentication docs for details.

Body

application/json
​
operations
object[]
required

Independent cancel-and-replace operations

Required array length: 1 - 4 elements

Response

Every operation succeeded

​
results
object[]
required

Outcomes in input order. Each item includes its zero-based input index.