Skip to content
>
Mode: standard
Dashboard

Webhooks

Authenticated · Event-Driven

Real-time event delivery, signed at the source.

Webhooks let CoinPayments push real-time updates to your platform — payments received, withdrawals confirmed, invoices closed out — so you don't have to poll. Every callback is HMAC-signed; verify it just like you'd verify any other API signature.
Configure client webhooksAuthenticate requests

What this API does

Signed requests required

Wallet webhooks

Get notified the moment a deposit hits any address on a wallet, or when an outgoing send progresses.
Learn more

Client webhooks (Invoice)

Manage webhook endpoints at the integration level — multiple endpoints, scoped to specific event types, with full CRUD.
Learn more

Signed callbacks

Every webhook is signed with an HMAC signature. Verify the signature before trusting the payload, just like outbound API requests.
Learn more

Event coverage

Receive invoice paid / cancelled, deposits, and withdrawal lifecycle events. Subscribe to as much or as little as you need.
Learn more

Event Types We Deliver

Today
  • Invoices

    Lifecycle events for hosted invoices, Buy Now buttons, and white-label checkout.

  • Withdrawals (sent)

    Spend-request confirmations and on-chain progress for transactions originating from your wallets.

  • Deposits (received)

    Incoming transactions credited to one of your wallet addresses.

One webhook per confirmation — until fully confirmed

CoinPayments fires a webhook on every confirmation a transaction accrues, not just the final one. If a chain requires 6 confirmations, you'll receive 6 progress events (plus the terminal credit event) — one for 1/6, one for 2/6, and so on. The per-chain target lives in the requiredConfirmations field on the Currencies route — and the same value is echoed inside every webhook payload body, so you can render confirmations / requiredConfirmations progress without an extra lookup. Don't credit on the partial events; key off the terminal status — which is confirmedOnBlockchain for on-chain (external) transactions and completed for internal ones. See Transaction Statuses for the distinction.

Acknowledge with 200 OK immediately

Respond to every webhook with an HTTP 200 right away — before you do any real work. Anything other than 2xx (or a slow response) is treated as a failed delivery and we'll retry, which compounds with the per-confirmation cadence and can stampede your endpoint. Acknowledge first, then process the event off the request thread (queue it, hand it to a worker, etc.).

Idempotency is non-negotiable

Webhook delivery can be delayed by network latency or retried by our infrastructure. While unlikely, on-chain confirmation may arrive before the corresponding webhook event, and you'll receive multiple events as a transaction progresses through its confirmations. Your credit-processing logic must be idempotent — guard against double-crediting by storing the event id and rejecting duplicates.

Verify before you trust

Every webhook callback carries an HMAC signature. Always verify it against your integration's client secret before acting on the payload — see Authenticating Requests for the recipe (it mirrors how outbound API requests are signed).

Where to next?

Pick the most useful next step.

Authenticating Webhooks
Verify the HMAC signature on incoming callbacks.
Wallet Webhooks
Per-wallet and per-address delivery configuration.