Coverage

Every institution on the Boleto Management API speaks the same API: one request to register a charge, one response shape, one set of statuses, one boleto/updated webhook. What differs between banks is how a Boleto Connection is established — what your customer has to provide, and whether they provide it to you or to the bank.

Institutions#

Connector ids, for GET /connectorsAPI: Inter Empresas 225, Bradesco 285, Sandbox 8.

Inter Empresas#

Inter is the reference implementation: everything below happens behind the same endpoints described in the Boleto Management API guide.

Credentials. Inter authenticates with four artifacts — a Client ID, a Client Secret, a private key and a certificate — created inside Inter's own Internet Banking. When creating the integration at Inter, enable both Boleto and Extrato scopes: a credential missing the Boleto scope connects successfully and then fails on the first issue attempt, which is a confusing place to discover the problem.

Two ways to connect. Going through an Item is the better default when you already collect account data for the same customer: one connection, one set of credentials, and the customer authorises once. Sending the credentials directly is for when there is no Item to reuse.

How Inter reports a payment. Inter notifies us and we translate its vocabulary into the statuses the API exposes:

When a boleto becomes PAID, Inter also reports what was actually paid and how, which lands in amountPaid and paymentOrigin (typically PIX or BOLETO).

Notifications. Inter publishes the IP ranges its notifications originate from, and we only accept callbacks from those addresses. Nothing is required from you — what you receive is our own boleto/updated webhook, authenticated the same way as every other Pluggy webhook.

Worth knowing before you go live

• nossoNumero is Inter's, and its format is Inter's. Do not parse it or assume a width; it will differ from what another institution returns for the same charge.
• A late payment is normal. Inter accepts payment after the due date, so a boleto can go OPEN → OVERDUE → PAID. Handlers that stop listening once a boleto is overdue miss real revenue.
• Reconcile on amountPaid, not amount. Discounts, fines and interest make them differ in both directions.

Bradesco#

Bradesco boleto issuing is not available yet. The model being built is described here so you can plan for it; the endpoints and the connection flow are not live, and the details may change as the integration is finished.

Every other institution on this API works the same way: your customer hands over credentials, we hold them, and we act with them. Bradesco separates identifying the caller from authorising the action:

The partnership is ours. Pluggy is a Bradesco partner, and that is what identifies the caller on every request — the same for every company we act for. There is nothing here for you or your customer to provide, install or renew.

The authorisation is granted once per company, by that company, inside Bradesco's own environment. Bradesco has confirmed this cannot be done through an API: the person authorising logs in at Bradesco, accepts the terms and confirms with a security key generated on their own device. We never see the password, the key, or the terms being signed. The two are independent and both are required: the authorisation is what a company grants, the partnership is what lets us act on it. Neither issues anything on its own.

What this means for your onboarding. Connecting a Bradesco account will involve a redirect: your customer leaves your interface, authorises at Bradesco, and returns. That is a different shape from the credential form used for Inter, and it introduces a state a credentials-only flow never has — a connection that exists but is not yet usable. Worth designing for now if Bradesco is on your roadmap.

Still being settled with Bradesco: the exact contract of the callback that confirms an authorisation; whether an authorisation expires, and whether revoking it inside Bradesco produces any notification; the onboarding path for companies that are not already Bradesco account holders; how a company with several CNPJs authorises for all of them.

Sandbox#

Testing a boleto integration against a real bank is slow and partly impossible: you need a business account, a real payer willing to pay a real charge, and for anything involving a due date you would have to wait for the date to arrive. The Sandbox connector removes all of that: it issues boletos that look real and moves them to the status you choose by themselves, firing the same webhooks a real bank would.

It is available now, with connector id 8. Its boletos carry a correctly shaped digitable line, barcode and PIX payload so your parsing and rendering are exercised, but they are not valid payment instruments — nothing issued there can be paid at a real bank. See Testing with the Sandbox for how the cents of the amount pick the scenario.