Status: pending release — effective date Thursday 06 Aug. Applies to: HTTP and WebSocket, three operations only.

What changes

The three batch order operations previously returned an array when per-order outcomes were available, but a single error object for request-level errors such as an unparseable body, invalid signature, rate limit, or internal error. Clients had to branch on the JSON shape — and over WebSocket there is no HTTP status code to branch on.

From this release, the HTTP response body and WebSocket data field for these operations are always arrays once the operation has been identified. A request-level error is returned as a one-element array.

HTTP

Success (200) is unchanged — still an array of per-order results.

Non-200 responses (400, 429, 500) change shape. HTTP status codes and Retry-After behaviour are unchanged. Retry-After remains present only for token-bucket IP and action rate limits, not for open_orders_limit.

// before — 400
{ "status": "err", "error": "invalid signature" }

// after — 400
[ { "status": "err", "error": "invalid signature" } ]

// before — 429 (Retry-After: 2)
{ "status": "err", "error": "ip_rate_limited" }

// after — 429 (Retry-After: 2)
[ { "status": "err", "error": "ip_rate_limited" } ]

WebSocket

The reply envelope is unchanged ({ "id": <your id>, "data": … }). For these three operations, data is now always an array.

// before — request rejected
{ "id": 1, "data": { "status": "err", "error": "invalid_request" } }

// after — request rejected
{ "id": 1, "data": [ { "status": "err", "error": "invalid_request" } ] }

Note: for createOrders, our AsyncAPI spec previously documented data as a single object. That was a documentation error — success replies were already an array. The spec now matches the wire.

What does NOT change

• HTTP status codes, Retry-After, and rate-limit behaviour.
• 200 / success payloads — same array, fields, and ordering.
• Per-order result objects — unchanged fields (status, oid, error, …).
• All other HTTP endpoints and WebSocket operations. For example, WS auth, ping, cancelAll, autoCancel, updateLeverage, updateMargin, and modifyOrders keep their existing object-shaped errors.
• WebSocket frames that are too malformed for us to identify the operation still reply with a generic object-shaped error. The exact id and error depend on which parsing stage failed because we cannot know that the frame was a batch order request.