What Is a Webhook? A Plain-English Guide With Examples
Webhooks might sound like something Spiderman uses to defeat the Green Goblin, but it’s actually a fundamental part of how lots of web apps interact. A webhook is an automated message one application sends to another, in response to a specific event. It’s used to bridge the gap between apps, pushing data to a destination URL. If you’ve ever used a Slack integration, set up a recipe in IFTTT, or managed workflows in Unito, you’ve used webhooks.
In this post, we’ll break down what they are, why they’re used, and how apps put them to work.
What is a webhook?
A webhook is essentially an automatic message being sent from one piece of software to another.
When you enter a search query into Google, you’re “contacting” the service — Google’s software. You’re the one taking action. Webhooks flip that one-way relationship on its head. They make the software contact you.
So it’s more like receiving a calendar reminder from Facebook when it’s a friend’s birthday. But webhooks can be applied to a vast array of software functions and actions. At their core, webhooks send bits of data from one app to another through an HTTP request — a quick communication across the internet.
How a webhook works
Webhooks typically follow the same three-step process across all apps:
- An event occurs in a source app.
- The source app sends an HTTP POST request to the destination’s webhook URL. The request includes a payload with data about the original event.
- The destination app receives the payload and acts on it.
Here’s what that looks like in practice, using Stripe as an example. Using a webhook, an integration between Stripe and your app sends a receipt to a customer each time a transaction is made in Stripe. Here’s that same three-step process with this example in mind:
- A customer makes a successful payment through Stripe.
- Stripe sends a message to your app that a payment was made.
- When the message is received, your app emails a receipt to the customer.
Webhooks work essentially the same way across all apps, but a webhook request could include significantly more data.
Webhooks vs APIs
| Webhook | API | |
| Direction | Push – data is sent from the source app when ready | Pull – destination requests data |
| Trigger | An event occurring | A request being made |
| Communication | One-way notification | Two-way request/response |
| Typical use | Real-time notifications, event-driven automation | Querying, creating, updating, deleting data |
| Resource cost | Low — no polling required | Higher — polling wastes requests between events |
Looking at the definition above, you might think that it sounds very similar to how APIs work. In fact, an API (application programming interface) is usually used in the creation of webhooks, but they are different entities.
A tool’s API exposes the protocol and functions that allow other tools to retrieve data from it. So, when someone wants to build an integration between two apps, they’re typically using the API to make that happen.
Now webhooks can be seen as a small part of the API focused on automatic actions. It’s like a little message that tells that specific piece of software to react when something happens.
Let’s use GitHub as an example. GitHub provides an API which lets you query for issues and pull requests. But it also lets you query and create webhooks. So developers can go in and build one that says “When an issue is updated, let me know at this internal url,” and GitHub will do so automatically. This saves other tools from having to go periodically “fetch” that information.
5 Webhook examples
Here are more examples showing how webhooks work in practice.
Payments
We already mentioned one Stripe example above, but let’s look at another. Say a significant volume of small transactions comes through, and Stripe identifies them as suspicious. A webhook might send a notification about these suspicious transactions to a cybersecurity platform, alerting your IT team.
Software development
Imagine a software development team that uses Jira to manage their work and GitHub to actually hold the code for that work. A webhook from Jira might trigger when specific issues are closed, pushing notifications to GitHub that signal work can begin on a specific build.
Messaging
Notifications from chat apps are some of the most common examples of webhooks. Apps like Slack integrate natively with project management apps, software development tools, and more, using webhooks to send notifications back and forth.
E-commerce
E-commerce tools like Shopify use webhooks across a wide range of actions. For example, a webhook in Shopify might trigger when a new customer account is registered, starting a welcome email sequence in a tool like Mailchimp.
CRM
A CRM like HubSpot centralizes data from all across the customer journey, from incoming leads to successful deals. A webhook in HubSpot might trigger when a deal is closed as won, sending a notification to a project management tool where another team starts delivering on the promises made in that deal.
Advantages of using webhooks
There are three main advantages to using webhooks:
- Automation
- Performance
- Cost
The clear advantage is that they’re automatic. When an event occurs, the data comes to you — without you or your tool spending effort and resources to query the other app’s API. You just maintain a server able to accept the webhooks, and it receives the news when the event occurs.
With this automation comes improved performance. Because there’s no manual action or querying involved in this interaction, it can happen far faster. The second something happens and the event triggers the webhook, the piece of software receiving it jumps into action.
This increased speed is reflected in the experience of the end user, who sees their intended action happen more quickly. Imagine your company manages billing in Stripe. When someone changes or cancels plans, you want Stripe to tell you as soon as it happens. A webhook makes it almost instantaneous.
Improved performance also has a positive impact on your bottom line. Without webhooks, your software might need to pull from an API at regular intervals. That would mean that every 15 minutes, you’re using CPU or RAM which adds up quickly, especially in the cloud.
With webhooks, the other app is the one calling yours, so you share the resource load and spend a lot less money in the process.
Most of Unito’s integrations use webhooks, which make a significant difference in performance. An integration that supports webhooks can sync updates from one tool to another in real-time. Without webhooks, that same integration usually checks for changes every 15 minutes.
Securing webhooks that send data
Because webhooks involve communicating with third-party servers, it’s important to authenticate the requests they use. For some organizations, the security requirements of the contracts they sign with their clients make this extremely important. Here are a few ways that developers and the organizations they work with authenticate these requests:
- HTTPS/TLS on the endpoint URL: Webhooks typically use HTTPS URLs instead of HTTP, which encrypts data in transit, preventing it from being read if it’s intercepted.
- HMAC: This is a specific kind of message authentication code that looks for shared secrets instead of a complex public key infrastructure. It streamlines the authentication process. HMAC-SHA256 is the current standard, used by GitHub, Stripe, Shopify, Zendesk, and Meta.
- Mutual TLS authentication: This is a security method that uses a “handshake” to authenticate two parties at the same time. This handshake uses a cipher to create a security certificate the sender and receiver can use to authenticate a connection.
- Keeping a list of approved IP addresses: Whoever is receiving the webhook requests can choose to keep a registry of known sources to streamline the secure acceptance of webhooks. Note, however, that approved IP addresses (called “allowlisting”) isn’t enough on its own. It’s a supplement, best used when the destination for your data is behind a firewall or other security system.
- Using basic HTTP authentication: With this system in place, webhook requests require a username and password before being approved. An example of a platform that uses this method is DocuSign.
- Secrets: No, this doesn’t mean using a cheat code or a secret level. Instead, developers can include a specific secret or verification token in a webhook — as well as information about what type of event it is — so it can be verified.
- Timestamp/replay protection: Some platforms add a timestamp to any request made through a webhook, allowing them to reject requests that are too old. This can guard against replay attacks, where a malicious actor captures and re-sends a legitimate webhook request to pull data they shouldn’t have access to.
Webhooks can be made just as secure as many other communications apps use every day, making them efficient shortcuts for sending available data without compromising data security.
How Unito’s integrations use webhooks
To illustrate how a company might use webhooks, we can share our own story.
Unito’s workflow management platform relies quite heavily on webhooks. They allow us to provide deep and fast two-way integrations between the world’s most popular work tools. They also allow us to automate workflows across these tools, so our users can receive updates in near real time. Unito’s platform uses webhooks to automate data transfer between integrated tools, enhancing efficiency and productivity. For instance, in an integration for Google Sheets and an app like Jira, Unito can automate data synchronization between spreadsheet rows and Jira issues, as well as automatically creating new work items in one tool as you create them manually in another.
When the Unito team starts building new integrations, we start by diving into a tool’s API.
First, we figure out the tool’s APIs to create webhooks (example: Teamwork, ClickUp), and we implement the CRUD webhook interfaces ({create, delete, update}Webhook) of our own internal API for each of them. Essentially, we teach our internal sync engine how a specific tool’s webhook is created. Some apps want us to specify which events should trigger it, some operate by folder/project, some let us do extra filtering, etc. This is where Unito shines: we piece everything together so that your workflow can run smoothly across tools.
After ironing out the kinks, the webhook begins operating normally in our sync engine:
- As you create a flow between Teamwork and ClickUp, for example, our sync engine automatically creates a webhook on each side.
- Then, as you modify your task in Teamwork, the tool instantly sends us a webhook telling us the task was modified. This allows us to immediately trigger your Teamwork/ClickUp workflow.
This process is what allows end users to go into Unito and build out their perfect workflows. You tell us exactly what information and data you want to travel between your tools, and the webhooks go to work.
What are other modern web services that use webhooks?
Zapier’s dashboard and Zaps
Zapier is an automation platform with thousands of integrations, and all of them rely on webhooks to ship data between tools. While you don’t need to work with those webhooks directly to use Zapier, they’ll be moving data back and forth behind the scenes.
Shopify webhooks
Shopify webhooks help integrate the popular e-commerce platform with a ton of other apps, and developers can work with them directly to build their own integrations. Examples of use cases for these webhooks, as highlighted in Shopify documentation, include:
- Sending notifications to clients through instant messages.
- Pulling data to warehouse it in a separate platform.
- Filtering order items and forwarding that information to shipping companies.
Stripe webhooks
Stripe may be one of the most integrated platforms on the internet. Its webhooks allow developers to add simple payment and invoicing solutions to their websites and applications. Payment data is carried back and forth, making it a lot simpler to accept payments for just about anything.
Hook, line, and sinker
Almost any time websites or apps are connected, a webhook is involved somewhere. By pushing data through HTTP requests, developers can streamline online experiences for users and visitors, and integration solutions like Unito can close the gaps between tools.
Webhooks FAQ
What are webhooks?
Webhooks are essentially automatic messages that send data out from a tool in a format — an HTTP request — that can be easily read by other apps.
What are webhooks used for?
Webhooks are often used by developers and other builders to share data from one app to another. From there, they can either integrate specific parts of the platform with another software tool or, like the developers at Unito, use these webhooks as part of a broader integration that will send the data back and forth between tools.
Are webhooks secure?
Yes, webhooks use a number of security measures to keep data secure in transit, including HTTPS, HMAC, verification tokens, and timestamps.
What is a webhook URL?
A webhook URL is the specific web address where data gets sent. The app that wants to receive data from a webhook provides this URL.
What’s the difference between a webhook and polling?
A webhook starts with the sending app and data is only sent when a specific event triggers it. With polling, the destination app checks the source app for specific data over and over again, and requests a data transfer when relevant.
Do webhooks work in real time?
Webhooks are as close to real-time as it gets. Data transfers are triggered by specific events, so the webhook starts sending data when these events occur.
What is the difference between a webhook and an API?
An API is essentially an intermediary used to access different parts of a software tool. It’s used when you want to send data out of that tool to another place — usually another tool, but sometimes just a raw data export. An API allows developers to use webhooks to push that data, and they act as a sort of shortcut. Think of an API as an access code to get into a building while a webhook is what actually allows you to travel throughout the building.