Bulk endpoint
Last updated: July 11, 2025
Ledger v2.O - _bulk endpoint
In order to perform multiple operations at once, starting ledger v2, you can use the _bulk endpoint to perform those.
Batch endpoint from v1 (atomic) is being replaced for an elastic-like bulk endpoint (atomic at the tx level within the bulk) meaning that e.g. N transactions out of 100 in the bulk can go through if the remaining 100-N are not valid (as opposed to the batch endpoint from the v1 endpoint, which would reject the whole batch)
Transactions processed and validated by the ledger are then inserted into the database in batch mode, limiting network round-trips and significantly increasing write throughput. The writing is done by a worker whose role is to loop continuously and insert pending transactions into the buffer.
you can add
idempotency-keyon actions in the bulk, so in case it stops, you can safely replay the same batch without having duplicates. Besides, there is a parametercontinueOnFailureavailable.continueOnFailure=false (default)
→ the bulk will stop on the first error returnedcontinueOnFailure=true
→ the bulk won't stop processing
POST /<ledger>/_bulk
[
{"action": "CREATE_TRANSACTION", "data": {...}},
{"action": "CREATE_TRANSACTION", "data": {...}},
{"action": "ADD_METADATA", "data": {...}},
...
]Available actions
* CREATE_TRANSACTION
* ADD_METADATA
* REVERT_TRANSACTION
* DELETE_METADATA
You can pass the following argument to the Ledger: --bulk-max-size
📄 How to increase the bulk transaction size limit
Note that increasing the Bulk size does not necessarily improve the writing performance of the Ledger.
Ledger v2.2 - Enhanced _bulk Endpoint
The _bulk endpoint has been significantly improved with three major capabilities:
Streaming Support
Bulk requests can now be streamed, allowing large payloads to be processed efficiently without requiring the entire request to be loaded into memory.
📄 How to Use Bulk Operations with Streaming in the Ledger API
Parallel vs. Sequential Processing
You can now specify whether bulk elements should be processed in parallel or sequentially using the parallel query parameter:
parallel=true: Elements are processed in parallel, improving throughput.parallel=false: Elements are processed sequentially, maintaining order.
Atomic Bulk Execution
You can now decide whether bulk elements should be committed atomically using the atomic query parameter:
atomic=true: The entire batch is committed as a single transaction. If any element fails, the entire batch is rolled back.atomic=false: Each element is processed independently. If one element fails, it does not affect the others.
atomic & parallel parameters are not compatible, they can't be set to true together. This combination will give you a 400 error.