Available in version 0.9.0 and later.
Creating bulk transactions
1
Configure and submit the batch
2
Confirm the response
Blnk returns a
batch_id that identifies the batch. When skip_queue: false, Blnk stores batch_id as the queued parent transaction.Save it. You can use the same ID to retrieve, commit, refund, or void every transaction in the batch without tracking individual child IDs first. See Retrieving transactions in a batch.- Synchronous
- Asynchronous
When
run_async is false:Response
On the default queued path,
status: "applied" means the bulk request was successfully submitted, not that every child is already APPLIED on balances. Blnk enqueues each item for asynchronous processing.Retrieving transactions in a batch
When you submit a bulk transaction request, Blnk assigns each transaction in the batch its own unique transaction ID and links it to yourbatch_id:
skip_queue: false(default): child transactions recordbatch_idinmeta_data.QUEUED_PARENT_TRANSACTION.skip_queue: true: child transactions setparent_transactiontobatch_id.
- skip_queue: false
- skip_queue: true
<batch-id> with the batch_id from the create response. Use the filter field that matches how you submitted the batch.
Handling inflight bulk transactions
To create inflight bulk transactions, setinflight: true in the request body. Blnk ignores any inflight flag passed in the transaction objects and respects the root inflight flag.
When set, all transactions in the batch will be processed as INFLIGHT.
To commit or void all inflight transactions in a batch, use the batch_id. For independently-created inflight holds, see Bulk commit & void.
Response
Webhook notifications
When usingrun_async: true, the API sends webhook notifications upon completion or failure.
The webhooks follow this structure:
- Successful webhook
- Failure webhook
Usage examples
- Synchronous
- Asynchronous
- Inflight
Process multiple transactions atomically (
atomic: true, run_async: false):Response
Error handling
Structured errors are available from Blnk Core 0.15.0 and later.
error_detail objects for validation failures. For duplicate references and batch rollbacks, behaviour depends on skip_queue. See API error codes for the full catalogue.
Request validation errors
Blnk returns400 when the request body fails validation before processing starts.
For
TXN_VALIDATION_ERROR, error_detail.details.index identifies the zero-based position in transactions[]:
400 Bad Request
Duplicate references
Duplicate-reference handling depends on whether items go through the queue.- skip_queue: false
- skip_queue: true
On the default queued path, duplicate references are deduplicated in the queue and never recorded. The batch still returns
201 with status: "applied" representing the request was successfully submitted:201 Created
Important notes
- When
atomicistrue, transactions are processed in the order provided in the request. - Each transaction’s
referenceshould be unique. On the default queued path, duplicates are silently deduplicated rather than rejected - see Duplicate references. - When
run_asyncistrue, processing happens in the background and you’ll receive an immediate response with a batch ID. - For large transaction batches, using
run_async: trueis recommended to avoid timeout issues. - Webhook notifications for async processing contain the same detailed error information as synchronous responses, including rollback status.
- On the default queued path,
status: "applied"means the bulk request was accepted - search byparent_transactionormeta_data.QUEUED_PARENT_TRANSACTIONto verify final child statuses.