event is always subscription; the concrete event name is in data.event_type.
Example delivery payload
attempt_number and failure_reason.
Events emitted today
subscription.createdsubscription.startedsubscription.renewedsubscription.updatedsubscription.canceledsubscription.payment_failedsubscription.past_duesubscription.trial_will_endsubscription.chargeback_received
Pix Automático sequence
Pix Automático subscriptions use the same envelope and event names. What changes is when each event arrives:- Without a trial: no event at creation.
subscription.started, withprevious_status: "incomplete", arrives once the payer has authorized and the first debit is paid. - With a trial:
subscription.createdarrives when the payer approves the authorization (statustrialing,latest_transaction: null).subscription.trial_will_endarrives 3 days beforetrial_endif the subscription is alreadytrialingby then, andsubscription.startedwith the first debit after it. - Rejected authorization, or, depending on the account configuration, an expired one:
subscription.canceled, withfailure_reason. - Later cycles:
subscription.renewedfor each paid debit. After a failed debit,subscription.payment_failed, plussubscription.past_duewhen the subscription moves topast_due. - Cancellation:
subscription.canceled, neversubscription.updated.
latest_transaction.method is "pix". Pix Automático charges do not send transaction.* webhooks, and a failed debit does not create a transaction, so on failure events latest_transaction is the most recent transaction of the subscription. The full table is in Pix Automático Subscriptions.
Plan changes
Plan changes apply to card subscriptions only. A plan change does not introduce a new event type. It arrives assubscription.updated, and update_fields tells you what moved: ["product_id", "amount"] when the new plan is now being billed, ["pending_change"] when a change was scheduled or a scheduled one was cancelled.
When a plan actually moves — immediately, or when it is scheduled — the payload also carries a plan_change block:
effective_at is the end of the current period; for an immediate one, it is the moment it was applied.
Two cases deliberately arrive without plan_change, and its absence is how you tell them apart from the cases above:
- A scheduled change was cancelled. You receive
subscription.updatedwithupdate_fields: ["pending_change"]and noplan_changeblock. - A scheduled change took effect at renewal. No
subscription.updatedis sent for it. You receive the usualsubscription.renewed, already carrying the newamount, andpendingChangeisnullon the next read.
Handling guidance
- Deduplicate by the top-level event
id. - Use
data.event_typeto route each event to the correct handler. - Use
data.statusfor the current subscription state. - Use
latest_transactionfor the billing transaction linked to the event. On Pix Automático failure events, it is the most recent transaction of the subscription. - Use the UUID in
data.idas the subscription identifier. - Reconcile with
GET /v2/subscriptions/{id}if delivery or processing is interrupted.

