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. Authentication and order signing also match the single endpoint. HMAC-sign the exact JSON body with the path /orders/cancel-replace/batch. Each signed replacement remains a normal EIP-712 order; delegated onBehalfOf operations follow the same authorized-owner and delegated-signing rules.
The API validates and prepares the whole request before executing any cancellation. A request-level validation, authorization, market, signature, or receive-window error rejects the batch without a results array. Duplicate cancellation targets and duplicate replacement clientOrderId values also reject the entire request. The independent-result behavior applies after the batch passes this preflight.
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

After request-wide preflight succeeds, the response preserves request order: every result has the zero-based index of its input operation. Executed operations produce independent outcomes, so inspect both cancel and replacement for every index rather than treating the HTTP status as an item-level result. 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. Public cancellation and replacement outcomes can also be UNKNOWN when the final result cannot be determined. Request-level errors use their ordinary HTTP status instead of 207 Multi-Status. A 207 is returned only after preflight succeeds and at least one executed operation has a non-success top-level result.
HTTP 200 versus 207 follows the top-level cancellation and placement statuses. A replacement accepted by the matching engine 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 has successful cancellation and replacement statuses

​
results
object[]
required

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