What Are Webhooks and How Do They Work?

In today's highly connected online world, nothing can function optimally in isolation. Achieving a task (almost) always involves the participation of more than one entity. E-commerce apps need to communicate with payment systems; payment systems need to communicate with banking systems, and banking systems need to communicate with customer accounts–do you see the pattern?

The interoperability of independent online systems—their ability to communicate with one another and share data in real-time—is at the core of what makes online services valuable today. In this post, we will look at webhooks, one of the most common ways to facilitate communication between online services. By the end of this article, you will fully understand what they are, how they work, and when to use them.

What is a webhook?

A webhook is an HTTP request triggered by an event in a source system and sent to a destination system, often with a payload of data. They are automated; in other words, they are automatically sent out when their event is fired in the source system.

It provides a way for one system (the source) to send data via an HTTP request to another system (the destination) when an event occurs and share information (request payload) about the event that occurred.

What is a webhook used for?

Webhooks are used to communicate the occurrence of an event in one system to another system and they often share data about the event. Let's look at a concrete example.

Let's say you subscribe to a streaming service. The service wants to email you when it charges your credit card.

The streaming service can subscribe to the banking service (the source) to send an HTTP request (webhook) when a credit card is charged (event trigger) to their emailing service (the destination). When the event is processed, it will notify you each time your card is charged.

The banking system webhooks will include information about the charge (event data), which the emailing service uses to construct a suitable message for you, the customer.

They are often an entry point for developers building event-driven applications and event-driven architectures (EDAs).

Common webhook use cases

Webhooks are used across almost every category of online service. Here are some of the most common patterns:

Payments and billing — Payment processors like Stripe and PayPal send webhooks when charges succeed, fail, or are refunded. Subscription platforms send them when a plan is upgraded, cancelled, or enters a dunning cycle. These events typically trigger downstream actions like provisioning access, sending receipts, or updating billing records.

E-commerce and inventory — Platforms like Shopify send webhooks for new orders, inventory changes, and fulfillment updates. These events feed into warehouse systems, shipping providers, and accounting tools that need to react to order activity in real time.

Developer tools and CI/CD — GitHub sends webhooks when code is pushed, pull requests are opened, or issues are created. CI/CD pipelines rely on these events to trigger builds, run tests, and deploy code automatically.

Communication and messaging — Services like Twilio and SendGrid use webhooks to notify your application when messages are delivered, opened, or bounced. Chat platforms like Slack send webhooks for new messages, reactions, and channel events.

CRM and marketing — Platforms like HubSpot send webhooks when contacts are created, deals move stages, or forms are submitted. These events power automated workflows like lead routing, nurture sequences, and data synchronisation across tools.

Infrastructure and monitoring — Cloud platforms and monitoring tools send webhooks for deployment events, alerts, incident updates, and resource changes. These events feed into on-call systems, dashboards, and automated remediation workflows.

In each of these cases, the pattern is the same: an event occurs in one system, and a webhook delivers data about that event to another system in real time. The difference is in what happens next — and that's where handling webhooks reliably becomes important.

Webhook vs. API

Webhooks and APIs both enable communication between systems, but they work in opposite directions.

An API is request-based. Your application sends an HTTP request to another system's endpoint and receives a response. You decide when to ask, and you have to keep asking if you want to stay up to date. This is often called polling — your system checks for new data at regular intervals, whether anything has changed or not.

A webhook is event-based. The other system sends an HTTP request to your endpoint as soon as something happens. You don't ask — you get told. This is why webhooks are sometimes called reverse APIs or push APIs: the server pushes data to the client, rather than the client pulling it.

The key difference is who initiates the communication:

• API (pull): Your system asks "has anything changed?" on a schedule. Simple to implement, but wastes resources when nothing has changed and introduces delay between checks.
• Webhook (push): The source system tells you "something just changed" the moment it happens. More efficient and real-time, but requires your system to be ready to receive requests at any time.

In practice, most integrations use both. In our streaming service example, the streaming service would use the banking service's API to create a new subscription, and receive a webhook each month when the subscription is charged. The API handles actions you initiate; the webhook handles events you need to react to.

For a deeper comparison, see our guide on when to use webhooks.

How do webhooks work

For a system to send webhooks, the system has to be able to support making outbound HTTP requests in response to an event within a system, and you can build your system to send webhooks by triggering HTTP requests for different types of events.

They are most common in SaaS and PaaS platforms like GitHub, Shopify, Stripe, Twilio because they support different types of events based on the activities that happen within them.

To receive webhook requests, you must register for all or specific events (also known as topics) that the platform offers. Those events are represent triggers for the events such as charge.created or user.created to name a few examples.

Some platforms require a handshake or challenge to complete before the registration is successful. It's a mandatory process to verified that the URL is valid and wishes to receive requests from the source system.

Once you register for an event, you will receive requests at the destination URL you provided each time the event occurs.

Consuming a webhook

Webhooks are regular HTTP requests and should be handled as such. The HTTP endpoint must support the HTTP method used by the provider and the request's content type. Payloads most commonly use a JSON, form-encoded, or XML content type, which most HTTP servers support.

They are most commonly sent using the HTTP POST method. However, this is dependent on the provider. GET requests have their payload appended to the URL as a query string. POST and PUT requests have their payload in the request body and might contain properties like authentication tokens.

There are several things to consider to consume webhooks successfully and avoid integrity issues

Delivery guarantees & idempotency

Webhooks typically have "at-least-once" delivery guarantees, which means receiving the same request more than once is possible. You should make your processing idempotent.

Timeouts

Webhook requests have a timeout for how long they wait for a response from your server. The timeout is typically short, at most 5 seconds and sometimes as low as 1 second. It is best practice to return an HTTP status code of 200 to confirm that you have received it.

Throughput control

Webhooks sent by providers are not throughput controlled, and chances are you will eventually receive more requests than you can handle. To not lose any data, you should persist the data immediately, generally using a message queue and process the event asynchronously.

Asynchronous processing

Because of the short timeout and lack of throughput control, webhooks should be processed asynchronously. By processing asynchronously, you can ensure that your system can respond quickly to the request and defer any long-running processing to a background job.

Ordering

Webhooks are not guaranteed to be delivered in order and typically include a timestamp in the payload or headers. That timestamp can be used to determine if an event is out of order or "stale" to avoid processing it.

Security & Signature verification

Since webhooks are ultimately HTTP requests made to a "Public" URL, they are susceptible to being spoofed by malicious actors. The authenticity can be verified by validating the request's signature. Typically, the signature uses HMAC algorithms with a shared secret key to hash the body of the request. The signature must be computed and compared to the signature in the request for every request. If the signature does not match, the request should be rejected.

Follow our webhook security guide to learn more about how to secure your application.

Next steps

Now that you understand webhooks, you might be wondering about the practical challenges of implementing them in production. As you've seen, webhooks require careful handling of timeouts, retries, security, and asynchronous processing.

Continue learning with our guides

Hookdeck has comprehensive guides to help you master webhook implementation:

• Receive your first webhook - Get started in minutes.
• Production best practices - Scale reliably.
• Webhook security guide - Protect your systems.

See webhooks in action using Hookdeck

If you're ready to implement webhooks, Hookdeck provides the infrastructure to handle the complexity—starting with testing all the way to production. Try it free to see how an event gateway simplifies webhook management.