In one sentence
A webhook is a message one system sends to another to say that something has just happened.
The simple model
An API is usually about asking: your workflow requests information when it wants it. A webhook is the reverse. Instead of your workflow constantly asking "has anything happened yet?", the other system tells you the moment it does.
When a payment clears, a form is submitted or an order ships, the source system sends a small message to a web address you provide. That message is the webhook, and it can start your workflow automatically.
Why you care
Webhooks are a common way to create a reliable trigger. They let a workflow react to real events immediately, without someone checking a system or a schedule polling for changes.
For example, "when a customer submits the returns form, start the returns workflow" is naturally a webhook: the form system notifies your workflow the instant a form arrives, carrying the form's data with it.
When a webhook fits
- You want to react to an event as it happens, not on a schedule.
- The source system can send notifications (many modern tools can).
- Missing an event would matter, so you want to be told rather than have to ask.
If the source system cannot send webhooks, the alternative is to check it on a schedule, which is simpler but slower and can miss rapid changes.
A small example
A workshop wanted repair jobs to appear automatically when a customer booked online. The booking tool sent a webhook on each new booking, which created the job in the workshop's queue instantly. No one had to watch the booking site.
What this does not solve
A webhook tells you an event happened; it does not guarantee the data is complete or correct, and a single missed or duplicated message can cause problems if not handled. Treat the incoming event as input to validate, not as automatically trustworthy.
