event envelope. Transfer webhooks use a payout type envelope.
Envelope comparison
Payment webhook example
data.informations echoes the custom informations you sent when creating the transaction via the API; it is present only when you sent custom entries. See Payment Events.
Transaction events also carry data.customer (buyer name, email and phone — never the
document), data.products (purchased line items, same shape as the transaction detail endpoint) and
data.attribution (campaign UTMs, ad click IDs, affiliate src/sck, the checkout URL we derive
and the one someone declared, plus the referrer). All are optional: customer and attribution can be null, products can be empty, and
attribution is always null for API-created transactions. See Payment Events.
Transfer webhook example
Subscription webhook example
transaction.* event, and the first event depends on whether the subscription has a trial. See the Pix Automático sequence in Subscription Webhooks.
Verifying signatures
When a webhook has a Security Token, verify these headers before you trust the body:
The HMAC key is the Security Token. The message is the timestamp, a
., and the exact HTTP body:
rawBody is the exact HTTP body you received. A webhook with no Security Token is unsigned. notify_url postbacks are unsigned.
Set the Security Token in the dashboard under Settings → Integrations when you create or edit the webhook. The field reads “Generated automatically if empty.” Leave it blank to generate one automatically.
Reconciling the resource with GET remains recommended. A runnable check is in the TypeScript webhooks example.
ACK response
Common ingestion error
id, deduplicate by that value, return 200 OK quickly, and process asynchronously.
Mapping guidance
- Drive business state from resource status, not from a frontend guess.
- Route subscription lifecycle changes from
data.event_type. - Map transfer event
payout.transferredto settled resource statuspaid. - Reconcile if your worker crashes after acknowledgement.

