Cancel an authorization at the payer's request
Revokes the mandate at the payer’s request. The revocation is IMMEDIATE and CASCADES over every debit scheduled under it, retries after the due date included — except those due for settlement on the day the revocation happens, which are preserved by rule (Guia v1.2 §3.7.1).
The termination and the scheduled-debit cascade commit together or not at all, so a mandate cannot be revoked while cancellable debits remain active.
A non-zero preservedScheduledPayments is CORRECT behaviour, not a partial failure. Those debits will still settle today, and the payer is shown the count so they know it.
The body’s reason is a free-text note for the payer’s own audit trail. It is NOT the value sent to the counterparty: the receiving PSP is told motivoCancelamento = SLDB, the pain.011 code for a cancellation the paying user asked for, which the response echoes as counterpartyReason.
A revocation over a mandate that has upcoming debits reports non-zero values on either counter, so a caller must read them rather than assume zero.
Autorizações
JWT bearer token issued by the identity provider.
Cabeçalhos
Non-zero UUID of the payer account selected by the calling PSP. The PSP must authorize its end user for that account before calling this API. A resource outside the selected account returns 404; a read with no records returns an empty page. See the API overview for the complete trust boundary.
^[0-9A-Fa-f]{8}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{12}$REQUIRED. Client-supplied replay key, at most 64 bytes. A request without it is refused with PIX-0030 @ 400 before the handler runs. Replaying the same key with a divergent method, URL or body is PIX-0031 @ 412. X-Account-Id is part of the compared request too, so replaying one account's key under another account is divergent rather than a replay.
1 - 64Parâmetros de caminho
Internal identifier of the mandate being revoked. A request or mandate that exists under a DIFFERENT account than X-Account-Id names is answered 404, not 403: the lookup carries the account as a predicate, so this end never learns that a resource exists elsewhere and cannot confirm it.
"01a044a8-f3bd-7488-a0dc-e8d4be4802be"
Corpo
Optional. Carries the payer's own free-text note, which is never forwarded to the counterparty.
Free-text note for the PAYER's own audit trail. It is NOT the value sent to the counterparty: the receiving PSP is told a fixed code this end chooses, which the response echoes as counterpartyReason.
200"Payer requested revocation in the mobile app"
Resposta
Recovered duplicate. The same X-Idempotency header was replayed with an identical request, so the FIRST call's response body is returned verbatim and nothing was reprocessed. A replay answers 200 whatever the original status was, so a client tells a replay from a fresh execution by the status code alone. NOTE: this 200 depends on the replay cache. The gate DEGRADES when the cache is unavailable -- it still demands the header, and each route still refuses a second effect through its own durable guard -- but a repeat is then answered by that guard rather than replayed, which for most routes is 409. A client must therefore treat 409 as a possible answer to a retry it believes is a replay, and must not read it as proof that a competing change happened.