Received Webhooks

Access Prerequisites

• Permission (module): viewWebhooks OR manageWebhooks (either module suffices)
• License/Feature: None
• Menu container: GENERAL → group Audit

What it is / when to use

The Received Webhooks screen (/manage-webhooks) displays the history of callbacks the platform received from external providers (banking BaaS, payment providers, blockchain, etc.). Each entry records the event type, the processing status, and the raw payload received.

Use this screen to investigate why an external event was not reflected in the platform — for example, a deposit that did not appear, a KYC confirmation that did not arrive, or a transaction notification that failed. The full payload helps you compare what the provider sent with what the system processed.

Prerequisites

• Permission: module viewWebhooks (read-only) or manageWebhooks. Permission is dual — CPM enum on the backend + dynamic module in the DB.
• License/Feature: none.
• Dependencies on other screens: none. Webhooks are recorded automatically by the WebhookService as they arrive.

Step by step

1. Go to the menu GENERAL → Audit → Webhooks.
2. The list loads the received webhooks, sorted by date.
3. Click the view icon (eye) on a row to open the dialog with the full event payload.

Filters and columns

Filter / Column	What it shows	Data source
Type	Type/entity of the received event (e.g.: the domain that triggered the callback)	entity of the webhook record
Status	Result of webhook processing	status of the record
Date	Moment the webhook was received/recorded	createTimeStamp
Action (eye)	Opens the dialog with the received body (JSON)	body of the record

Actions and modals

• View payload (eye icon): opens the WebhookPayloadDialog, which shows the entity, status, timestamp, and the raw body (body) of the webhook. It is read-only — it is used to compare what the provider sent with the effect (or lack of effect) on the platform.

Business rules / notes

Attention

• The payload may contain sensitive data (documents, account identifiers). Handle the content in accordance with the operation's LGPD/PII policy.
• A webhook with a failure status does not necessarily mean the event was lost: many providers retry (retry). Check whether there are duplicate entries for the same event before concluding that a loss occurred.

• Idempotency: processing of financial event webhooks is typically idempotent by external identifier. Redeliveries of the same event are expected and must not result in double accounting.

Related screens

• Digital Bank creation failures
• Audit (overview)