# Inter Empresas

Inter Empresas is the first institution available on the Boleto Management API, and the reference implementation: everything on this page happens behind the same endpoints described in the [Boleto Management API](/docs/boleto/management-api) guide.

## Establishing a connection

Inter authenticates with four artifacts — a Client ID, a Client Secret, a private key and a certificate — created inside Inter's own Internet Banking. The [Banco Inter Empresas tutorial](/docs/developer-tools/tutorials/inter-pj) walks through producing them.

<Callout variant="warning" title="Enable the right permissions">
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.
</Callout>

There are two ways to turn those credentials into a connection:

```mermaid
graph TD
  A[Credentials from Inter] --> B[Connect through Pluggy Connect<br/>creates an Item]
  A --> C[Send credentials directly<br/>POST /boleto-connections]
  B --> D[POST /boleto-connections/from-item]
  C --> E[Boleto Connection]
  D --> E
```

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 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:

| Inter `situacao` | Becomes |
|---|---|
| `RECEBIDO` | `PAID` |
| `MARCADO_RECEBIDO` | `PAID` |
| `ATRASADO` | `OVERDUE` |
| `PROTESTO` | `PROTESTED` |
| `A_RECEBER` | ignored — the boleto is simply still open |

When a boleto becomes `PAID`, Inter also reports what was actually paid and how, which lands in `amountPaid` and `paymentOrigin`. `paymentOrigin` is typically `PIX` or `BOLETO`, reflecting how the payer chose to settle.

<Callout variant="info" title="Cancellations do not arrive by webhook">
A boleto you cancel through [POST /boletos/{id}/cancel](/reference/boleto-cancel) is marked `CANCELLED` immediately, as part of that call. But a boleto cancelled directly inside Inter's own portal will not update on our side — that path produces no status change you can observe. If your operations team cancels boletos at Inter rather than through the API, treat our status as authoritative only for boletos cancelled through the API.
</Callout>

## Authenticating the notifications

Inter publishes the IP ranges its notifications originate from, and we only accept callbacks from those addresses. Nothing is required from you — the notification 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 differs from what another institution will return 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.
- **Test the partial-payment path.** `amountPaid` can be lower or higher than `amount` once discounts, fines or interest apply. The [Sandbox](/docs/boleto/sandbox) produces it on demand: issue a boleto with an amount ending in `,01` and it is paid for half.