Webhooks recibidos

Requisitos previos de acceso

• Permiso (módulo): viewWebhooks O manageWebhooks (basta con uno de los módulos)
• Licencia/Feature: Ninguna
• Contenedor del menú: GENERAL → grupo Auditoría

Qué es / cuándo usar

La pantalla de Webhooks recibidos (/manage-webhooks) muestra el historial de callbacks que la plataforma recibió de proveedores externos (BaaS bancario, proveedores de pago, blockchain, etc.). Cada entrada registra el tipo de evento, el estado de procesamiento y el payload bruto recibido.

Use esta pantalla para investigar por qué un evento externo no se reflejó en la plataforma — por ejemplo, un depósito que no apareció, una confirmación de KYC que no llegó o una notificación de transacción que falló. El payload completo ayuda a comparar lo que el proveedor envió con lo que el sistema procesó.

Requisitos previos

• Permiso: módulo viewWebhooks (solo lectura) o manageWebhooks. El permiso es doble — enum CPM en el backend + módulo dinámico en la BD.
• Licencia/Feature: ninguna.
• Dependencias de otras pantallas: ninguna. Los webhooks son grabados automáticamente por el WebhookService a medida que llegan.

Paso a paso

1. Acceda al menú GENERAL → Auditoría → Webhooks.
2. La lista carga los webhooks recibidos, ordenados por fecha.
3. Haga clic en el ícono de visualización (ojo) de una fila para abrir el diálogo con el payload completo del evento.

Filtros y columnas

Filtro / Columna	Qué muestra	Origen del dato
Tipo	Tipo/entidad del evento recibido (p. ej.: el dominio que disparó el callback)	entity del registro de webhook
Estado	Resultado del procesamiento del webhook	status del registro
Fecha	Momento en que el webhook fue recibido/grabado	createTimeStamp
Acción (ojo)	Abre el diálogo con el cuerpo (JSON) recibido	body del registro

Acciones y modales

• Ver payload (ícono de ojo): abre el WebhookPayloadDialog, que muestra la entidad, el estado, el timestamp y el cuerpo bruto (body) del webhook. Es de solo lectura — sirve para comparar lo que el proveedor envió con el efecto (o la ausencia de efecto) en la plataforma.

Reglas de negocio / consideraciones

Atención

• El payload puede contener datos sensibles (documentos, identificadores de cuenta). Trate el contenido conforme a la política LGPD/PII de la operación.
• Un webhook con estado de fallo no significa necesariamente la pérdida del evento: muchos proveedores reenvían (retry). Verifique si existen entradas duplicadas del mismo evento antes de concluir que hubo pérdida.

• Idempotencia: el procesamiento de webhooks de eventos financieros es típicamente idempotente por identificador externo. Las reentregas del mismo evento son esperadas y no deben generar doble contabilización.

Pantallas relacionadas

• Fallos en la creación de Banco Digital
• Auditoría (visión general)