# What Is a Webhook? A Practical Guide

Source: https://dijituldevelopments.co.uk/guides/what-is-a-webhook/
Updated: 2026-10-10

> A webhook is an automatic message one system sends to another the moment something happens, such as Stripe telling your website a payment succeeded or Shopify announcing a new order. dijitul builds secure, reliable webhook handlers and integrations for UK businesses, with a fixed-price quote after a free chat.

## Key facts

- A webhook is an HTTP POST sent to your URL when an event happens
- It replaces polling: no need to ask "anything new?" every minute
- Stripe, Shopify, Xero, GitHub and Microsoft Graph all send webhooks
- Every webhook should have its signature verified before it is trusted
- Providers retry failed deliveries, so handlers must ignore duplicates
- Respond quickly and do the heavy work in a background queue

## Webhooks in plain English

With a normal API call, your system asks another system for information. With a webhook, the other system tells you, automatically, as soon as something happens. You give the provider a URL on your server, choose the events you care about, and they send an HTTP POST with a JSON description of each event.

The difference matters. Checking for new orders every five minutes (polling) wastes calls, hits rate limits and is always slightly out of date. A webhook arrives within seconds and only when there is something to say.

## Real examples

- **Stripe** sends `payment_intent.succeeded` when a card payment completes, and `invoice.paid` or `customer.subscription.deleted` for subscriptions. Your system marks the order paid or ends access.
- **Shopify** sends `orders/create`, `orders/paid` and `refunds/create`, which can trigger stock updates in a warehouse system or postings to accounts.
- **Xero** sends webhooks when contacts or invoices change, so your website can show an invoice as paid.
- **Microsoft Graph** change notifications tell your app when an Outlook calendar event or a SharePoint file changes.
- Your own system can *send* webhooks, letting customers' systems react to your events.

## Receiving webhooks securely

A webhook URL is public, so anyone could post fake data to it. Always verify that a message is genuine:

- **Stripe** signs each event; check the `Stripe-Signature` header with your endpoint secret, ideally using Stripe's official library.
- **Shopify** sends an `X-Shopify-Hmac-Sha256` header, an HMAC of the raw body with your app secret.
- **Xero** signs payloads with an `x-xero-signature` header and checks your endpoint with an "intent to receive" test before activating it.

Verify against the raw request body before any parsing, use a constant-time comparison, and reject anything that fails. Only accept HTTPS. For extra safety, use the event ID to fetch the latest data from the provider's API rather than trusting the payload alone.

## Receiving webhooks reliably

- **Respond fast.** Return a 2xx status within a few seconds, then process the event in a background queue (Laravel queues with Redis, or a Node.js worker). Slow responses are treated as failures.
- **Expect duplicates.** Providers retry when they do not get a success response; Stripe, for example, keeps retrying for up to three days in live mode. Store each event ID and ignore ones you have already handled (idempotency).
- **Expect disorder.** Events can arrive out of sequence. Check timestamps or fetch current state.
- **Log everything** and alert someone when processing fails repeatedly.
- **Have a fallback.** A scheduled reconciliation job catches anything missed during an outage.

## Testing and debugging webhooks

Webhooks are harder to test than ordinary pages because the request comes from outside, often only when a real event happens. Practical techniques:

- **Provider tools.** The Stripe CLI can forward events to a local development machine and trigger test events on demand. Shopify and Xero let you send test notifications from their developer dashboards.
- **Test mode first.** Stripe's test mode and test cards let you create real-looking events without moving money.
- **Record raw payloads.** Store the raw body and headers of incoming events (with sensitive data protected) so you can replay them during debugging.
- **Delivery dashboards.** Providers show delivery attempts and response codes. If they report timeouts or 500 errors, your endpoint is the problem.
- **Replay safely.** Because your handler is idempotent, you can replay an event to fix a failed process without fear of duplicates.
- **Watch for signature failures.** A sudden rise usually means a rotated secret, a proxy changing the body, or a framework parsing JSON before verification.

When you send webhooks from your own system, give customers the same courtesies: a signing secret per endpoint, documented event types and payloads, automatic retries with backoff, a delivery log they can see and a way to resend events. Those features save support time later.

## When to talk to dijitul

Webhooks are where many integrations quietly fail: unverified endpoints, double-processed payments, orders lost during a server restart. dijitul builds webhook handlers and Stripe integrations with signature checks, queues, idempotency and monitoring. If you have an integration that sometimes misses events, we can find out why. Start with a free chat and a fixed-price quote.

## FAQs

### What is the difference between a webhook and an API?

With an API, your system asks another system for data or to do something. With a webhook, the other system sends your system a message automatically when an event happens. Most integrations use both: webhooks for alerts, API calls to fetch details.

### Are webhooks secure?

They are when the receiver verifies each message's signature, accepts only HTTPS and treats the payload with caution. Stripe, Shopify and Xero all sign their webhooks. An endpoint that skips verification can be fed fake events by anyone who finds the URL.

### What happens if my server is down when a webhook is sent?

Most providers retry failed deliveries for a period, with increasing gaps. Stripe retries for up to three days in live mode. A good integration also runs a scheduled reconciliation to pick up anything still missed.

### Why did my system process the same payment twice?

Usually because a webhook was retried or delivered twice and the handler did not check whether it had already processed that event ID. Storing event IDs and making handlers idempotent stops duplicates.

### Can dijitul add webhooks to our own software?

Yes. dijitul can add outgoing webhooks so your customers' systems receive events from yours, with signing secrets, retries, delivery logs and a test tool. It starts with a free chat and a fixed-price quote.

## Pricing and contact

Every project gets a fixed-price quote after a free initial chat and a short scoping stage. You own the code and the data. Book a free chat: https://dijituldevelopments.co.uk/contact/ · 01623 650333 · info@dijitul.uk