Skip to main content
Esta página lista todos os eventos que você pode passar em subscribedEvents ao registrar um endpoint de webhook. Os nomes dos eventos seguem a convenção {resource}.{subject}. Os eventos são disparados em transições do status publicamente observável do recurso — estados exclusivamente internos nunca produzem eventos de webhook.

Wildcards

Além de nomes de evento individuais, subscribedEvents aceita:

Eventos de cliente

Disparados à medida que o perfil de verificação de um cliente avança pelo seu ciclo de vida de status. Um evento é disparado por perfil de verificação por transição — um cliente com múltiplos perfis produz um fluxo de eventos independente por perfil. Exemplo — customer.approved:
O campo cause é reservado para um motivo de rejeição legível por máquina. Atualmente ele é sempre null, inclusive em customer.rejected — motivos de rejeição estruturados serão lançados em uma próxima versão.

Eventos de transferência

Disparados à medida que uma transferência avança pelo seu ciclo de vida de status. Webhooks agora são a forma recomendada de acompanhar o progresso de transferências. Exemplo — transfer.succeeded:
Os nomes de eventos de transferência usam o nome público do recurso na API (transfer.*), enquanto data.id usa o prefixo payout_ — correspondendo aos IDs retornados pela API /v2/transfer hoje. transferType é staticTransfer para on-ramper accounts e offloader wallets, e oneTimeTransfer nos demais casos. O status depreciado undeliverable não produz eventos.
O campo cause é reservado para um motivo de falha legível por máquina em eventos de falha terminal (transfer.failed, transfer.returned, transfer.expired, transfer.canceled, transfer.failedPrecondition, transfer.unexpectedError). Atualmente ele é sempre null — motivos de falha estruturados serão lançados em uma próxima versão.
Última modificação em 11 de agosto de 2026