Webhooks recebidos

Pré-requisitos de acesso

• Permissão (módulo): viewWebhooks OU manageWebhooks (basta um dos módulos)
• Licença/Feature: Nenhuma
• Contêiner do menu: GERAL → grupo Auditoria

O que é / quando usar

A tela de Webhooks recebidos (/manage-webhooks) exibe o histórico de callbacks que a plataforma recebeu de provedores externos (BaaS bancário, provedores de pagamento, blockchain, etc.). Cada entrada registra o tipo de evento, o status de processamento e o payload bruto recebido.

Use esta tela para investigar por que um evento externo não refletiu na plataforma — por exemplo, um depósito que não apareceu, uma confirmação de KYC que não chegou ou uma notificação de transação que falhou. O payload completo ajuda a comparar o que o provedor enviou com o que o sistema processou.

Pré-condições

• Permissão: módulo viewWebhooks (somente leitura) ou manageWebhooks. Permissão é dupla — enum CPM no backend + módulo dinâmico no DB.
• Licença/Feature: nenhuma.
• Dependências de outras telas: nenhuma. Os webhooks são gravados automaticamente pelo WebhookService conforme chegam.

Passo a passo

1. Acesse o menu GERAL → Auditoria → Webhooks.
2. A listagem carrega os webhooks recebidos, ordenados por data.
3. Clique no ícone de visualização (olho) de uma linha para abrir o diálogo com o payload completo do evento.

Filtros e colunas

Filtro / Coluna	O que mostra	Origem do dado
Tipo	Tipo/entidade do evento recebido (ex.: o domínio que disparou o callback)	entity do registro de webhook
Status	Resultado do processamento do webhook	status do registro
Data	Momento em que o webhook foi recebido/gravado	createTimeStamp
Ação (olho)	Abre o diálogo com o corpo (JSON) recebido	body do registro

Ações e modais

• Ver payload (ícone de olho): abre o WebhookPayloadDialog, que mostra entidade, status, timestamp e o corpo bruto (body) do webhook. É somente leitura — serve para comparar o que o provedor enviou com o efeito (ou ausência de efeito) na plataforma.

Regras de negócio / cuidados

Atenção

• O payload pode conter dados sensíveis (documentos, identificadores de conta). Trate o conteúdo conforme a política de LGPD/PII da operação.
• Um webhook com status de falha não significa necessariamente perda do evento: muitos provedores reenviam (retry). Verifique se há entradas duplicadas do mesmo evento antes de concluir que houve perda.

• Idempotência: o processamento de webhooks de eventos financeiros é tipicamente idempotente por identificador externo. Reentregas do mesmo evento são esperadas e não devem gerar dupla contabilização.

Telas relacionadas

• Falhas na criação de Banco Digital
• Auditoria (visão geral)