A webhook is an HTTP-based callback function that allows lightweight, event-driven communication between 2 application programming interfaces (APIs). Webhooks are used by a wide variety of web apps to receive small amounts of data from other apps, but webhooks can also be used to trigger automation workflows in GitOps environments.
What is an API?
An API is a set of definitions and protocols for building and integrating application software. Communication between APIs is sometimes referred to as a contract between an information user and an information provider—establishing the content required from the consumer (the call) and the content required by the producer (the response). This relationship is also described as the client app which calls the server app, but these roles can be reversed, depending on which app is requesting data in a given situation.
Web APIs typically use HTTP to request data from other apps and define the structure of response messages, which usually take the form of an XML or JSON file. Both XML and JSON are preferred formats because they present data in a way that’s easy for other apps to manipulate.
When a client API requests data from a server API, it’s calling to see if a certain event has occurred—in other words, whether the server’s data has changed in a way that might be useful to the client. In this process (known as polling), the client sends an HTTP request at regular intervals until the server’s API sends the relevant data, which is sometimes called the payload.
The client app doesn’t know the state of the server app, so it polls the server’s API for an update—calling over and over until the specific event occurs—but the server will only send the requested data once that information is available. The client app has to keep asking for the update and wait until the relevant event happens.
How are Webhooks different?
To set up a webhook, the client gives a unique URL to the server API and specifies which event it wants to know about. Once the webhook is set up, the client no longer needs to poll the server; the server will automatically send the relevant payload to the client’s webhook URL when the specified event occurs.
Webhooks are often referred to as reverse APIs or push APIs, because they put the responsibility of communication on the server, rather than the client. Instead of the client sending HTTP requests—asking for data until the server responds—the server sends the client a single HTTP POST request as soon as the data is available. Despite their nicknames, webhooks are not APIs; they work together. An application must have an API to use a webhook.
The name webhook is a simple combination of web, referring to its HTTP-based communication, and the hooking programming function that allows apps to intercept calls or other events that might be of interest. Webhooks hook the event that occurs on the server app, and prompt the server to send the payload to the client via the web. Jeff Lindsay helped to popularize the concept with his 2007 blog post, “Web hooks to revolutionize the web.”
IT teams use a variety of methods to protect apps that communicate via webhooks. Most webhook-enabled apps add a secret key to the request header of the payload, so that the client can confirm the server’s identity. Webhooks are often protected with Mutual Transport Layer Security (mTLS) authentication, which verifies both client and server before the payload is sent. It is also common for client apps to use SSL encryption for the webhook URL, to ensure the transferred data remains private.
- Eliminate the need for polling. This saves resources for the client application.
- Are quick to set up. If an app supports webhooks, they are easy to set up through the server app’s user interface. This is where the client enters their app’s webhook URL and sets some basic parameters, like which event they are interested in.
- Automate data transfer. The payload is sent as soon as the specified event happens on the server app. This exchange is initiated by the event, so it happens as quickly as the data can be transferred from server to client—as real-time as any data transfer can be.
- Are good for lightweight, specific payloads. Webhooks rely on the server to determine the amount of data it sends, leaving it to the client to interpret the payload and use it in a productive way. Since the client does not control the exact timing or size of the data transfer, webhooks deal with small amounts of information between 2 endpoints, often in the form of a notification.
Webhooks are most commonly used to simplify communication between two applications, but they can also be used to automate Infrastructure-as-code (IaC) workflows and enable GitOps practices.
What is Infrastructure as Code (IaC)?
Infrastructure as Code (IaC) is the managing and provisioning of infrastructure through code instead of manual processes. Version control is an important part of IaC, and configuration files should be under source control just like any other software source code file. Deploying infrastructure as code also means that infrastructure can be divided into modular components that can then be combined in different ways through automation.
Automating infrastructure provisioning with IaC means that developers don’t need to manually provision and manage servers, operating systems, storage, and other infrastructure components each time they develop or deploy an application. Codifying infrastructure provides a template to follow for provisioning. This can still be accomplished manually, but these processes can be automated with an enterprise-level desired state engine, such as Red Hat® Ansible® Automation Platform.
What is GitOps?
Often considered an evolution of IaC, GitOps is a strategic approach to managing infrastructure and application configurations using Git, an open source version control system. Following GitOps practices, developers use Git as a single source of truth for declarative infrastructure and applications, and use Git pull requests to automatically manage infrastructure provisioning and deployment. The Git repository contains the entire state of the system so that the record of changes is visible and auditable.
Where do webhooks come into it?
Webhooks reduce the steps required to implement and manage git-centric deployment pipelines, and can be used to automatically launch entire IaC workflows. In a GitOps environment, a webhook functions the same as it does between 2 applications; when triggered by a specified event, 1 API sends a payload to another API. The difference lies in what type of event triggers the webhook and what the recipient does with the payload.
In this context, the git repository plays the role of the server app, while the desired state engine—which manages the state of infrastructure—plays the role of the client app. A webhook can be set up to trigger communication whenever a change is made in the repository. For example, if a piece of code is updated and pushed to the Git repository, this event will trigger the webhook. The repository then automatically sends the payload to the desired state engine’s webhook address, informing it of the code change.
Using webhooks in this manner allows desired state engines to keep close tabs on any infrastructure changes, without having to actively monitor repositories. If the desired state engine also supports automation, webhooks can be used to trigger IaC workflows. For example, with an enterprise-level desired state engine—like Ansible Automation Platform—a system administrator can use webhooks to automatically deploy the latest changes on their managed hosts.
Red Hat® Ansible® Automation Platform comes with built-in automation webhooks to support IaC and GitOps practices. Webhooks enable the native integration of a Git repository—via a service like GitHub or GitLab—with Ansible Automation Platform. Once a repo link is set up, Ansible Automation Platform catches Git commits from the Git system and uses those events to trigger automation jobs to update projects, manage inventories, and perform deployments.
Automation webhooks allow you to automatically activate automation workflows when events occur in your source control system. This eliminates the need for additional CI/CD tools—like Jenkins—to monitor repositories and launch automation jobs when changes occur, simplifying your GitOps workflow and streamlining operations. Because Red Hat Ansible Automation Platform works with a wide variety of development and deployment tools, you can tailor your GitOps workflow to your preferred tools and processes.