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.