Available in version 0.8.4 and later.
PRE_TRANSACTION vs POST_TRANSACTION runs, and product-level guidance, start with Introduction to hooks. For patterns like fraud checks or KYC, see Hook examples.
Prerequisites
- Blnk Core base URL — e.g.
http://localhost:5001or your deployed instance (replaceYOUR_BLNK_INSTANCE_URLin the examples). - Master key — required for all hook management requests as of 0.14.3. Use
server.secret_keyfrom your Blnk configuration. - HTTPS in production — your hook
urlshould use TLS in live environments.
Authentication
Hook management endpoints require the master key (server.secret_key). Send it in the X-Blnk-Key header.
Header name is case-insensitive; examples on this page use
X-Blnk-Key for readability.Register a hook
Blnk sends an HTTP POST to yoururl when a transaction matches the hook type. Delivery is asynchronous: hook failures are isolated from the core transaction (see Introduction to hooks).
| Field | Description | Required | Type |
|---|---|---|---|
name | Human-readable label for operators and logs. Use something you can recognize in dashboards and audits. | Yes | string |
url | Absolute HTTPS (recommended) or HTTP URL that accepts POST requests from Blnk. | Yes | string |
type | Either PRE_TRANSACTION (before the transaction is applied) or POST_TRANSACTION (after). | Yes | string |
active | When false, Blnk skips this hook until you enable it again. | Yes | boolean |
timeout | Maximum time in seconds Blnk waits for your endpoint to respond per attempt. | Yes | number |
retry_count | Maximum additional attempts after a failed delivery (network error, timeout, or non-success HTTP status). Tune this with your idempotency strategy on the receiver side. | Yes | number |
Response
Exact JSON keys may vary slightly by Blnk version. Use the hook identifier returned by your instance for update, get, and delete calls.
After a successful response, store
hook_id. You need it for Get, Update, and Delete.Quick start: two hooks
Pick endpoints in your app
Implement
POST handlers that read JSON, return 2xx quickly, and do heavy work asynchronously if needed. Your server must be reachable from Blnk Core.Register each hook with POST /hooks
Create one hook with
"type": "PRE_TRANSACTION" and one with "type": "POST_TRANSACTION" if you need both lifecycle stages.Verify signatures on inbound traffic
Blnk signs hook deliveries. Follow Webhook security (signature verification) so you only process genuine callbacks.
Create examples (PRE and POST)
What Blnk sends to your url
Each delivery is a POST whose JSON body includes the transaction context. Typical top-level fields:
| Field | Description |
|---|---|
transaction_id | Ledger transaction identifier |
hook_type | PRE_TRANSACTION or POST_TRANSACTION |
timestamp | When Blnk built the payload |
data | Transaction object (amount, balances identifiers, status, meta_data, etc.) |
PRE_TRANSACTION deliveries usually see an early status such as QUEUED. POST_TRANSACTION deliveries reflect the transaction after application (for example APPLIED), depending on your flow.
Sample delivery bodies
Related documentation
Hooks overview
Lifecycle, async behavior, and hook types.
Webhook security
Signatures, timestamps, and hook headers.
Hook examples
Fraud, KYC, loyalty, and reconciliation-style patterns.
Secure your Blnk server
API keys,
server.secret_key, and operational hardening.