Skip to main content

Setup

Yativo sends webhook notifications to your registered HTTPS endpoint via HTTP POST whenever a program event occurs. Each request is signed with HMAC-SHA256 so you can verify it genuinely came from Yativo. Register your endpoint at the unified webhook endpoint. Card issuer events and general crypto events share the same service — subscribe to any combination.
Store the secret securely — use a secrets manager or environment variable. The secret is also retrievable later via GET /v1/yativo-card/webhooks/:webhookId. If compromised, rotate it via POST /v1/yativo-card/webhooks/:webhookId/rotate-secret.
Pass "events": ["*"] to receive all event types. Other management endpoints:

Event categories

Event reference

Payload structure

All webhook events share a common envelope. The data object contains event-specific fields. The event type is also sent in the X-Yativo-Event request header.

Payload examples

master_wallet.deposit

You will receive this event twice for a single deposit: once immediately when funds are detected (processing), and again when settlement is confirmed (settled). The payload shape differs between the two states. status: "processing" — fired as soon as the incoming deposit is detected.
status: "settled" — fired once the funds are settled into your master wallet.

master_wallet.swap

Fired when a token swap is submitted from your master wallet.

customer.funded

Fired when a customer’s card wallet has been credited. The transfer_id can be looked up via Get Transfer.

customer.funding.failed

Fired when a funding transfer to a customer’s card wallet fails.

master_wallet.customer_funded

Fired alongside customer.funded whenever your master wallet is debited. Includes remaining_balance when the transfer settles immediately; omitted when the balance updates asynchronously.

card.frozen

Fired when a card is frozen, either by your program or by the customer.
The card_id field in webhook events is the card token identifier. This may differ from the card_id returned by the Get Customer endpoint. Use yativo_card_id as the stable cross-reference between webhook events and API responses.

customer.balance.updated

Fired whenever the card provider reports a balance change — after a purchase authorization, settlement, top-up, or reversal. Provides the full balance breakdown so you can update your UI in real time without polling.

transaction.authorized

Fired when a card transaction is authorized at the point of sale. A customer.balance.updated event typically follows immediately.
billing_amount/billing_currency reflect the card’s own settlement currency and are present on every transaction event, not just foreign-currency ones — on a same-currency purchase like this one they simply equal amount/currency. See the full transaction event reference for the foreign-currency case and the fx_rate calculation.

card.lost

Fired when a card is reported lost.

Signature verification

Every webhook request includes an X-Yativo-Signature header and an X-Yativo-Timestamp header. The event type is also in the X-Yativo-Event header and the unique delivery ID in X-Yativo-Delivery-Id. Verify signature and timestamp before processing the event. The signature is computed over the raw request body (the exact JSON bytes received), prefixed with the timestamp.
Always verify the signature before trusting the payload. Use express.raw({ type: 'application/json' }) (not express.json()) so you have the raw bytes for verification.

Delivery history

Both delivery history endpoints accept the same query parameters: Results are sorted newest first.
Examples
Each record in the response includes: To see the full payload and per-attempt log for a delivery, call GET /v1/yativo-card/webhooks/deliveries/:deliveryId.

Retry policy

Yativo retries failed webhook deliveries using exponential backoff. Respond with any HTTP 2xx status code to acknowledge receipt and prevent retries. After 7 failed attempts the delivery is marked permanently failed — no further automatic retries. You can manually replay individual deliveries via POST /v1/yativo-card/webhooks/deliveries/:deliveryId/retry. If your endpoint fails 100 consecutive deliveries, Yativo will automatically disable the subscription to protect your program’s event queue. Re-enable it via PUT /v1/yativo-card/webhooks/:webhookId with { "enabled": true } after fixing the issue.
To avoid processing duplicate events, use the top-level id field (e.g. evt_1747058400000_abc123) as an idempotency key. The X-Yativo-Delivery-Id header carries the delivery record ID (a separate identifier used to retry individual deliveries via the API).