- Branches on HTTP status codes
- Parses error message text
- Expects inflight commit or void requests to return
APPLIEDorVOIDimmediately - Reads reconciliation status directly from the start response
At a glance
| Change | Who is affected? | What changed |
|---|---|---|
Structured error_detail added | Most integrations are not affected | Error responses now include error_detail.code, error_detail.message, and error_detail.details. The existing error field is still returned. |
| HTTP status codes corrected | Integrations that branch on old HTTP statuses | Some errors now return more specific statuses, such as 404, 409, 423, and 500. |
NOT_FOUND: message prefix removed | Integrations that parse error message text | Error messages no longer include the NOT_FOUND: prefix. |
| Inflight commit and void are queued by default | Integrations that expect immediate APPLIED or VOID responses | Commit and void requests now return a queued response by default. |
| Reconciliation start response changed | Integrations that read reconciliation status from the start response | Start endpoints return only reconciliation_id. Handle reconciliation.completed and reconciliation.failed webhooks for results. |
| Per-endpoint item limits | Integrations that send large bulk or reconciliation requests | Bulk create and instant reconciliation: max 10,000 items per request. Bulk commit and void: max 100 transactions. |
| Request and upload size caps | Integrations with large JSON bodies or file uploads | Configurable caps apply to JSON request bodies and multipart uploads. See Server and security configuration. |
| Transaction hash chain (optional) | Operators who want ledger-wide tamper detection | New opt-in global hash chain; disabled by default. Enable in config and run blnk verify-chain. See Transaction hashing. |
Structured error_detail added
Error responses now include a structured error_detail object.
The existing error field is still returned, so existing integrations that read error continue to work.
error_detail.code.
Do not branch on error, errors, or error_detail.message. These fields are human-readable and may change between releases.
See API error codes documentation for the errors catalog.
HTTP status codes corrected
Several errors that previously returned400 now return more specific HTTP statuses.
The response body still includes error and error_detail. The main change is the HTTP status code returned with the response.
Review any logic that:
- Treats every failed request as
400 - Branches only on HTTP status codes
- Does not read
error_detail.code
| Condition | Before | Now |
|---|---|---|
| Resource not found | 400 | 404 |
| Duplicate transaction reference | 400 | 409 |
| Inflight already committed or already voided | 400 | 409 |
| Identity field already tokenized | 400 | 409 |
| Tokenization disabled | 400 | 403 |
API key create or list request missing owner when using the master key | 401 | 400 |
| Hook infrastructure failures | 400 | 500 |
| Database backup failures | 400 | 500 |
| Lock contention | 400 | 423 |
| Unclassified internal failures | 400 | 500 (sanitized message) |
NOT_FOUND: message prefix removed
Error messages no longer include the NOT_FOUND: prefix.
If your integration checks for this prefix, update it to use error_detail.code.
error_detail.code is stable. Message text is meant for display and may change between releases.
Inflight commit and void are queued by default
Single and bulk inflight commit and void requests now go through the queue by default. This means the action is processed asynchronously instead of being applied immediately in the request cycle. By default, the response returns the transaction with:INFLIGHT until the worker processes the queued commit or void. A second queued commit or void for the same transaction returns 409 Conflict.
To keep the previous synchronous behavior, send skip_queue: true in the request body.
Use this when your app needs the request to return an immediate APPLIED or VOID response.
Reconciliation response changed
Start reconciliation and Instant reconciliation no longer return run status, match counts, or timestamps in the start response. Both endpoints now return onlyreconciliation_id.
Here’s the new flow:
- Start the reconciliation and save the returned
reconciliation_id. - Handle
reconciliation.completedorreconciliation.failedon your webhook endpoint. - Read status, match counts, and timestamps from the webhook payload.
Request and item limits
Blnk Core 0.15.0 adds per-endpoint item limits and configurable request size caps:| Endpoint | Max per request |
|---|---|
| Bulk transactions | 10,000 transactions |
| Instant reconciliation | 10,000 external transactions |
| Bulk commit inflight / Bulk void inflight | 100 transactions |
Recommended upgrade checklist
Before upgrading to v0.15.0:- Replace message-text parsing with
error_detail.code. - Review any logic that depends on HTTP status codes.
- Update inflight commit and void flows to handle queued responses or use
skip_queue: trueto keep existing synchronous behavior. - Update reconciliation flows to handle
reconciliation.completedandreconciliation.failedwebhooks instead of reading status from the start response.