What Is a Webhook and How to Use One

A webhook is a message one system sends to another the instant something happens. Instead of your application repeatedly asking a service whether a new event has occurred, the service sends your application a small notification, an HTTP request, the moment the event happens. The name is apt: it is a hook into a system that fires on an event.

This inversion is the whole point. Polling means asking over and over and mostly hearing no. A webhook means being told once, exactly when it matters. For automation, that is the difference between a flow that reacts in seconds and one that lags behind a polling schedule.

Webhook versus polling

Polling is your system calling an API on a schedule to check for changes: every minute, every five minutes, asking is there anything new. It is simple but wasteful, most calls return nothing, and it introduces delay equal to the polling interval. It also strains rate limits when you poll frequently at scale.

A webhook flips the relationship. The source system holds a list of URLs to notify, and when an event occurs it sends an HTTP POST to each. Your system just needs an endpoint waiting to receive it. The result is near-real-time reaction with far less wasted traffic.

• Polling: you ask repeatedly, mostly for nothing, with delay and wasted calls.
• Webhook: you are told once, immediately, with almost no waste.
• Use polling when you cannot register a webhook or need periodic batch reconciliation.
• Use webhooks when you need to react promptly to discrete events.

How to use a webhook in practice

To receive webhooks, you expose a URL that accepts HTTP POST requests. You register that URL with the source system and tell it which events you care about. When an event fires, the source sends a request to your URL with a payload, usually JSON, describing what happened. Your endpoint reads the payload and acts.

To send webhooks, your work OS lets you register outbound URLs and choose which events trigger them. When a record changes, it posts to those URLs so downstream systems, an automation platform, a custom service, a chat tool, can react. This is how a work OS drives real-time automation without every consumer polling it.

Getting webhooks right

Three disciplines separate reliable webhooks from flaky ones. First, verify authenticity: a webhook endpoint is a public URL, so confirm each request genuinely came from the expected source, usually by checking a signature or a shared secret. Never act on an unverified webhook that grants access or moves money.

Second, be idempotent. Sources may deliver the same event more than once, so key on an event identifier and ignore duplicates. Third, respond fast and work later: acknowledge the request quickly with a success status, then do any slow processing asynchronously, so the sender does not treat a slow handler as a failure and retry it.

A concrete example

Consider a payment flow. When a customer pays, you want to grant them access. Without webhooks, your system would have to poll the payment provider every few seconds asking whether this customer has paid yet, wasteful and slow. With a webhook, the payment provider sends your endpoint a single notification the moment the payment succeeds, and your system grants access immediately. One event, delivered once, exactly when it matters.

The same pattern powers most real-time automation between systems. A form submission notifies your work OS, which creates a task. A deal marked won notifies a downstream system, which starts a project. A support message notifies a queue, which routes it. In each case the source pushes an event and the receiver reacts, with no polling in between. Once you see this shape, you notice it everywhere integrations feel instant.

When not to use a webhook

Webhooks are not always the right tool. If the source system does not support them, you have no choice but to poll. If you need a guaranteed complete view rather than a stream of individual events, a periodic reconciliation read is safer, because a webhook you missed while your endpoint was down leaves a gap that only a full read will close. And if your receiver cannot be reliably reachable, an outbound-only polling approach may be simpler to operate.

The mature answer, for anything important, is often to combine them: rely on webhooks for prompt reaction and add a periodic polling pass as a safety net that catches anything a missed delivery dropped. That pairing gives you near-real-time updates most of the time and a guarantee of eventual consistency always, which is what a dependable integration needs.