What Is a Webhook (in Plain English)?

Short Answer

A webhook is the way one app tells another app that something happened, the moment it happens. When a customer pays in Stripe, Stripe fires a webhook to whatever URL you have given it, saying “payment X just succeeded”. When a contact updates in HubSpot, HubSpot fires a webhook to your system saying “contact Y just changed”. The receiving system processes the message and updates whatever it needs to. The alternative is polling (the reason webhooks exist), where the second system asks “anything new?” every few minutes, which is wasteful and slow. Webhooks flip that around: the originating system pushes the news the instant it occurs. They are the plumbing of modern real-time integration.

How Webhooks Actually Work

The mechanics are simpler than the jargon suggests.

A webhook is just an HTTP POST request to a URL you control. The sending system (Stripe, HubSpot, GitHub, whatever) is configured to call that URL whenever a specific event happens. The request includes a payload, usually JSON, describing what just occurred: the event type, the relevant data, the timestamp.

Your system receives the request, validates it (typically using a signature header to confirm the request really came from the sender), processes the payload, and responds with a success status code. The whole thing happens in tens of milliseconds, and your data is updated in near real time without any polling.

The basic setup is three steps:

1. Your system exposes a URL (say, https://yourapp.com/webhooks/stripe) that knows how to handle Stripe events
2. In Stripe’s settings, you tell Stripe to send specified events to that URL
3. When the event happens, Stripe POSTs the event to your URL; your code processes it

The implementation challenges are not in the basic flow; they are in the edge cases. What happens if your endpoint is down when the webhook fires? (Most providers retry, but you need to handle duplicates.) What happens if the webhook arrives twice? (Idempotency: processing the same event twice should not produce two outcomes.) What happens if events arrive out of order? (Rare but real, and your code should handle it.) These are the things that separate a webhook handler that works in development from one that works in production.

Why Webhooks Matter for Businesses

Webhooks make real-time integration possible. Without them, the alternative is polling every few minutes, asking each system “anything new?”, which is wasteful (most polls return nothing), slow (data is up to several minutes out of date), and expensive (lots of API calls counting against rate limits).

The business effect is anything you have ever wanted to happen “the moment X occurs”: send a welcome email the moment a customer signs up, alert the team the moment a high-value lead arrives, update the dashboard the moment a payment lands, kick off the onboarding workflow the moment a contract is signed. All of these depend on webhooks underneath.

A specific example: a B2B SaaS business needs to provision access to a client portal the moment a contract is signed. Without webhooks, they would poll the contract platform every five minutes, find new signatures, and trigger provisioning. With webhooks, the contract platform calls their endpoint the instant a signature is recorded, and provisioning happens within seconds. The user experience goes from “you will have access soon” to “your dashboard is ready”, which is the difference between a feature that works and one that delights.

What to Look For

• Signature verification. Webhooks should be signed by the sender so you can verify they are genuine. Without verification, any attacker who guesses your URL could fake events. Every major provider (Stripe, HubSpot, GitHub, etc.) supports this.
• Idempotency. Your handler should be safe to call twice with the same event. Duplicates happen through retries, provider bugs, and network hiccups. Idempotency means the second processing is harmless.
• Retry handling. Senders typically retry failed deliveries (5xx responses, timeouts). You need to respond with success quickly and process asynchronously if the work is heavy, otherwise the sender’s retry clocks will fire before you finish.
• Monitoring and logging. Webhooks fail silently if you let them. Log every incoming webhook, alert on failures, and have a way to replay missed events if they pile up.
• A dead-letter queue. Events that fail to process repeatedly should go somewhere visible, not get lost. A queue of failed webhooks is the safety net that prevents lost data.

Common Mistakes

The most common mistake is processing the webhook synchronously inside the handler. The work (creating records, triggering emails, calling other APIs) takes longer than the sender will wait, the sender retries, and you end up processing the same event multiple times. The right pattern is to acknowledge the webhook immediately (return a 200) and queue the work for asynchronous processing. The second is skipping signature verification. The third is not handling the case where webhook delivery fails. Providers retry for a while, but eventually give up; without a backup polling mechanism for critical events, missed webhooks become missed data permanently.

How We Approach This

We build webhook handlers as production-grade infrastructure, with signature verification, idempotency, async processing, monitoring, and dead-letter queues as defaults. The basics are quick to set up; the engineering is in the edge cases.

Use Webhooks Where They Belong

Webhooks sit at the core of real-time API integrations. For the broader picture of how systems connect, What Is an API and Why Does It Matter? is the right starting point, and What Is an API Integration covers how integrations are built in practice. The Knowledge Center has the full range of guides. If you have a specific event-driven use case in mind, that is the natural starting point for a conversation.