Webhooks notify your own HTTPS callback about your account’s events,
cryptographically signed.
Create a subscription
event_type: one of the events below, or * for all.
callback_url: HTTPS required; localhost and private IPs are
rejected — for local development use an
HTTPS tunnel.
secret: at least 16 characters; used to sign every delivery. Stored
encrypted and cannot be retrieved.
The subscription receives your account’s events. You can list active
subscriptions at any time:
Events
Payload of each event
In payout_status_changed and crypto_withdrawal_status_changed, status
can be completed or failed (with failed, the debit has already been
refunded by the time you receive the event).
Every delivery is a JSON POST with these headers:
Verify the signature
Compute the HMAC over the raw body (bytes as received), not over
re-serialized JSON. Reject old timestamps (> 5 minutes) to prevent replay.
Retries and idempotency
- Your endpoint must respond 2xx within the timeout; anything else is
retried.
- Up to 5 attempts with incremental backoff:
- Use
X-Webhook-Event-ID to deduplicate: the same event can arrive more
than once (at-least-once delivery).
- If all 5 attempts fail the event is not resent — recover the state with
the resource’s
GET (which is why no flow should depend ONLY on the
webhook).
Best practices
- Respond
200 immediately and process in the background.
- Log the
X-Webhook-Delivery-ID for traceability.
- Don’t rely solely on webhooks for critical states: you can always query
the object by API (
GET /v1/payouts/{id}, etc.).