An Introduction to Webhooks

Laatste update 04 juli 2022

Modern applications often work reactive, based on a wide range of events. For this purpose, webhooks offer a simple and fast way to spin up processes, fired from these events. Let’s have a look at what webhooks actually are.

Webhooks versus polling

When the concept of webhooks is explained, they are mostly compared with polling.

Polling involves a client that interrogates the server API at regular time intervals to know if there is new data to be processed. The server side API performs a lookup each time and returns the result set, which is often empty.

Webhooks require the client to register first for specific events. The client provides a URL that must be called in case a server side event occurs. When an events occurs, the server looks into its subscription store and invokes every registered HTTP endpoint with the event payload.

Advantages

The “don’t call me, I call you” concept of webhooks, introduces the following advantages:

More efficient: with polling, many API calls lead to no data exchange. Webhooks are more resource-friendly, because there are only API calls when events occur.
Faster: the speed of data exchange with polling depends on the polling interval of the client. Webhooks invoke in near real-time the client, when an event occurs.
No client side state: during polling, the client often needs to maintain state between two API calls (e.g. remember last modified datetime). This requirement is no longer needed when applying webhooks.
Extensibility: webhooks offer the ideal mechanism to provide extensibility for your (SaaS) application. Consumers can perfectly extend the core application, by subscribing to the offered webhooks.

Disadvantages

Unfortunately, as with every design decision, there are also some downsides to using webhooks:

Not standardized: because there’s no real standard, many different implementations for webhooks exist. Hopefully, the CloudEvents standard will get wide industry adoption soon.
Extra responsibilities: the webhook pattern is only successful when both client and server fulfill their responsibilities in regards to security, availability and reliability.
Black-box: when using webhooks from external (SaaS) applications, you often don’t have any visibility as to whether the webhooks have been fired or if they are facing internal problems.

Webhooks versus web sockets

Although both concepts are an alternative to polling, they are quite different.

Web sockets are mostly used in server to browser communication. They require a long-lived connection and provide a two-way communication channel.

Webhooks are mostly used in server to server communication. They initiate a short-lived connection when the event occurs and provide only a one-way communication.

Examples

There are many implementations of webhooks out there. Here are some of them:

GitHub: has state of the art support for webhooks. You can choose the Content-Type, provide a secret for additional security and select multiple individual events.

Teamleader: allows to subscribe to all events on their available CRM entities. You can choose between JSON or XML format.

Azure Monitor Alerts: Azure monitor alerts allow you to specify, next to the default email alerts, a webhook to be invoked when an alerts is fired. It’s a good practice to provide the request URL of a Logic App, which can provide advanced notifications.

Azure Event Grid: Azure Event Grid is a fully-managed intelligent event routing service that allows for uniform event consumption using a publish-subscribe model. Use Azure Event Grid to react to relevant events across both Azure and non-Azure services in near-real time fashion.

Keep an eye on this blog for more articles about webhooks!