Skip to main content
Most HIFI resources settle asynchronously - an Onramp clears a fiat deposit, a Compliance review resolves, a Bridge confirms on the destination chain. Webhooks push each of these changes to your own endpoint as they happen, so you don’t have to poll GET endpoints to find out. See Webhooks for the full list of event types HIFI can send.

Register an endpoint

Registers a URL to receive deliveries and returns a signingSecret for verifying them. subscriptions is the list of event types to receive - an endpoint only receives events it’s explicitly subscribed to. A profile can register up to 16 endpoints. Request
Response
signingSecret is only ever returned once, in this response - store it right away. It isn’t included in any later GET, and there’s currently no endpoint to rotate it; if it’s compromised, delete the endpoint and register a new one.

Event payload

Every delivery is a POST with this envelope. data is always the resource’s full current state - the same shape you’d get back from GET.

Verify the signature

Every delivery includes a hifi-signature header so you can confirm it actually came from HIFI:
  • t - the Unix timestamp (seconds) the request was signed.
  • v1 - an HMAC-SHA256 hex digest of {t}.{raw request body}, keyed with the endpoint’s signingSecret.
Recompute the digest over the exact raw body and compare against v1 with a constant-time comparison: Javascript Example
Verify against the raw request body, before any JSON parsing - re-serializing the parsed object won’t necessarily byte-match what was signed. We also recommend rejecting requests where t is too far in the past, to guard against replay.

Retries

A delivery succeeds on any 2xx response. Anything else - a non-2xx status, a timeout, no response - is retried with exponential backoff: 30 seconds, then doubling each attempt (with a little jitter) up to a cap of 24 hours, for up to 10 attempts total. After the final failed attempt, that event type’s subscription on that endpoint is disabled - nothing further is sent for it until you re-subscribe (PATCH the endpoint with subscriptions again).

Webhooks can arrive out of order

Events are queued and retried independently of each other, so your endpoint isn’t guaranteed to receive them in the order the underlying changes actually happened. A resource can go PENDINGCOMPLETED, but a retried or delayed delivery means the PENDING event’s request can land at your endpoint after the COMPLETED one. Don’t treat “a webhook arrived” as the update itself. Instead, do one of:
  • Trust the payload’s own status, with a forward-only guard. Read data.status (or the resource’s equivalent field) off the event and compare it against whatever you last recorded for that resource. Only apply the update if it represents the same or a later point in that resource’s lifecycle than what you already have - an event carrying an earlier-stage status than what you’ve already recorded should be discarded, not applied. Once a resource reaches a terminal status, no later event should be able to move it out of that state.
  • Treat the webhook only as a signal, not as data. On receipt, ignore data entirely and call GET on the resource by its id instead, then apply whatever that response says. This sidesteps ordering completely, since a fresh GET always reflects current state regardless of which webhook happened to arrive first.

Resend a delivery

Re-queues a specific event for redelivery to a specific endpoint - useful after fixing whatever caused it to fail. Request
Response

Delivery status

Endpoint status

Getting Help

  • 📧 Email: support@hifi.com
  • 💬 Slack: Message us in our shared Slack channel
  • Webhooks - Every event type HIFI supports, by resource
  • Onramps - Convert fiat into stablecoins
  • Offramps - Convert stablecoins into fiat