# Webhook Notifications

Eleven events, signed, at least once — the full transaction lifecycle pushed to your backend.

Every polling loop is a trade-off between API load and how stale your ledger is. Webhooks invert
it: eleven signed event types push each state change to your backend as it happens, with delivery
evidence you can inspect and replay.

## The event contract

- **The outgoing lifecycle** — requested, approved, rejected, broadcast, mined, failed.
- **Incoming deposits** — at first sight and at confirmation, for coin, token and internal
  transfers.
- **Confirmation depth is per chain** — 6 blocks on Bitcoin-family, 12 on EVM, so you credit users
  exactly as your risk policy dictates.
- **HMAC-SHA256 signature header on every delivery**, HTTPS only, so your endpoint can prove the
  event came from us.
- **At least once, with idempotency keys** — duplicate delivery is a guarantee we keep rather than
  a bug we hide. Handle events idempotently and dedupe is a one-liner.

## When your endpoint is down

Failed deliveries retry on an exponential schedule, so a short outage does not lose an event.
Delivery logs are retained and any event can be re-sent from the dashboard, with the API as the
source of truth behind it. Webhook endpoints are included from Standard: three on Standard, five
on Business.

## FAQ

**What happens if we miss a delivery?**
Retries with exponential backoff first, then replay from the dashboard. Combined with the API as
source of truth, nothing is lost.

**How do we verify a delivery is genuine?**
Check the HMAC signature header against your webhook secret. Standard practice, and non-optional
in our docs.

## Related

- [Automation Workflows](/features/automation-workflows)
- [Dashboard + API](/features/dashboard-and-api)
- [Audit Trail](/features/audit-trail)
- [Pricing](/pricing)