Webhooks, Explained Without the Jargon

The idea in one paragraph

Two systems can stay in step in two ways. Polling means asking every few minutes whether anything has changed, which is wasteful and slow. A webhook means the first system sends a message the moment something happens, which is immediate and cheap.

Almost every modern platform supports them, and whether your integrations use them affects both cost and how current your data is.

Why it matters commercially

• Timeliness. Seconds instead of up to your polling interval.
• Cost. No charge for thousands of requests that find nothing changed.
• Rate limits. Polling frequently bumps into them; events do not.
• Simplicity. No need to track what you have already seen.

The catch: delivery is not guaranteed

Webhooks are messages, and messages get lost. Your server might be down, the network might fail, the sender might time out. A system that assumes every webhook arrives will silently miss data.

Every webhook integration needs a reconciliation job — a periodic check that compares both sides and fills gaps. Without it, you will find out about missed events from a customer.

What a well-built webhook receiver does

1. Verifies the signature, so nobody can send you fake events.
2. Responds immediately and processes afterwards, because senders time out.
3. Handles duplicates, because the same event can arrive twice.
4. Stores the raw payload before processing, so a bug can be reprocessed rather than lost.
5. Alerts on repeated failures rather than retrying silently forever.

Questions to ask your supplier

Do our integrations use webhooks or polling? Do we verify signatures? What happens when a webhook fails to arrive? Is there a reconciliation job, and when did it last find a discrepancy?

Those four questions will tell you quickly whether an integration is robust or merely working at the moment.

Frequently asked questions