The short answer
A webhook is an HTTP request that one system sends to another when something happens. Instead of your app asking Stripe "has anyone paid yet?" every few seconds, Stripe calls a URL you gave it, the moment the payment succeeds.
That URL is your webhook endpoint. The request body describes the event, usually as JSON, and headers carry metadata such as a signature that proves who sent it.
What a webhook looks like
Here is a typical delivery, trimmed:
POST /webhooks/stripe HTTP/1.1
Host: api.yourapp.com
Content-Type: application/json
Stripe-Signature: t=1730419200,v1=5257a869e7ec…
{"id":"evt_1Q…","type":"invoice.paid","data":{"object":{…}}}Your endpoint does three things: check the signature, record the event, and answer with a 2xx status quickly. Anything else (a 5xx, a timeout, a dropped connection) tells the sender the delivery failed, and most senders will try again later.
Webhooks vs. polling vs. WebSockets
| Webhooks | Polling | WebSockets | |
|---|---|---|---|
| Who starts the request | The provider | Your app | Your app opens, then both sides talk |
| Latency | Seconds | Up to your polling interval | Milliseconds |
| Cost when nothing happens | None | A request every interval | An open connection per client |
| Works server-to-server | Yes, the usual choice | Yes | Rarely offered by providers |
| Main risk | Missed or duplicate deliveries | Wasted requests, rate limits | Reconnects, state on both sides |
Use webhooks when another company's system needs to tell your backend about events: payments, pushes to a repository, orders, form submissions.
Use polling when the provider has no webhooks, or as a safety net: a nightly job that lists recent objects catches anything a webhook missed.
Use WebSockets for live, two-way traffic with your own users' browsers, such as chat, collaborative editing or live dashboards. Providers rarely offer them for server-to-server events.
What goes wrong with webhooks
Webhooks are simple to start with and easy to get subtly wrong:
- Your endpoint is down during a deploy, and the provider gives up after its own retry schedule.
- Someone forges a request to your public URL, because the signature isn't checked. See Webhook security and HMAC verification.
- The same event arrives twice, and your app charges, emails or ships twice. See Retries, idempotency and failures.
- Nobody can tell what happened, because the request and the response were never recorded.
Where HookStead fits
HookStead gives each provider a stable URL, verifies the provider's signature on arrival, stores every event before answering, then forwards it to your endpoint with retries, its own signature and a full record of every attempt. When something breaks you can see it, fix your endpoint and replay.
- Set it up in five minutes with the user guide.
- Follow the Stripe or GitHub guide.
- Compare plans: the free plan covers 10,000 events a month.