Webhooks Overview - WalletSuite

What you can build

Credit user balances on deposit - fire as soon as funds reach a watched deposit address, without polling get_tx_status in 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

Confirm authoritative state via the REST API before moving money or releasing goods - the webhook payload is a trigger, not the final word.

Explore the docs

Quickstart

Provision a signing secret, create your first subscription, and receive a real event end to end.

Acknowledgement rules, the full retry schedule with jitter, ordering, and at-least-once semantics.

Standard Webhooks verification, raw-body handling, and replay protection.

The transfer.received payload, field-by-field semantics, and chain-specific address encodings.

Idempotency, async processing, schema evolution, and forward-compatible event handling.

Signature mismatches, missed events, paused endpoints, and how to debug deliveries locally.