subscribedEvents al registrar un endpoint de webhook. Los nombres de eventos siguen la convención {resource}.{subject}. Los eventos se disparan en las transiciones del estado públicamente observable del recurso — los estados internos nunca producen eventos de webhook.
Comodines
Además de nombres de eventos individuales,subscribedEvents acepta:
Eventos de cliente
Se disparan a medida que el perfil de verificación de un cliente avanza por su ciclo de vida de estados. Se dispara un evento por perfil de verificación por transición — un cliente con múltiples perfiles produce un flujo de eventos independiente por perfil.
Ejemplo —
customer.approved:
El campo
cause está reservado para una razón de rechazo legible por máquina. Actualmente siempre es null, incluso en customer.rejected — las razones de rechazo estructuradas llegarán en una próxima versión.Eventos de transferencia
Se disparan a medida que una transferencia avanza por su ciclo de vida de estados. Los webhooks son ahora la forma recomendada de rastrear el progreso de las transferencias.
Ejemplo —
transfer.succeeded:
Los nombres de eventos de transferencia usan el nombre público del recurso de la API (
transfer.*), mientras que data.id usa el prefijo payout_ — coincidiendo con los IDs que devuelve la API /v2/transfer hoy. transferType es staticTransfer para cuentas on-ramper y billeteras offloader, y oneTimeTransfer en los demás casos. El estado deprecado undeliverable no produce eventos.El campo
cause está reservado para una razón de fallo legible por máquina en los eventos de fallo terminal (transfer.failed, transfer.returned, transfer.expired, transfer.canceled, transfer.failedPrecondition, transfer.unexpectedError). Actualmente siempre es null — las razones de fallo estructuradas llegarán en una próxima versión.