What is a webhook and how do you use it?

Webhooks allow web-based applications to interact through the use of custom callbacks.

Using webhooks allows web applications to automatically communicate with other web-apps.

Unlike traditional systems where one system (subject) keeps polling another system (observer) for some data, webhooks allow the observer to automatically push data into the subject's system whenever an event occurs.

This eliminates the need for constant monitoring by the subject. Webhooks operate entirely on the Internet and therefore all communication between systems must take place in the form of HTTP messages.

Using webhooks

Webhooks rely on the presence of static URLs pointing to APIs in the subject's system that need to be notified when an event occurs in the observer's system. An example of this would be a web app designed to collect and manage all orders placed on a user's Amazon account. In this scenario, Amazon acts as the observer and the Custom Order Management Webapp acts as the subject.

Instead of having the custom webapp periodically call the Amazon APIs to check for an order created, a webhook created in the custom webapp would allow Amazon to automatically submit an order newly created in the webapp via a registered URL. Therefore, to enable the use of webhooks, the subject must have designated URLs that accept event notifications from the observer. This reduces a significant load on the object since HTTP calls are made between the two parties only when an event occurs.

Polling based systems vs webhook based systems

Once the subject's webhook is called by the observer, the subject can take the appropriate action with this newly submitted data. Typically, webhooks are done via POST requests to a specific URL. POST requests let you send additional information to the object. Additionally, it can also be used to identify among a number of various possible events instead of creating separate webhook URLs for each event.

Webhook workflow

To implement inbound webhooks on your application, you need to perform the following basic steps:

• Expose an API endpoint on your application server that accepts and processes HTTP POST calls
• Provide access to this endpoint for potential webhook users. The API endpoint will call a data source application whenever the relevant conditions are met.
• Process the POST data and return a response to the webhook call initiator to indicate the status. This step may or may not be present.

Webhooks vs. APIs

Both webhooks and APIs have the goal of establishing communication between applications. However, there are some distinct advantages and disadvantages of using Webhooks over APIs to achieve application integration.

Webhooks tend to be better solutions if the following points are more relevant to the implemented system:

• If the data is frequently updated on the server, webhooks tend to be better solutions as unnecessary API calls from the client to the server are eliminated. According to resthooks.com, 98,5% of API surveys go to waste.
• Webhooks enable better solutions for systems that require near real-time data updates. API polls typically run at set intervals which may prevent live data from being updated. With webhooks, updates are sent from the server to the client as soon as the webhook is triggered.

Using the API should be preferred over webhooks in some other situations.

Aspects to consider

The important things to consider for using APIs on Webhooks are:

• Using the API allows for more customization of when to poll for data from a server and also how much data to poll from the server. The amount of data to be polled is governed by the API poll size. With webhooks, the server generally decides the data and when it is sent.
• For systems with highly variable data (like real-time systems, IoT systems, etc.), API-based polling might be a better option since for every API call, there is a high probability of usable responses.
• It is possible for data sent from a server, via a webhook, to be completely ignored by the client in case the REST endpoints are offline. In case the server doesn't have a mechanism to retry such failed pushes, data updates are completely lost.

To deal with the possibility of losing data sent from a server when the webhook goes offline, you can use an event messaging queue to archive those calls. Examples of platforms that provide such functionality include Rabbit MQ o Amazon's Simple Queue Service (SQS). Both are designed to act as intermediary messaging storage facilities that avoid the possibility of missing a webhook call.

Ercole Palmeri