Webhooks deliver real-time notifications to your application when events occur in the Custody API. Every webhook delivery is signed with HMAC-SHA256 so you can verify authenticity.Documentation Index
Fetch the complete documentation index at: https://docs.quantumapi.io/llms.txt
Use this file to discover all available pages before exploring further.
Registering a webhook endpoint
Event types
Qustody emits 12 webhook event types across four categories.| Event | Trigger |
|---|---|
transaction.created | New transaction accepted by the API (state SUBMITTED) |
transaction.status_changed | Any transition between active states |
transaction.completed | Transaction reached COMPLETED |
transaction.failed | Transaction reached FAILED |
deposit.detected | Inbound transfer detected on a registered wallet |
deposit.confirmed | Inbound transfer confirmed with sufficient depth |
approval.required | Policy requires manual approval (state PENDING_AUTHORIZATION) |
approval.decision | An approver called approve or reject |
screening.submitted | Compliance screening was submitted to the provider |
screening.completed | Provider returned a clean result |
screening.flagged | Provider returned a flagged result requiring review |
screening.blocked | Provider blocked the transaction (state BLOCKED) |
* wildcards in event subscriptions. For example, transaction.* subscribes to all transaction events; screening.* subscribes to every compliance event.
Webhook payload format
Every delivery includes these headers:| Header | Description |
|---|---|
X-Webhook-ID | Unique delivery ID |
X-Webhook-Timestamp | Unix timestamp of the delivery attempt |
X-Webhook-Signature | HMAC-SHA256 signature for verification |
Content-Type | application/json |
HMAC-SHA256 verification
Always verify theX-Webhook-Signature header to confirm the payload came from Qustody and hasn’t been tampered with.
The signature is computed as:
Retry behavior
Failed deliveries are retried with exponential backoff:| Attempt | Delay |
|---|---|
| 1 | Immediate |
| 2 | 30 seconds |
| 3 | 2 minutes |
| 4 | 10 minutes |
| 5 | 1 hour |
| 6 | 6 hours |
What counts as a failure?
- HTTP response status outside
200–299 - Connection timeout (10 seconds)
- DNS resolution failure
- TLS handshake failure
Managing endpoints
Best practices
Respond quickly
Return
200 OK immediately and process the event asynchronously. Slow responses trigger retries.Handle duplicates
Use the
id field to deduplicate. Retries may deliver the same event multiple times.Verify signatures
Always validate HMAC-SHA256 before processing. Reject unsigned or invalid deliveries.
Monitor dead letters
Set up alerting on dead-letter events to catch configuration issues early.