v2.43.0 — Granular scopes on integration credentials

You choose what each credential can do. When creating a credential in the panel (API Credentials), a tenant manager picks the scopes: read, qrcode.manage, pix_keys.manage, webhooks.manage, exports.create and med.defend. A credential without the route’s scope gets 403 insufficient_scope naming the missing scope.
A QR-code credential can see its own QR’s payment. qrcode.manage covers creating, cancelling and reading the QR (GET .../pix/qr-code/lookup), so you can have a charge-only credential with no access to balance or statement.
Per-account restriction. A credential can be limited to specific accounts of the tenant — that is how you give a subsystem access to a single account. No user can issue a credential broader than their own access.
Money-moving scopes are issued by CorpX (pix_out.create, refund.create, internal_transfer.create, ted.create, boleto_payment.create, med.decide). Requesting one from the panel returns 403 scope_not_self_service.
Existing credentials are unchanged. Current integrations keep full access (api2/read api2/write) and need no action.

v2.43.1 — Inflow credential with no access to balance or statement

read is no longer mandatory. It now covers only the account-wide queries (balance, statement, timeline, entries) and is optional when creating a credential. Previously every credential was issued with read, which blocked the very use case granularity exists for.
Every scope queries its own domain. qrcode.manage alone creates the QR and sees whether it was paid; pix_keys.manage lists the keys; exports.create downloads the file; webhooks.manage follows the deliveries; med.defend queries the MEDs. The same holds for cashout scopes and the status of their own operations.
qrcode.manage plus one account is now a credential that charges by QR code on that account and sees nothing else.
Credentials already issued are unchanged — those created earlier keep the read they were given. To restrict, issue a new credential and revoke the old one.