Skip to main content
Webhooks push real-time events to your server so you don’t have to poll. Use them to react to deposits, transfers, customer creation, and verification state changes.

Add an endpoint

1

Open Webhooks

In the dashboard, go to Webhooks and click Add endpoint.
2

Set your URL

Enter an HTTPS URL on your server that can receive POST requests.
3

Choose events

Subscribe to the events you care about. You can change these any time.

Wallet events

Transfer lifecycle payloads contain transfer_id, your reference, and the normalized status. Treat REQUIRES_REVIEW as non-terminal. Yara may later reconcile the transfer to SUCCEEDED or FAILED.

Customer events

See Customer webhooks for payload fields and verification-state behavior.

USD virtual-account deposit events

These events include the Yara virtual-account, customer, and deposit IDs; gross amount; Yara fee; net merchant credit; normalized status; and timestamps. They do not expose provider fees or provider balance movements. Treat the completed event as the balance-credit notification.

Transfer funding events

Both events contain transfer_id, funding_intent_id, and a merchant-safe receipt snapshot. transfer.funding.received does not mean the payout has already been submitted. A mismatched bank or crypto receipt is followed by transfer.funding.flagged and receives no automatic ledger credit or reservation.

Payload

Every webhook is a JSON POST with an event ID, event name, resource data, and creation time.

Verify signatures

Each endpoint has a signing secret. Yara signs the exact request body with HMAC-SHA256 and sends the lowercase hexadecimal digest in X-Yara-Signature. Calculate the digest from the raw body before JSON parsing. Compare it to the header using a constant-time comparison. Reject the delivery when the values do not match. Rotate the secret from the dashboard if you suspect it has been exposed.

Inspect delivery history

You can review outbound event history from the API:

Best practices

  • Respond fast. Return a 2xx quickly and do heavy work asynchronously.
  • Be idempotent. The same event may be delivered more than once — de-duplicate on the event id.
  • Retry-friendly. Failed deliveries are retried; you can review status in the dashboard or via the endpoint above.