Webhooks are event notifications that can be sent to an organisation’s configured endpoint when certain activity occurs in BE Custody.
They can help organisations connect custody activity with internal systems, monitoring tools, reconciliation processes, compliance workflows, or operational dashboards.
Webhook availability, event types, payloads, and configuration depend on the organisation’s BE Custody setup and enabled services.
Why use webhooks?
Webhooks can support operational awareness by notifying internal systems when relevant events occur.
Depending on configuration, webhooks may help organisations:
- Track transaction activity
- Monitor workflow status changes
- Support reconciliation processes
- Trigger internal operational workflows
- Receive compliance-related event information, where supported
- Reduce reliance on manual status checks
- Improve visibility across custody operations
Webhooks should be implemented as part of a controlled integration design.
How do webhooks work?
A webhook is typically sent from BE Custody to an endpoint configured by the organisation.
The receiving system should process the webhook, validate it where applicable, and decide what internal action to take. For example, a webhook may be used to update an internal system, alert an operations team, or reconcile transaction status.
Organisations should not rely on webhooks as the only source of truth for critical decisions. Webhook events should be reconciled with BE Custody records, API responses, or internal records where appropriate.
Who should manage webhooks?
Webhooks should be managed by authorised technical or operational teams within the organisation.
This may include:
- Engineering teams
- Platform operations teams
- Treasury operations teams
- Reconciliation teams
- Compliance operations teams
- Security teams
- Internal tooling teams
Responsibilities for webhook configuration, monitoring, retry handling, and incident response should be clearly defined.
What should developers consider?
When implementing webhooks, organisations should consider:
- Endpoint security
- Authentication or validation controls, where supported
- Secure handling of payload data
- Retry and failure handling
- Idempotency and duplicate event handling
- Logging and monitoring
- Alerting for failed deliveries
- Reconciliation against BE Custody records
- Access controls for internal systems receiving webhook data
- Change management and testing before production use
Webhook payloads may contain sensitive operational information and should be handled accordingly.
What should not be included in logs or support requests?
Do not expose API keys, API secrets, access tokens, private keys, seed phrases, passwords, PINs, or other sensitive authentication information in webhook logs or support requests.
If support is required, include non-sensitive information such as:
- Your organisation name
- The affected webhook or endpoint
- The approximate date and time
- The event type or workflow involved
- The response code or error message, where available
- A short description of the expected and actual behaviour
- Any relevant non-sensitive request or event identifier
What should I do if a webhook fails?
If a webhook fails, follow your organisation’s internal incident or integration support process.
Check endpoint availability, response codes, recent changes, logs, retry behaviour, and whether the receiving system processed the event correctly.
If further support is required, contact Bitpanda Enterprise Custody Support through the approved support channel.