Skip to main content
POST
Batch modify orders
The response body shown here is a static example, not live data. After you click Send, your live result appears in a separate panel headed 200 OK. The panel under the status-code tabs is a fixed sample from the spec — its field values (fees, prices, sizes, IDs, timestamps) are placeholders. Use Send, or call the endpoint, for current values.
Modify up to 100 open orders in a single request. Every row must share the same (address, accountIndex) — batch modifies are scoped to one subaccount. Requires address query parameter (or a uniform per-row address) matching the master Ethereum address for X-API-Key. Signed per modify. This endpoint requires the X-Signature header to be present (non-empty); its value is not verified — set it to any one element’s signature. Omitting it rejects every element with invalid order signature. Each element of modifies carries its own signature over the same typed canonical modify payload as a standalone modifyOrder, so the signed bytes are identical whether the modify is submitted alone or in a batch; the shared X-API-Key + X-Timestamp headers authenticate the batch. Failures are per-item. A row that fails validation or signature verification is returned with status: ERROR and an error message; the remaining rows still reach the matching engine. The whole batch is rejected only for envelope-level problems (empty/oversized array, mixed (address, accountIndex), bad auth). Speed-bump semantics match batchPlaceOrders: the batch is forwarded to the engine as one unit. If every modify targets a post-only (ALO) resting order the batch skips the taker speed bump entirely; if ANY modify targets a non-post-only order the whole batch is subject to it. All-ALO batches are prioritized like cancels. An all-ALO batch can only shrink or reprice maker orders — it can never take liquidity — so it is routed on the high-priority path ahead of order placements, the same as cancels. Like a cancel, it may therefore be processed ahead of earlier not-yet-sequenced placements (including its own targets, which would then reject as ORDER_NOT_FOUND_FOR_MODIFY). Such a rejected modify is also buffered briefly and applied when the target placement arrives, mirroring buffered-cancel behavior — see POST /v1/modifyOrder.

Response behavior

Asynchronous. Returns either 202 Accepted (the common case) or 200 OK (the gateway already had definitive per-row state). Each row echoes orderId / clientId so clients can correlate orders WebSocket channel events.

Authorizations

X-API-Key
string
header
required

Hex-encoded Ed25519 public key (64 chars). The public key IS the API key — register it via POST /createApiKey. Required on every authenticated request, both read-only and signed.

X-Timestamp
string
header
required

Unix time in nanoseconds as a decimal string (e.g. "1713825891591000000"). Millisecond or second epochs are rejected with 401 Unauthorized. Must be within ±30,000 ms of server wall-clock, or the request is rejected with 401 Unauthorized. Required on all mutating / credential-creating endpoints. This same value must appear as the ct field in the ordersign typed canonical payload (single-order endpoints) or in each element's ct field (batch endpoints).

X-Signature
string
header
required

Lowercase hex-encoded Ed25519 signature (128 chars).

Single-order endpoints (placeOrder, cancelOrder, modifyOrder, and other non-batch mutating routes) sign over the ordersign typed canonical payload — a compact, key-sorted JSON object built from parsed request fields using engine-native integer values:

ct must equal the X-Timestamp header value. Keys in brackets are conditional (omitted when empty). op values: 1=place, 2=cancel, 3=modify. See the ordersign package for field definitions and reference signing code.

Other signed routes (e.g. createApiKey) still use the legacy scheme: signing_message = X-Timestamp + ACTION + canonicalJSON(body), where ACTION is the camelCase final path segment.

Batch endpoints (batchPlaceOrders, batchCancelOrders, batchModifyOrders) do NOT use this header. They authenticate with per-element typed ordersign signatures embedded in the request body (see the global auth description and the per-field signature descriptions on OrderRequest / CancelOrderRequest / ModifyOrderRequest).

Read endpoints are authenticated by ?address= (and optionally X-API-Key) only — no signature is required, except for the signed affiliate reads (see the Referral tag), which require the full header triple; with no body their signing message is X-Timestamp + ACTION. canonicalJSON(body) is the JSON body with object keys sorted lexicographically at every level and no whitespace; the server canonicalizes the received body before verifying, so only the bytes signed over must be canonical. Required on all mutating / credential-creating endpoints.

Query Parameters

address
string
required

Master Ethereum address for this API key (must match address from POST /createApiKey for the same key). Required on REST for account-scoped reads and for place/cancel. Invalid hex → 400; mismatch with key → 403.

20-byte EVM address as hex: optional 0x or 0X prefix and exactly 40 hexadecimal digits. API responses normalize to lowercase a–f after 0x.

Pattern: ^(0x|0X)?[0-9a-fA-F]{40}$

Body

application/json
modifies
object[]
required

Array of 1-100 modify requests. Every row must share the same (address, accountIndex) — batch modifies are scoped to a single subaccount — and every row must carry its own signature field (see ModifyOrderRequest.signature).

Required array length: 1 - 100 elements

Response

Batch modify processed and the gateway already has definitive state for the rows. Per-row status reflects that state. Treat as best-effort enrichment of the 202 path; the orders WebSocket channel is still the source of truth.

responses
object[]
required

One row per input modify, in request order. Failures are per-item: a row that fails validation or signature verification is returned with status: ERROR and an error message while the remaining rows still reach the matching engine.

rateLimit
object

Per-subaccount order-pool rate-limit snapshot after charging the whole batch (one snapshot for the request, not per row). Omitted when rate limiting is not configured.