> ## Documentation Index
> Fetch the complete documentation index at: https://docs.walletsuite.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Webhooks Overview

> React to on-chain events in real time. WalletSuite delivers signed, structured event data to your servers as events happen - no polling required.

WalletSuite webhooks push a signed HTTP request to your endpoint the moment an on-chain event touches an address you watch. Instead of polling for state, your backend reacts to events as they happen - credit a deposit, start a fulfillment job, or reconcile a treasury inflow within seconds.
Every delivery is signed to the [Standard Webhooks](https://www.standardwebhooks.com) spec, so you can cryptographically verify it originated from WalletSuite before you act on it.

## 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 |

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

## Explore the docs

<CardGroup cols={2}>
  <Card title="Quickstart" icon="rocket" href="/webhooks/quickstart">
    Provision a signing secret, create your first subscription, and receive a real event end to end.
  </Card>

  <Card title="Delivery & retries" icon="arrows-rotate" href="/webhooks/delivery">
    Acknowledgement rules, the full retry schedule with jitter, ordering, and at-least-once semantics.
  </Card>

  <Card title="Verify signatures" icon="shield-check" href="/webhooks/verify">
    Standard Webhooks verification, raw-body handling, and replay protection.
  </Card>

  <Card title="Event reference" icon="list" href="/webhooks/events">
    The `transfer.received` payload, field-by-field semantics, and chain-specific address encodings.
  </Card>

  <Card title="Best practices" icon="circle-check" href="/webhooks/best-practices">
    Idempotency, async processing, schema evolution, and forward-compatible event handling.
  </Card>

  <Card title="Troubleshooting" icon="wrench" href="/webhooks/troubleshooting">
    Signature mismatches, missed events, paused endpoints, and how to debug deliveries locally.
  </Card>
</CardGroup>