What Is a Webhook — Explained for Non-Technical Founders

The customer pays online, but the order stays «pending» until an employee refreshes the admin. Stock runs out on the site while the inventory platform still shows 40 units. Thirty orders arrive overnight, but invoices get issued manually the next morning. All three have the same root cause: your apps don't tell each other when something happens. The webhook is the mechanism that fixes this — this article explains what it is, when to use it, and what goes wrong when it's implemented badly.

What a webhook is, in one sentence

A webhook is an automatic notification one application sends to another the moment an event occurs. Payment confirmed — Stripe sends a webhook. Invoice issued — the tax authority's e-Factura system sends a webhook. Customer placed an order — the e-commerce platform sends a webhook. The receiving side has a prepared URL (called an endpoint), and the notification is an HTTP request carrying the event data as JSON.

If you've read our article on REST APIs, think of it this way: with an API, you ask («any new orders?») and get an answer. With a webhook, you get told («there's a new order, here it is») without asking. That's why it's sometimes called a «reverse API»: the initiative comes from the system that holds the information, not the one waiting for it.

The problem it solves: webhooks vs polling

Before webhooks, the only way to find out «did anything new happen?» in time was polling: your app asked the partner system every 5 minutes. It works, but it has three concrete problems:

• Latency. Checking every 5 minutes means a confirmed payment can wait up to 5 minutes before reaching your system. On Black Friday, 5 minutes is dozens of orders stuck in «processing».
• Cost. 288 requests per day per integration, of which 280 find nothing new. Each one consumes server, database, and — on some APIs — quota from a paid limit.
• Rate limits. Large platforms (Stripe, marketplaces, government APIs) limit how many requests you can make per minute. Aggressive polling hits the limit fast, and subsequent requests get rejected with a 429 error.

The webhook inverts the model: zero requests until there is actually something to announce, then exactly one, in the second the event happens. The information arrives within a second of payment confirmation, the operating cost is near zero when nothing happens, and rate limits stop being a concern.

What a webhook looks like, concretely

The most common example in practice: a customer pays by card on your online store. Two or three seconds later, Stripe sends a request to your endpoint that looks, simplified, like this:

POST https://your-store.com/api/webhooks/stripe
{
  "id": "evt_1PxyzaBCD123",
  "type": "payment_intent.succeeded",
  "data": {
    "object": {
      "amount": 24900,
      "currency": "ron",
      "metadata": { "order_id": "4187" }
    }
  }
}

Three things to note: the event type (payment_intent.succeeded — the payment succeeded, not just «started»), the unique ID (evt_... — you use it for idempotency, see below), and the order data already included (no second request needed to learn the amount). Your app receives the request, marks order 4187 as «paid», issues the invoice, decrements stock — all automatic, within the same second.

You'll find the same structure everywhere: e-invoicing services (notify when an invoice is validated), shipping carriers (notify when a tracking number gets its first scan), marketplaces (notify on orders and stock changes), GitHub (notify on every push). Details differ; the mechanism is identical.

What the developer actually has to build (and why it's not trivial)

An endpoint that receives webhooks is not a simple «form that accepts data». There are four requirements any serious implementation handles:

1. Signature verification. Anyone who knows your URL can send a fake request that looks like a Stripe webhook. That's why Stripe (and every serious provider) signs each request with a shared secret, and your endpoint verifies the signature before processing anything. An unverified webhook is an open door: an attacker marks an order «paid» that was never paid.
2. Idempotency. The network isn't perfect: if your endpoint responds incorrectly or slowly, the provider resends the notification — sometimes multiple times. If you don't recognize that evt_1PxyzaBCD123 was already processed, you double-issue the invoice and decrement stock twice. The solution is simple (store the event ID, check before executing) but it must be done explicitly.
3. Fast response. The provider usually waits at most 5 seconds for a 200 OK. If your processing takes longer (submitting an invoice to a government API can take 10-30 seconds), don't hold the request open: acknowledge receipt immediately and process in the background, in a queue. Otherwise the provider considers delivery failed and enters retry mode.
4. Retry handling. Your server will be in maintenance or crash at some point, exactly when a webhook arrives. Providers retry with exponential backoff for hours (Stripe: up to 3 days). You need a log of failed deliveries and a way to manually reprocess what the queue lost.

These four points are the difference between an integration that works in a demo and one that works in production, at 2 AM, when the first duplicate resend happens.

Webhook vs API — when to use each

They're not competitors; they complement each other. The practical rule:

In practice, almost every complete integration uses both: the API for actions (create a payment, submit an invoice) and the webhook for reactions (payment succeeded, invoice rejected by validation).

What a webhook integration costs

Real estimates for standard operations, including signature verification, idempotency, retries, and monitoring (detailed figures by project type in our pricing guide):

The red flag in a quote: «Stripe integration in 3 hours». It might work on sandbox, but without idempotency and retries it's a time bomb set for the first resend.

How to verify, as a non-technical founder, that the integration is done well

Three questions you can ask any team delivering a webhook integration:

1. «Do you verify the webhook signature?» The correct answer is «yes, with the secret from the dashboard, on every request». «No need» means the endpoint accepts forged notifications.
2. «What happens if the same webhook arrives twice?» The correct answer describes storing the event ID. «That can't happen» is false — resending is documented behavior at every major provider.
3. «Where do I see failed deliveries?» The correct answer shows a log or dashboard (yours or the provider's). If there's no answer, there's also no way to know you're losing orders.

Frequently asked questions

Can a webhook simply never arrive?

Yes. If your server is down or responds with an error, the provider retries for a limited window (Stripe: up to 3 days), then gives up. That's why a delivery log and a manual reprocessing path are mandatory, not optional.

Why is a webhook cheaper than polling if I still build an endpoint?

The endpoint is built once. Polling consumes server and database on every interval, forever, plus a permanent X-minute delay. At high volume the operating-cost gap is significant, and the reaction-time gap (seconds vs minutes) is directly visible in how the store runs.

Can I receive webhooks without my own server?

Intermediary services can receive webhooks and forward them (email, queue, another API). Useful for prototypes or simple notifications. For real processing — invoices, stock, payments — the endpoint must belong to the application executing those actions.

Keep reading

• What Is a REST API — Explained Without Jargon
• Services: API Integrations
• How Much Does a Custom Web App Cost in 2026