Glossary
Webhook
A webhook is an automatic message one piece of software sends to a web address you nominate the moment a specific event happens, so the receiving system can react immediately instead of checking repeatedly for changes.
In plain terms
There are two ways to find out whether the post has arrived. You can walk to the door every ten minutes and look, or you can have the postman ring the bell. A webhook is the bell. You give one system an address and tell it which events matter, and it calls you when they happen rather than making you keep asking.
Why it matters
Almost every automation you set up between two tools rests on this. Something has to notice that a form was submitted, an invoice was paid or a ticket was raised, and start the next step. Doing that by asking repeatedly is slow, wasteful and runs into limits on how often you may ask. A webhook makes the reaction immediate and the cost proportionate to how often the thing actually happens. When people say a workflow triggers on something, this is usually the mechanism underneath.
How it works
You register a web address with the system that has the news, and say which events you want to hear about. When one occurs, that system sends a small message to your address describing what happened: which record, what changed, and when. Your side receives it and does whatever it was going to do.
The message travels the same way an ordinary web request does, which is why nothing special has to be installed at either end. What matters is that your address is reachable and answers quickly. Receivers are expected to acknowledge immediately and do the real work afterwards, because a sender waiting on a slow reply will usually give up and try again later.
Because anyone who learns the address could send to it, the sender normally signs each message with a shared secret so the receiver can confirm it is genuine. Retries are the other half of the design: if your side is down, most senders try again for a while, which means the same event can legitimately arrive twice and the receiver has to notice it has already handled it.
A worked example. A form on your site is submitted. The form tool sends a webhook to an automation platform carrying the submitted fields. The platform acknowledges it, then runs its steps: create a record in the CRM, ask an assistant to draft a reply, hold the draft for someone to approve, and post a note into a team channel. Nothing polled anything, and the whole sequence started within a second of the visitor pressing send.
What actually arrives, and which parts matter
Seen in the wild
Connect two tools on an automation platform so a flow starts on an event in the first one rather than on a timer, which is the trigger half of every trigger-and-action workflow.
ZapierRun the receiving end on your own infrastructure, where an incoming event starts a workflow and the data never passes through anyone else's servers.
n8nHave a CRM notify another system as records change, using the API and webhooks its developer platform exposes.
Attio
Common misconceptions
People assume
A webhook is a kind of API.
In fact
They point in opposite directions. With an API, you call the other system when you want something. With a webhook, the other system calls you when something happens. Most integrations use both: a webhook to learn that something changed, then an API call to fetch the detail.
People assume
If the receiving end is down, the event is lost.
In fact
Usually not immediately. Most senders retry for a period, spacing the attempts out. That is a safety net rather than a guarantee: retries eventually stop, and the same event arriving twice is the normal cost of them, so a receiver that cannot tolerate duplicates will create them.
Questions
- What is the difference between a webhook and an API?
- Direction and timing. An API waits for you to ask, so you control when the exchange happens. A webhook fires on its own when an event occurs, so the other system controls the timing. They are complements rather than alternatives, and a typical integration is a webhook telling you something changed followed by an API call fetching the detail.
- Why do webhooks need a secret?
- Because the receiving address is reachable by anyone who discovers it, and nothing about an incoming message proves who sent it. The sender signs each message with a shared secret, and the receiver checks the signature before acting. Without that check, a system could be driven by messages that never came from the service it trusts.
- Can the same webhook arrive twice?
- Yes, and it should be expected. Retries after a failed or slow response are standard, and a response that was slow rather than genuinely failed produces a duplicate. Receivers handle this by recording the event identifier and ignoring anything already processed, which keeps one payment from being recorded twice.
- Do I need to be a developer to use webhooks?
- Not usually. Automation platforms expose the mechanism as a trigger you select from a list, generate the address for you, and handle acknowledgement, retries and signature checking in the background. You meet the raw form only when connecting something the platform does not already support.
Key takeaways
- A webhook is an automatic message sent the moment an event happens, to an address you nominate.
- It replaces asking repeatedly, which is slower, wasteful and limited in how often it is allowed.
- It points the opposite way to an API: the other system calls you rather than you calling it.
- Signatures prove the message is genuine, and retries mean the same event can arrive twice.
- Most people meet it as a trigger in an automation platform rather than as something to build.
Last checked July 2026