Skip to main content
Webhooks let Yativo push real-time event notifications to your server the moment something happens — a deposit confirms, a card transaction clears, a swap completes. This guide covers registering webhooks, verifying signatures, handling events correctly, and understanding the retry policy.
Test webhooks against the Sandbox at https://crypto-sandbox.yativo.com/api/v1/. Use a tool like ngrok or Hookdeck to expose your local server during development.
1

Create a webhook endpoint in your app

Your webhook handler must:
  • Accept POST requests at a public HTTPS URL
  • Parse the JSON body and verify the X-Yativo-Signature + X-Yativo-Timestamp headers before processing
  • Return HTTP 200 within 5 seconds
  • Process event logic asynchronously after returning 200
TypeScript
2

Register the webhook with Yativo

Register your endpoint and select which event types you want to receive.
Response:
Store the secret securely in an environment variable or secrets manager. It can be retrieved later via GET /v1/yativo-card/webhooks/:webhookId, but treat it like a password.
3

Verify webhook signatures

Every delivery includes two headers:The HMAC is computed over "${timestamp}.${JSON.stringify(payload)}". Always verify this signature before processing the event.
TypeScript
Always use a timing-safe comparison function (timingSafeEqual, hmac.compare_digest, hash_equals). Using a regular string equality check (===) exposes you to timing attacks.
4

Handle events idempotently

The same event may be delivered more than once (see Retry Policy below). Your handler must be idempotent — processing the same event twice should produce the same result as processing it once.
TypeScript
Store processed event IDs in a database table with a unique index on id. Use the insert as an upsert or check-then-insert within a transaction to prevent race conditions when events arrive in parallel.
5

Return 200 quickly and process asynchronously

Yativo waits up to 5 seconds for an HTTP 200 response. If your server does not respond in time, the delivery is treated as failed and will be retried.Pattern: Respond 200 first, then process.
TypeScript
In production, use a job queue (e.g., BullMQ, Celery, SQS) rather than setImmediate so events survive server restarts.
6

Understand the retry policy

If your endpoint returns a non-2xx status code, times out, or is unreachable, Yativo retries the delivery with exponential backoff:After 7 failed attempts, the event is marked as permanently failed and no further retries are made. You can manually replay failed deliveries via POST /v1/yativo-card/webhooks/deliveries/:deliveryId/retry.
Because retries are possible, your handlers must be idempotent (see Step 4). A 200 response stops retries — never return 200 if you have not processed (or enqueued) the event.

Event Types Reference

Deposit Events

Transaction Events

Card Events

Card issuer events and general crypto events share the same webhook service. Register at POST /v1/webhook/create-webhook and include the relevant card event slugs in your events array. See Card Issuer Webhook Events for full payload examples.

IBAN Events

KYC Events

Webhook Event Envelope

All events share a common envelope. The request body is JSON; delivery metadata is carried in HTTP headers. Request body:
Request headers: Body fields:

Managing Webhooks