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 600.

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 certificate identifies Pluggy as the partner. It is ours, not your customer's, and it is the same certificate for every company we act for — there is no per-customer certificate to collect, 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. Without the authorisation, the certificate alone issues nothing; without the certificate, the authorisation is unusable.

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 is meant to remove all of that — boletos that look real, moved to any status on demand, firing the same webhooks a real bank would.

It is not available yet: the Sandbox connector does not accept boleto connections today. When it does, its boletos will carry a correctly shaped digitable line, barcode and PIX payload so your parsing and rendering are exercised, but they will not be valid payment instruments — nothing issued there can be paid at a real bank.