Webhook Integration Guide
Webhooks allow your application to receive real-time notifications when transaction events occur, instead of polling for status changes.Overview
Step 1: Register a webhook
Subscribe to all events
Use* to receive every event type:
Available events
Step 2: Verify webhook signatures
Every webhook request includes anx-zet-signature header containing an HMAC-SHA256 signature of the request body, computed using your webhook secret.
Always verify signatures to ensure the webhook came from Zet and wasn’t tampered with.
Step 3: Handle events
Webhook payload structure
Example handler
Retry policy
If your endpoint doesn’t respond with a2xx status within 30 seconds, Zet retries with exponential backoff:
After 5 failed retries, the webhook is marked as failed. You can check missed events via the Transactions API.
Managing webhooks
List all webhooks
Delete a webhook
Per-transaction callbacks
In addition to global webhooks, you can specify acallbackUrl when initiating a transaction. This URL receives events for that specific transaction only:
Best practices
- Always verify signatures — never process unsigned or incorrectly signed webhooks
- Implement idempotency — webhooks may be delivered more than once; deduplicate by
transactionId+event - Respond quickly — return
200immediately, then process asynchronously - Use a queue — push webhook payloads to a queue (SQS, Redis, etc.) for reliable processing
- Log raw payloads — store the raw request body for debugging and auditing
- Use raw body for verification — don’t parse and re-serialize JSON before verifying the signature
- Monitor webhook health — alert if your endpoint starts returning errors
- Use HTTPS only — webhook URLs must use HTTPS with a valid TLS certificate
- Set up a fallback — periodically poll the Transactions API to catch any missed events
- Limit to 10 webhooks — you can register up to 10 webhook URLs per API key
