Skip to main content
The BlooBank Transactions Engine API is the canonical entry point for moving money on the BlooBank platform. This page sketches the surrounding architecture so you can reason about where your integration sits in the bigger picture.

​
The integration surface

You will work with two control planes:

Transactions Engine API

REST API. Provision wallets, create and approve payment orders, query state. The subject of this documentation.

Webhooks

Server-pushed events. Receive lifecycle notifications for payment orders so your reconciliation does not depend on polling.
Both surfaces share a single Access Protocol — ECDSA secp256k1 signatures over canonical request strings. The same credential identifies your service on the API and authenticates webhook deliveries (in the reverse direction).

​
Request path

​
Boundaries you must reason about

These boundaries shape your integration design — choose where each lives in your stack.

​
Reliability model

  • API requests — strongly consistent. A 201 Created response means the resource is persisted.
  • Payment-order settlement — asynchronous. A 201 Created on POST .../paymentOrders means the order is accepted, not settled. The order moves through lifecycle states and finalizes when the provider confirms.
  • Webhook delivery — at-least-once. Events can be redelivered. Idempotent consumers are required — see Best practices.

​
Next

Resources & naming

How resources are identified and versioned.

Authentication

The Access Protocol — your entry point.