Skip to main content
Available from Blnk Core 0.15.0.
Blnk returns a stable error_detail.code on API errors. Use this code for programmatic handling. Treat error, errors, and error_detail.message as display text only.

Error response shape

Error responses include error_detail and error (or errors on some list and filter endpoints):
Error response
{
  "error": "transaction not found",
  "error_detail": {
    "code": "TXN_NOT_FOUND",
    "message": "transaction not found",
    "details": {}
  }
}
FieldDescription
error_detail.codeStable code from the catalog below. Branch on this field, not on message text or error / errors.
error_detail.messageHuman-readable message. May change between releases.
error_detail.detailsOptional structured context (filter parse errors, reindex progress, batch IDs, and similar).
error or errorsExist for backwards compatibility and display.
Unclassified server failures return HTTP 500 with the sanitized message "internal server error". The underlying error is logged server-side and is not echoed to clients.

How to handle errors

Handle Blnk API errors in two steps:
  1. Use the HTTP status code to understand the type of failure.
  2. Use error_detail.code to decide what your application should do.
Recommended flow
const body = await response.json();

if (!response.ok) {
  const code = body.error_detail?.code;

  switch (code) {
    case "TXN_NOT_FOUND":
      // Show a not found state or retry with a valid transaction ID.
      break;
    case "TXN_DUPLICATE_REFERENCE":
      // Treat as a conflict. You may fetch the existing transaction by reference.
      break;
    case "TXN_INSUFFICIENT_FUNDS":
      // Ask the user to fund the source balance or choose another source.
      break;
    default:
      // Fall back to status-based handling.
      break;
  }
}
When debugging, log:
  • HTTP status code
  • error_detail.code
  • error_detail.details when present
These fields give you the clearest context without depending on message text.
Do not build logic around error, errors, or error_detail.message. These fields are meant for display and may change between releases.

Error-code catalog

Codes are domain-prefixed. Each code has one default HTTP status.

Platform

Errors that apply across endpoints: malformed requests, validation failures, rate limits, lock contention, and unexpected server failures. Codes use the GEN_* prefix.
CodeHTTPMeaning
GEN_MALFORMED_REQUEST400Request body could not be parsed (invalid JSON, wrong types, or body too large)
GEN_VALIDATION_ERROR400Request failed validation (invalid params, filters, fields)
GEN_MISSING_PARAMETER400A required route or query parameter is missing
GEN_BAD_REQUEST400Request rejected; no more specific code applies
GEN_NOT_FOUND404Resource not found; no domain-specific code applies
GEN_CONFLICT409Request conflicts with current resource state
GEN_RESOURCE_LOCKED423A concurrent operation holds the lock; retry shortly
GEN_RATE_LIMITED429Too many requests
GEN_INTERNAL500Unexpected server failure; message is sanitized

Core resources

Errors when creating or fetching ledgers. Codes use the LGR_* prefix.
CodeHTTPMeaning
LGR_NOT_FOUND404Ledger does not exist
LGR_DUPLICATE409Ledger with this name or ID already exists

Other operations

Errors when updating metadata on ledgers, balances, transactions, and other entities. Codes use the META_* prefix.
CodeHTTPMeaning
META_ENTITY_NOT_FOUND404Entity for metadata update does not exist
META_UNSUPPORTED_ENTITY400Entity type does not support metadata
META_INVALID_ENTITY_ID400Entity ID is missing or malformed

Bulk commit and void

Bulk commit and void have two types of failures:
  1. Request-level failures
  2. Per-item failures
Request-level failures reject the whole request, i.e. they reject the whole call before any item runs. Per-item failures are returned inside the bulk result.
Request-level failures reject the whole request, i.e. they reject the whole call before any item runs. Per-item failures are returned inside the bulk result.The response applies the standard transaction error shape with codes such as TXN_BULK_EMPTY or TXN_BULK_LIMIT_EXCEEDED.
Empty batch
{
  "error": "transactions cannot be empty",
  "error_detail": {
    "code": "TXN_BULK_EMPTY",
    "message": "transactions cannot be empty"
  }
}
Bulk commit expects a transactions array. Bulk void expects transaction_ids. Sending the wrong shape returns TXN_BULK_EMPTY because unrecognized fields are dropped.

Legacy codes

Blnk normalizes older generic error names to canonical error_detail.code values before the response leaves the server. You will not receive legacy error names in error_detail.code. To handle legacy behaviour:
  • Use error_detail.code from the catalog above.
  • Prefer domain-specific codes over generic codes. For example, a missing transaction returns TXN_NOT_FOUND, not GEN_NOT_FOUND.
  • Do not parse error, errors, or error_detail.message to infer the code.
Legacy internal codeCanonical error_detail.code
NOT_FOUNDGEN_NOT_FOUND
CONFLICTGEN_CONFLICT
BAD_REQUESTGEN_BAD_REQUEST
INVALID_INPUTGEN_VALIDATION_ERROR
INTERNAL_SERVER_ERRORGEN_INTERNAL
RATE_LIMITEDGEN_RATE_LIMITED

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.