JSON-RPC batches: order, ids and partial errors

Last updated: September 22, 2026

At a glance

What you see

A batch of balance reads returns values attached to the wrong accounts, or one item carries an error while the others succeed. Occasionally a batch returns fewer responses than requests.

Why this happens

The JSON-RPC 2.0 specification says "the Response objects being returned from a batch call MAY be returned in any order within the Array" and that "the Client SHOULD match contexts between the set of Request objects and the resulting set of Response objects based on the id member within each Object". The server "MAY process a batch rpc call as a set of concurrent tasks". Each response has either a result or an error, so one failing item does not fail the batch. Notifications — requests without an id — get no response, and if nothing is left to return the server returns nothing at all rather than an empty array.

What to do

1. Give every request in a batch a unique id and build a map from id to request.
2. Match each response by id, not by position.
3. Check each response for error independently and retry only the failed items.
4. Do not send requests without an id when you need an answer — they are notifications.

When this is not our problem

Batch ordering and per-item errors are defined by the JSON-RPC 2.0 specification, for every server that implements it, whoever operates it, Triport included. Batch size limits, where they exist, are a separate server policy documented per endpoint.