Webhooks explained for business owners (no coding needed)

Short answer: A webhook is an automatic message one system sends to another the moment something happens, such as "payment succeeded" or "new order placed". It replaces polling, where your system keeps asking "anything new yet?". Webhooks make automations fast, but they can arrive twice, out of order, or not at all, so a well-built integration checks each message is genuine, ignores duplicates and has a back-up way to catch anything it missed.

You'll usually meet the word when a developer says "we'll use a webhook from Stripe" or an app's setup page asks for a "webhook URL". You don't need to build one to make good decisions about it.

The idea, with two analogies

Polling is checking the letterbox. Every 15 minutes you walk to the gate to see whether anything has arrived. Most trips, nothing has. When something arrives just after you looked, it sits there until your next trip.

A webhook is a courier who knocks. You give the courier your address once. When there's a delivery, they bring it to the door and wait for you to sign. No wasted trips and no delay.

In technical terms, the "address" is a URL on your website or app (the endpoint), the "delivery" is a small bundle of data about the event, and the "signature" is your system replying "got it" with a success code. Shopify's developer docs describe webhooks the same way: a way to keep an app in sync, and a "performant alternative to continuously polling" a shop's data.

Everyday examples

Tools such as Zapier and Make often hide the webhook behind an "instant" trigger. If you've built one of those, you've already used webhooks.

What makes webhooks reliable (or not)

This is the part worth understanding, because it's where cheap integrations cut corners.

Is the message genuine?

Anyone who knows your webhook URL could send fake data to it, such as a fake "payment succeeded". Good providers sign each message. Stripe sends a signature header that your endpoint checks with a secret key; Shopify includes an HMAC signature generated from your app's secret and the message body, and says to verify it before trusting the contents. Your developer should be checking these.

What if your website is down?

Providers retry. Stripe's docs say it attempts delivery for up to three days in live mode, with growing gaps between attempts. Retries are helpful, but they mean your system may receive an event late.

What if the same message arrives twice?

It happens. Stripe notes that endpoints might occasionally receive the same event more than once and suggests logging event IDs you've processed. Shopify includes a delivery ID for the same reason. Without that check, a customer might get two confirmation emails, or stock might drop twice.

What if they arrive in the wrong order?

Stripe says it doesn't guarantee events arrive in the order they were created. Shopify suggests using timestamps to put them in order. A well-built handler doesn't assume "created" always comes before "updated".

What if one never arrives?

Shopify's docs are blunt: delivery "isn't always guaranteed", so apps should run reconciliation jobs that periodically fetch data to catch anything missed. Think of it as a nightly check that the shop and the warehouse agree on today's orders.

Is the reply quick?

Stripe advises returning a success response quickly, before doing slow work like updating your accounts system. If your endpoint takes too long, the provider may treat the delivery as failed and retry.

Questions to ask your developer or app vendor

You don't need to read the code. These questions tell you whether the integration was built carefully:

1. Which events do we listen to, and why those? Fewer, well-chosen events are easier to support.
2. Do we verify the signature on every webhook? The answer should be a plain yes.
3. How do we handle duplicates? Look for "we store the event or delivery ID and skip repeats".
4. What happens if our site is down for an hour? Expect "the provider retries and we process them when we're back", plus how you'd know it happened.
5. Is there a reconciliation job? For anything involving money or stock, there should be.
6. Where do failed webhooks show up, and who gets alerted? Most providers have a delivery log; someone should be watching it.
7. What happens when we change the URL or move hosting? Moving a website can silently break webhooks if the endpoint address changes.
8. Which secret keys are involved, and where are they stored? Not in an email, a shared document or the website's public code.

FAQ

Is a webhook the same as an API?

Not quite. An API is a door you knock on to ask for or change data. A webhook is the other system knocking on your door to tell you something happened. Most integrations use both: the webhook says "order 1042 was paid", and the API call fetches the order's full details.

Do I need a website to receive webhooks?

You need an address on the internet that can receive them. That could be your website, your app's server, or an automation tool that gives you a webhook URL.

Why did my automation stop when we moved hosting?

The webhook was probably still pointing at the old address, or the new server isn't accepting the requests. Check the provider's webhook settings and its delivery log for errors.

Are webhooks secure?

They can be, if the receiver uses HTTPS, verifies signatures and keeps the secret keys private.

If a payment, booking or order system needs to talk to the rest of your business reliably, tell us which two systems should be connected.

Sources

• https://docs.stripe.com/webhooks
• https://shopify.dev/docs/apps/build/webhooks
• https://shopify.dev/docs/apps/build/webhooks/subscribe/https