Architecture overview

Bre-B is Colombia's interbank instant-payment scheme — a real-time rail similar to Brazil's Pix or India's UPI that lets any participant bank or licensed entity send and receive funds 24/7 in seconds. The Bre-B Participant API gives you a programmable on-ramp to that network: you authenticate with OAuth, register tenant accounts, generate QR codes for incoming payments, and dispatch outgoing transfers against payment keys (aliases such as phone, document, email, alphanumeric, or merchant code).

This page is the right starting point if you want to understand the path a request takes from your code to the Bre-B central directory and back.

Components

Request lifecycle (outgoing transfer)

1. Authenticate — exchange client credentials for an OAuth access token.
2. Resolve the target — submit the payment key; receive the holder's name and bank.
3. Dispatch — submit the resolved target with amount and idempotency key.
4. Track lifecycle — webhooks fire on every state transition.
5. Reconcile — credit or release the operation in your books.

Tenant model

Every customer is a Bre-B participant tenant at Mono. Tenant accounts are isolated; resolutions and transfers always operate against a specific tenant.

Lifecycle references

Once a request enters the platform it moves through a deterministic state machine, and every transition emits a webhook. The two flows have their own lifecycle pages — read these alongside the architecture above to understand what your integration should be listening for.

• Outgoing transfer lifecycle — states, webhook events, and terminal outcomes for payouts you dispatch.
• Collection lifecycle — states, webhook events, and terminal outcomes for QR codes and payment keys that receive funds.

Next steps

• Authentication
• Concepts
• Integration example