What Is a Webhook and How Does It Work?

Short answer

A webhook is a notification method that automatically sends information to another server the moment a specific event happens inside a system. The receiving system doesn’t poll for data; the sender pushes it over an HTTP request as soon as the event occurs.

A confirmed payment in an online store, a new contact in a CRM, or a code push on GitHub all reach another piece of software without delay because of a webhook.

What is a webhook and how does it work?

The term webhook comes from combining “web” and “hook,” and it describes an HTTP-based mechanism that lets one piece of software automatically notify another system about a specific event. The sender posts a JSON payload to a pre-registered URL (the endpoint) the moment the event fires; that payload typically carries the event type, a timestamp, and the ID of the relevant record. When the receiving server gets the request, it runs its own business logic: creating a database entry, triggering an email, or passing data along to yet another system.

Setting one up requires registration on both sides. The team using the webhook first builds an endpoint on the receiving system, then registers that address in the sending platform’s settings and specifies which events should trigger it. When a payment completes in Stripe, a pull request merges on GitHub, or an order’s status changes on an ecommerce platform, every registered endpoint gets an automatic request.

How is a webhook different from an API?

Webhooks and APIs get confused constantly, yet the direction of the data flow is fundamentally different between them. In a classic API call, the client requests the data; staying current means polling at regular intervals, which introduces delay by design. With a webhook, that direction flips: the sender pushes the data itself the instant the event happens, and the receiver gets notified without ever asking.

This difference has a direct effect on server resources too. An integration that asks “has anything changed?” dozens of times a minute wears down both sides’ servers for nothing, while a webhook only fires when a real event actually occurs. For scenarios that need real-time notification, a webhook is usually the more efficient choice compared to an API.

What steps does a webhook request go through?

A webhook request’s lifecycle breaks down into a few clear steps. First, an endpoint is built on the receiving system, coded to handle incoming requests properly. Next, that URL gets registered in the sending platform’s settings panel, along with the specific events that should trigger it, something like “order.completed” or “user.signed_up.”

When the event happens, the sending system typically builds an HTTP POST request in JSON format and delivers it to the registered address. The receiving server checks authentication first, processes the payload, and finally returns a 200 status code confirming the request was received successfully. If that response doesn’t come back, the sender usually retries the delivery at set intervals.

Webhook security: why signature verification and HTTPS matter

A webhook endpoint is, by definition, a public URL, and that creates a real security risk: anyone who discovers the address can send a forged request and inject false data into the system. To reduce that risk, most sending platforms attach a digital signature generated with a shared secret key to every request; the receiving server recalculates that signature independently and compares it, confirming the request genuinely came from the expected source.

The secret key used for signature verification should never be hardcoded into the source; it belongs in a secrets manager or an environment variable, and leaking it into a repository by mistake carries the same urgency as the scenario covered in our guide on leaking an API key on GitHub. Using HTTPS matters just as much, since a payload sent over an unencrypted connection can be read or altered by anyone intercepting the traffic. Skip either safeguard, and a webhook turns into an easy attack surface.

What business processes rely on webhooks?

Payment systems are one of the most common places webhooks show up: providers such as Stripe, PayPal, or a local gateway send an instant notification to the store’s server the moment a payment is confirmed or refunded, so the order status updates on the customer’s screen within seconds. In ecommerce, webhooks that fire when a tracking number is generated or stock drops below a threshold are one of the core building blocks of the ERP synchronization work covered in our API integration guide.

CRM systems lean on webhooks just as heavily: when a form gets submitted, a deal stage changes, or a customer cancels a subscription, that information can reach the sales team’s dashboard or a Slack channel instantly. Marketing automation tools use webhooks triggered by an email open or a link click to update segmentation decisions in real time.

What happens when a webhook request fails?

A webhook request doesn’t always succeed on the first attempt: the receiving server might be down for maintenance, the network connection might drop, or the server might return an unexpected error. Most providers plan for exactly this and retry a failed request several times at increasing intervals, say a few seconds, then minutes, then hours; this pattern is called exponential backoff.

Once every retry is exhausted, the request is usually marked failed, and some systems move it into a separate dead letter queue. Teams running a serious webhook integration in production should build a dashboard that tracks failed requests and an alert that notifies the team when that happens, since an outage that goes unnoticed for days can quietly grow into a mismatch in accounting or inventory data.

Webhook or polling?

Not every integration is a good fit for a webhook. If the receiving system doesn’t have a public server ready to accept one, or the other side simply doesn’t support webhooks, polling remains the only option: the receiver asks “is there anything new?” at set intervals, and some delay becomes unavoidable.

For processes that need real-time notification, change frequently, and expect an immediate response, a webhook is almost always the sharper choice. For a report that runs once a day or a dataset that rarely changes, a simple scheduled task may not be worth the extra maintenance a webhook setup adds.

How do tools like Zapier, Make, and n8n use webhooks?

For teams that want to build automation without writing code, platforms such as Zapier, Make, and n8n hide the webhook behind a visual interface. Adding a “webhook trigger” in one of these tools generates a URL automatically, and that address can be pasted into any other system, a custom form, a payment provider, or a mobile app, and set as its event trigger.

Once the webhook URL fires, the platform reads the incoming data and runs through the steps the user set up beforehand: sending an email, adding a row to a spreadsheet, posting a Slack message. This is a fast starting point for small teams that want to wire up complex integrations without custom code; once volume grows or custom business logic enters the picture, a direct integration built through custom software development tends to hold up better long term.

What mistakes do teams commonly make setting up webhooks?

The most common mistake is processing an incoming request without ever verifying its signature, which means anyone who finds the URL can send fake data. The second frequent mistake is letting the receiving endpoint’s response time run too long: running a heavy operation synchronously before responding delays the reply enough that the sender treats the request as failed and resends it, causing the same event to be processed more than once.

The third mistake is never accounting for the possibility that the same event gets processed twice. Network interruptions can, in theory, deliver the same webhook request twice, so every request should carry a unique identifier (an idempotency key) that gets checked, and a second request with the same key should be silently ignored.

What’s next

A webhook is one of the most practical ways to build a fast, efficient notification bridge between two systems, and that’s exactly where its real value shows up, it removes both the delay and the server load that periodic polling creates. Not skipping signature verification, keeping response times short, and blocking duplicate requests with an idempotency key are the three habits that make this simple mechanism reliable in production. GitHub’s own documentation explains in detail how webhooks fire per event and what data structure they use; for the technical reference, see GitHub’s webhook documentation.

If you want a full review of your system’s integration and automation architecture, our group company Web Tasarım Ofisi also supports this as part of custom software work. You can look into our custom software service or get in touch with us to talk through your needs.