Skip to main content
Available in version 0.15.3 and later.
A dry run answers whether a transaction would apply and what the source and destination balances would become. Nothing is written: no transaction, no queue entry, no webhook, and no new @ balance. You can reuse the same reference on a real post afterwards. Send the same request you would use to record the transaction, and set dry_run to true. Blnk runs the same balance arithmetic a real post uses, then returns a projection. Use a dry run to check funds, overdraft rules, or split math before you post. It is a snapshot of balances as they stand now.

​
Dry-run a transaction

Call Dry-run a transaction with the same body as Record a transaction, plus "dry_run": true.
The same dry_run flag works on bulk create, refund, and commit or void inflight.
The response is always HTTP 200 when the preview itself succeeds. A projected rejection is not an HTTP error.
200 OK
Things to note:
  • There is no transaction_id. Nothing was written, so the reference is still free to use on a real post.
  • dry_run takes precedence over skip_queue. The preview always answers synchronously.

​
Read the response

Amounts on the preview are minor-unit strings. Convert with the same precision you sent: display_amount = precise_amount / precision. An @indicator that does not exist yet is projected against a zeroed stand-in and marked virtual: true. A real post would create that General Ledger balance. The dry run does not. notes carries warnings that are not rejections, such as a currency mismatch or a scheduled_for date (the preview applies as if now).

​
When the transaction would fail

If the transaction would be rejected, you still get HTTP 200. Read would_apply and rejection, not the status code.
200 Would not apply
rejection.code is the same catalog code a real post would return, so existing handling for codes like TXN_INSUFFICIENT_FUNDS still works. On rejection, resulting_* matches current_*. The failed apply is not shown as a partial movement, and status is omitted. Some failures never become a preview. Request validation and a missing balance ID return the same HTTP error a real post returns (400, 404). Those run before the dry-run branch.

​
Bulk and split transactions

Bulk create and multiple sources or destinations use the same dry-run pattern. skip_queue changes how the preview treats items in the batch:
  • true: the result is cumulative. Later transactions use the resulting balance change from earlier processed transactions in the dry run.
  • false: the result is independent. Each item is processed on its own. Balance changes from other items in the same request are not applied.
In this example bln_source-bal-001 has 500.00 available. The batch sends 450.00 to bln_dest-bal-001, then 100.00 to blnk_dest-bal-002.
Set skip_queue to true. The first item leaves 50.00. The second item needs 100.00, so would_apply is false.
200 OK

​
Need help?

We are very happy to help you make the most of Blnk, regardless of whether it is your first time or you are switching from another tool. To ask questions or discuss issues, please contact us or join our Discord community.