Webhooks de Onboarding
Todos os eventos de onboarding seguem o envelope padrão de webhooks da plataforma (mesmo formato de entrega, autenticação, retries e idempotência). Esta página documenta os eventos específicos de accreditation.
Eventos
Assine accreditation.updated como fonte de verdade do progresso, e use accreditation.active / accreditation.failed como gatilhos terminais no seu sistema. Os eventos de link servem para automatizar a entrega dos links aos usuários finais.
O callbackUri não substitui estes eventos
Se você usa o retorno ao seu app, o outcome que chega na URI é uma dica de interface: ele viaja na barra de endereço e o próprio titular pode editá-lo. Use-o só para escolher que tela mostrar quando o usuário voltar. Todo gatilho com efeito no seu sistema continua vindo daqui — ou de GET /v1/accreditations/{accreditationId}.
accreditation.updated
Emitido em toda transição de estado, com o status anterior, o atual e o detalhe por pessoa.
accreditation.biometry.link.created
Emitido quando um link de captura facial é gerado para uma pessoa (na criação da accreditation e em cada retry).
No PJ, este evento é emitido uma vez por sócio — use o cpf para saber a quem entregar cada link.
accreditation.acceptance.link.created
Emitido quando um link de aceite de termos é gerado para uma pessoa. Só ocorre em fluxos habilitados sob demanda pela CorpX; no fluxo padrão este evento não é emitido.
accreditation.consent.link.created
Emitido quando o CPF informado já tem conta e a accreditation nasce em PENDING_CONSENT: em vez de abrir conta nova, o titular precisa autorizar que você opere a conta existente. Entregue o consentLink a ele. Reemitido a cada retry.
Detalhes da jornada em Titular que já tem conta.
accreditation.active
Evento terminal de sucesso — a conta está pronta para operar.
Quando a accreditation veio do fluxo de consent, o data traz dois campos adicionais:
account.shared_access.granted
Emitido para os tenants que já operavam uma conta quando o titular autoriza um novo tenant a operá-la também. O seu acesso não muda — este evento existe para você saber que a conta passou a ser movimentada por mais alguém.
Se o compartilhamento não faz sentido para o seu caso, acione o suporte: o titular pode revogar o acesso concedido, e a partir da revogação as chamadas do tenant revogado para aquela conta respondem 403.
accreditation.failed
Evento terminal de falha — o processo foi encerrado sem abertura de conta.
Valores comuns de errorReason:
Quando a recusa vem do liquidante, data traz também o bloco partner com o
que ele informou — o mesmo bloco aparece em GET /v1/accreditations/{id},
para consulta e webhook não divergirem:
As três chaves são opcionais: o bloco reflete o que o liquidante enviou, e há
recusas que chegam só com message. Use-o em log e suporte — a decisão do seu
código continua sendo por errorReason.
accreditation.pf.created / accreditation.pj.created
Emitidos na criação da accreditation (início do workflow), como confirmação assíncrona do POST. Assine-os no portal (Settings → Webhooks) ou via PUT na subscription.