Webhook

A webhook turns the usual API relationship around. With an API, your system asks another service for information whenever it wants it. With a webhook, the other service tells your system as soon as an event happens, so nobody has to keep checking. Developers sometimes call it a reverse API or a push notification between servers.

A webhook is not a feature you see on a page. It is a background connection between two systems, set up once in the sending service's settings, that then runs every time the chosen event occurs. If either end changes, it can stop working without anyone noticing.

How it works

You give the sending service a web address on your system, called the endpoint, and choose which events you care about. When one of those events happens, the service sends an HTTP request to that address containing the details, usually as JSON: which order, which customer, what amount, what time.

Your endpoint receives the message, checks that it is genuine and acts on it, for example by marking an order as paid, sending a confirmation email or updating a spreadsheet. It then replies with a success code so the sender knows it arrived. Most providers sign each message with a secret that only you and they know, and your endpoint should reject anything without a valid signature, because the address itself is not secret.

If your endpoint does not answer, or answers with an error, many providers try again several times over the following hours, and some eventually disable a webhook that keeps failing. Because of these retries, the same event can arrive twice, so a well-built endpoint checks whether it has already handled a message before acting on it again.

Example

A yoga studio takes class payments through an online payment provider. When a payment succeeds, the provider sends a webhook to the studio's booking system, which marks the place as paid and emails the member their confirmation. When a refund is issued, a second webhook frees the place for someone else.

One weekend the booking system is offline for maintenance. The payment provider's webhooks fail, but the provider retries them, and when the system comes back the missed payments arrive and are processed in order. Because the endpoint ignores events it has already seen, a payment that arrives twice does not book two places. The studio's only manual step is checking the provider's delivery log after the maintenance window to confirm nothing is still failing.

Why it matters for your business

Webhooks are what make automation feel instant: an order paid at midnight is confirmed at midnight, not when someone opens the dashboard in the morning. They save staff time and reduce mistakes that come from copying data between tools. The risk is silence. A webhook that breaks after a settings change or an expired address simply stops delivering, so someone should check the sending service's delivery log now and then, and important flows should raise an alert when deliveries fail. Keep a short note of which webhooks exist and where they point, because that list is exactly what is needed during a site migration.

Common mistakes

• Accepting webhook messages without checking their signature, so anyone who finds the address can send fake events.
• Doing slow work before replying, so the sender times out and keeps retrying the same event.
• Processing a retried event twice and sending duplicate emails or double-counting payments.
• Changing a site's address during a migration and forgetting to update the webhook endpoints in every connected service.

Questions people ask

What is the difference between a webhook and an API?

With an API, your system asks another service for data when it wants it. With a webhook, the other service sends data to your system automatically when an event happens. Many integrations use both: webhooks to hear about changes and API calls to fetch fuller details.

Are webhooks secure?

They can be. The secure pattern is an HTTPS endpoint that checks a signature on every message using a secret shared with the sender, and ignores anything that fails. Without that check, anyone who discovers the endpoint address could send fake events to your system.

How do I know if a webhook stopped working?

Most services that send webhooks keep a delivery log in their settings, showing each attempt, the response and any errors. Check it when something seems missing, and ask your developer to set up an alert so repeated failures are reported rather than discovered weeks later.