What is a Webhook? A Beginner’s Guide
A webhook 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. 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.
Webhooks vs APIs
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 which allow other tools to communicate with 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.
Advantages of using webhooks
There are three main advantages to using webhooks:
- Automation
- Performance
- Cost
The clear advantage to using them is that they’re automatic. They don’t require you or your tool to spend effort and resources to query the API of the tools you need to interact with. You just maintain a server able to accept the webhooks, and it receives the news.
With this automation, comes improved performance. Because there’s no manual action or querying involved in this interaction, it can happen so much faster. The second something happens and 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 possible. 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 10 or 15 minutes, you’re using CPU or RAM which can really cost your business, especially if you’re hosted on the cloud.
With webhooks, that other business is the one calling you, so you share the resource load and spend a lot less money in the process.
Webhooks and security
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:
- 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.
- 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 signature in a webhook — as well as information about what type of even it is — so it can be verified.
- 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. Used Stripe or GitHub before? Then you’ve made use of webhooks that rely on this method.
- SHA-1: This is an algorithm that creates a 40-digit number that a receiving system looks for to authenticate a request. It was designed by the NSA in the 90s but isn’t considered very secure anymore. Facebook still uses this method.
- 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.
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 it’s done at Unito
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.
When Unito builds a brand new integration — like the ones we recently announced with Teamwork and ClickUp — we start by diving into the API of those tools.
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.
How do remote workers save time?
They use Unito to send crucial data across tools seamlessly. Tools like Asana, Trello, Jira, and more.