A webhook is how software says “Hey, this event just occurred.” Instead of your system constantly asking another system for new data, the other system tells you the moment something happens.
Think about a doorbell at an office. You don’t stand at the door all day asking whether someone has arrived. The bell rings when they do, and that ring is the signal to do the next thing. A webhook works like that doorbell.
How it shows up
You see webhooks in everyday software even if you never call them that. A payment succeeds in Stripe and your system gets notified. A form is submitted and a CRM receives the lead. The event itself rings the bell, so no human had to remember to check. This is the opposite of cron and scheduling, which is like checking the front door every fifteen minutes on a fixed schedule. Webhooks are also where automation chains often start: event happens, webhook fires, another system updates a record or asks an agent to review something. For agentic work, a client uploading a file can wake up a process at the right moment instead of an agent polling for it.
Why you care
Webhooks make systems more responsive and less wasteful. They cut the need for polling and “did anything happen yet?” loops. The doorbell has a second lesson, though: if the bell rings and nobody is assigned to answer it, nothing useful happens. A webhook needs a receiver, a rule for what to do next, and enough error handling that missed signals don’t become silent failures.