What you can build
- Credit user balances on deposit - fire as soon as funds reach a watched deposit address, without polling
get_tx_statusin a loop. - Trigger downstream workflows - start order fulfillment, send a notification, or release a digital good when payment arrives.
- Reconcile treasury inflows - stream every inbound transfer to your ledger as it confirms, with a signed, replay-protected record you can trust.
- Feed external systems - push confirmed transfers into your CRM, compliance, or accounting stack the moment they happen.
Webhooks vs polling
Webhooks are event-driven; the REST API is the source of truth for state. Use both - they answer different questions.| Webhooks | Polling | |
|---|---|---|
| Model | Push - we call you when an event occurs | Pull - you ask whenever you need an answer |
| Best for | Reacting to new on-chain events in near real time | Reading authoritative current state on demand |
| Latency | Seconds after first confirmation | As fast as you poll (and your rate limit allows) |
| Coverage | On-chain events on watched addresses | Any address, balance, tx, or fee the API exposes |
| Delivery guarantee | At-least-once, retried | Exactly the response to your request |
| Cost shape | One request per event | One request per poll, whether or not anything changed |
Explore the docs
Quickstart
Provision a signing secret, create your first subscription, and receive a real event end to end.
Delivery & retries
Acknowledgement rules, the full retry schedule with jitter, ordering, and at-least-once semantics.
Verify signatures
Standard Webhooks verification, raw-body handling, and replay protection.
Event reference
The
transfer.received payload, field-by-field semantics, and chain-specific address encodings.Best practices
Idempotency, async processing, schema evolution, and forward-compatible event handling.
Troubleshooting
Signature mismatches, missed events, paused endpoints, and how to debug deliveries locally.