Mandate revocation initiated
Triggered when a wallet revocation is submitted. mandate.status becomes revocation_pending. This happens regardless of whether the mandate was previously canceled. New authorizations are blocked while in revocation_pending. Wait for revocation_succeeded or revocation_failed before acting.
Authorizations
HMAC-SHA256 signature of the raw request body, computed using your webhook secret. Webhook receivers should always verify this header before processing the event. The header value is hex-encoded and prefixed by the algorithm and timestamp, e.g. t=1700000000,v1=abc123... (refer to the Webhook Security docs for the exact verification algorithm).
This scheme applies to webhook delivery (outbound POSTs from CDP to your endpoint), not to inbound CDP API requests.
Body
The acceptance.mandate.revocation_initiated webhook event payload.
The acceptance.mandate.revocation_initiated event. data carries the full mandate and the revocation. Emitted when a wallet revocation is submitted to the network.
Unique identifier for this webhook event. Use this for idempotency.
"123e4567-e89b-12d3-a456-426614174000"
When this event occurred (ISO 8601 format).
"2025-06-01T12:00:00Z"
The data payload for every mandate webhook event. Always contains the full mandate. Action events also carry the relevant sub-resource: approval on the three approval_* events, revocation on the three revocation_* events. The created and canceled events carry only the mandate.
mandate.status reflects only the latest action. Read mandate.canceledAt and mandate.revokedAt to know what has durably happened: the on-chain spending allowance is gone precisely when revokedAt is set, and canceling alone does not remove it.
The type of webhook event.
acceptance.mandate.revocation_initiated "acceptance.mandate.revocation_initiated"
Response
Webhook received and processed successfully.