v2.41.1 — A refused internal transfer no longer comes back as pending

Provider refusals now answer 422. POST /v1/accounts/{accountId}/transfers/internal (and the /by-document and /by-bank-account variants) used to answer 202 with status: "PENDING" when the banking provider refused the operation — the transfer was definitively over, yet the response asked you to wait. Refusals now come back as 422 with status: "FAILED", errorCode and errorReason, as the contract already documented. 202 PENDING is now reserved for the indeterminate case (operation still running when the synchronous window ends).
insufficient_funds instead of partner_rejected when balance is the reason. The provider refuses internal transfers for lack of balance with a generic message (“the provider refused the operation”). We now read the available balance at refusal time: when it does not cover the requested amount, the response is insufficient_funds. Without that evidence the refusal stays partner_rejected, with the provider’s reason in the partner block.
Correct workflowId for internal transfers. Repeating the POST with the same Idempotency-Key returned a workflowId carrying the PIX out prefix. It now carries the operation’s real id (internal-out-…).
TED no longer stays in PROCESSING forever. The settlement bank’s outcome did arrive, but it was delivered to the wrong process and lost — and the TED record was never updated. As a result, GET /transfers/ted/{tedId} and the statement showed “processing” even for TEDs already settled or rejected, and a rejection only surfaced as ted.out.failed 48h later, with a generic timeout reason instead of the real rejection. The outcome is now applied as soon as it arrives, and the TEDs that were stuck have been reconciled with their real state.
TED: bankCode only accepts the 3-digit Compe code. Sending the 8-digit ISPB in that field is now rejected upfront with 400 invalid_bank_code. Before, the request was accepted with 202, reached the settlement bank with no destination bank, and the TED stayed stuck in PROCESSING — never settling, never failing. ISPB remains valid for PIX by bank account (bankIspb).

Internal transfers have no failure webhook

The transfer.internal.out webhook is only delivered when the transfer settles. For a refusal the outcome lives in the response to the call itself — which is why the 422 above matters. Do not wait for a webhook to close a refused internal transfer.

v2.42.0 — Temporary access suspension for open pendencies

Two new codes: tenant_suspended and tenant_disabled. When there is an open pendency, a tenant’s access can be suspended temporarily. With the tenant suspended, reads (GET) keep working — balance, statement, operation status — and writes answer 403 tenant_suspended. With the tenant disabled, every route answers 403 tenant_disabled.
The credential is not revoked. The same client_id/client_secret keeps issuing tokens normally; the refusal happens on the API call. Once the pendency is cleared, access returns on the next call — no new credential, no new token.
Incoming money keeps flowing. Received PIX is still credited and the webhooks for those events are still delivered. Suspension blocks starting new operations, not receiving.

Details in the Authentication Guide.