# What is a webhook and what is it for?

> A webhook pushes an automatic notice the moment an event happens in a piece of software. How it works, a worked SME example and the security traps to avoid.

Updated on October 15, 2026 · https://app.pilotiko.com/en/glossary/webhook

A webhook is a mechanism in which a piece of software automatically sends an HTTP request carrying data to a web address you chose, as soon as a specific event occurs, such as a payment going through or a booking being created. The receiving system therefore does not need to keep checking the source system for changes.

## In short
- You subscribe to an event once; notices then arrive on their own.
- Webhooks complement APIs: they push information instead of waiting to be asked.
- Verify the signature on every message you receive.
- A good receiver answers fast and can handle the same notice twice.

## How does a webhook work?

GitHub's documentation puts it simply: webhooks let you subscribe to events in a software system and automatically receive a delivery of data on your server whenever those events occur. The point is to get data as it happens, rather than polling an [API](https://app.pilotiko.com/en/glossary/api) every so often to see whether anything changed [1].

When you create a webhook, you give it a URL and pick the events you care about. When one of them happens, the source system sends an HTTP request with the event details to that URL. The server listening there can then act: post a notice, update a record, start the next step [1].

Many modern [SaaS](https://app.pilotiko.com/en/glossary/saas) products offer webhooks. A common use is to open a [work order](https://app.pilotiko.com/en/glossary/work-order) as soon as a booking comes in, or to alert whoever prepares the [quote](https://app.pilotiko.com/en/glossary/quote).

## Which events trigger webhooks in a service business?

| Event in the source system | Data sent | Possible reaction |
|---|---|---|
| Card payment approved | Amount, customer, invoice number | Mark the invoice paid in accounting |
| Booking created on the website | Date, service, contact details | Create the technician's work order |
| Quote request form submitted | Job description, address | Alert the person preparing the quote |
| Subscription cancelled | Customer, end date | Remove the customer from upcoming routes |

Available events depend entirely on each product; check its documentation.

## What happens if the receiving server is down?

Well-built providers retry. Stripe, for example, says that in live mode it keeps trying to deliver an event for up to three days with exponential back-off, while in a sandbox it retries three times over a few hours [2].

The practical upshot: the same notice can arrive more than once. Your receiver has to recognize an event it already handled so it does not, say, create the same invoice twice.

## How many wasted calls does a webhook avoid?

**Calculation: a 3-room physiotherapy clinic in Rimouski syncing its bookings**

- Option 1: poll the API every 5 minutes, 12 hours a day : 144 calls a day
- Real new bookings per day (assumption) : 18
- Calls that find nothing new (144 − 18) : 126
- Option 2: webhook on the booking-created event : 18 notices a day
- Longest wait to see a booking with option 1 : up to 5 minutes
- **= The webhook sends only the 18 useful events, as they happen, instead of 144 checks of which 126 come back empty.**

## Which security and design mistakes are common?

- Trusting any message that reaches the webhook URL without checking its signature: anyone could post a fake payment received.
- Altering the raw body before checking the signature: Stripe warns that any change to the raw body makes verification fail [2].
- Doing all the processing before replying: with some providers, a slow answer can be counted as a failure and trigger a resend.
- Not handling duplicates, even though retries are normal.
- Wiring an [automated process](https://app.pilotiko.com/en/glossary/process-automation) that emails a customer the moment a notice lands, with no human check.

## Does Pilotiko use webhooks?

Pilotiko's capability register does not describe any customer-facing webhooks, so we do not advertise them. Our stance on outgoing actions is clear, though: in Pilotiko, anything touching a customer, money or a send waits for [a person's approval](https://app.pilotiko.com/en/glossary/human-in-the-loop), even when the trigger arrived automatically.

## Frequently asked questions

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

With an API, your program asks when it decides to. With a webhook, the source system tells you when an event happens. They often work together: the webhook flags the change, and the API is then used to read the details.

### Do I need a server to receive a webhook?

You need a reachable web address that listens for requests, whether that is your own server, a hosted function or an automation tool. Use HTTPS so the data is protected in transit.

### Are webhooks instant?

They fire when the event happens, but the real delay depends on the provider and the network. If your receiver is down, the notice may arrive much later after retries.

### How do I know a webhook really came from the right system?

Most providers sign each message with a secret only you know. Your receiver recomputes the signature and rejects anything that does not match.

### Are webhooks practical for a small business?

Yes, especially through automation tools that provide the receiving address for you. Start with one useful event, such as a new booking, and watch the results for a few weeks.

## Sources

1. GitHub Docs, « About webhooks », https://docs.github.com/en/webhooks/about-webhooks (accessed on 2026-10-15)
2. Stripe Docs, « Receive Stripe events in your webhook endpoint », https://docs.stripe.com/webhooks (accessed on 2026-10-15)