What are Webhooks and why should developers use them?

Webhooks and APIs are a developer-friendly approach to building modern-day web applications. In this blog, we explain what a webhook is, do a detailed webhooks vs. API comparison, and explain why we recommend developers use them with Squadcast.

What are Webhooks?

Webhooks are a means for different applications on the web to communicate with each other in real-time. They allow developers to build applications that can react to certain events happening on other applications. This makes it easier for developers to build integrations between different applications because they don't have to worry about constantly checking for updates.

A common application of Webhooks is applied in couriers/ shipments. As and when the package arrives at a warehouse or crosses some transit point, a notification automatically goes out to the receiver informing them of the updated location and estimated ETA.

Why do we recommend Developers to use Webhooks?

Fundamentally, you can use webhooks to send data from a source to a destination by simply specifying an endpoint URL. And since Webhooks allow systems to exchange data in response to event triggers, they are key building blocks of modern web applications.

In short, Webhooks are a resource-light alternative to APIs because rather than periodically polling the application to see if there are any new updates, they rely on changes in the event state to trigger the next set of actions in a workflow.

Another advantage of webhooks is that they can be triggered by a wide variety of events, so developers can use them to build very flexible and responsive applications. For example, a webhook could be triggered when a new user signs up for a service, when a payment is made, or when a form is submitted. This makes it easy for developers to build applications that can react to changes in a variety of different systems. Many other modern web services like GitHub and Slack also make use of webhooks to communicate events.

Most of all, Webhooks are easy to create and easy to implement. Most web development frameworks such as Django, Express, Rails, and Laravel provide a way for developers to create Webhooks using their preferred programming language. Infact, even serverless frameworks like AWS Lambda and Azure Functions can listen to Webhook requests. Bottomline is, Webhooks can be used with anything that can listen & reply to HTTP requests.

So far, we’ve covered a lot about Webhooks. Now let’s try to understand what was the need for it in the first place when APIs themselves do something similar.

Need for Webhooks

HTTP is based on a traditional 2-way communication architecture where a client sends a request to the server and the server responds in return. And depending on the service in question there could be plenty of to and fro of data leading to heavy load.

Webhooks work differently. They support the mechanism of 1-way communication. So depending on the use case, you can configure the server to send data to a client based on occurrence of pre-defined conditions.

Now let’s understand this in more detail by fundamentally breaking down the differences between an API and Webhook, and when either of them should be used.

Webhooks vs APIs: How different are they?

In case of an API, communication is always initiated from the client’s end to the server. In technical terms, the request is initiated by the client. And in return, it expects a response from the server. An example is the Weather App on your phone where the app periodically polls the server for updated temperature data.

However, in case of a Webhook, communication is initiated by the server and data is subsequently delivered to the client. But the point to note is that the client registers itself to the server in advance.

An example is a data upload service to a backup server. In such a case, instead of polling the server for constant updates, the client can subscribe to the server and whenever certain criteria is met, the server issues a notification to the subscribed client.

Now let’s understand this with a better example. For two web applications to communicate with each other, one or the other method can be used. (Ex. considered: your friend is baking a cake and you want a piece of the pie 😋)

• Polling (a method used by API calls) this is like knocking on your friend's door every now and then and asking if they are done baking the cake(aka information). You have to post this question every now and again(constantly poll a service to get the latest update)
• Webhooks this is like requesting your friend to save a piece of pie for you. And whenever the pie is ready, he will issue a notification informing you to come over and collect it. (Automatically receive information from a service as and when there is an update)

APIs

API call is a way for a server to respond to a client request.
Purpose of an API is to respond to any realtime request as and when received by the server.
Example of an API in action - The weather app on your phone. It manually polls temperature data (or sends a request to a server) and your phone app receives a response in return for the request.
APIs are resource-heavy because it constantly requires for to and fro (2-way communication) between a client and server.
APIs are similar to modern-day phone calls.

Webhooks

A way for the server to send data to the client.
Purpose of a Webhook is also to respond in realtime, but only on the basis of future events occurring at the server.
Example of a Webhook in action - The Email app on your phone. As and when you receive an email, an in-app notification is triggered in your phone(note there was no request made).
Webhooks are resource-light because data is only sent 1 way from a server to a client (even though it is technically a 2-way communication)
Webhooks are similar to SMS notifications.
Bottomline is, Webhooks are automated messages sent from apps when something happens. They have a message—or payload—and are sent to a unique URL—essentially the app's phone number or address. Webhooks are almost always faster than polling and require less work at your end.

How do Webhooks work?

Configuring a Webhook

As explained earlier, for a Webhook (even API for that matter) there are two stations - a provider and a receiver. The occurrence of a particular event can trigger the Webhook provider to post the data to an end-point URL (at the receiver’s end). This end-point URL must also be accessible from the public web.

The data that is posted will usually be either in JSON or XML format as specified by the provider. And most web frameworks will support the application of Webhooks. If the web frameworks don’t, you may need to call on a function or two.

Debugging a Webhook

Since Webhooks are asynchronous, debugging them can get tricky. You must first trigger the webhook, wait for a couple of seconds, and then check the response. There are other workarounds involving various tools to avoid this manual effort:

• RequestBin - can be used to collect Webhook requests to verify the data
• Webhook.site - can be used to inspect, test and automate any incoming HTTP request or email
• Postman / cURL - can be used to mock the requests
• Ngrok - can be used to test the code on your machine
• Runscope - can be used to visualize the entire flow

Securing a Webhook

This is an essential aspect of implementing Webhooks. Since the URLs are publicly available, anyone that gets hold of the end-point URL can start sending you false data. So it's extremely important to be careful, to who you reveal the URLs. Either ways its recommend to enforce TLS connections (HTTPS). You can then secure your connection by following one of the techniques:

• Add tokens to the URL that act as unique identification, e.g.,?auth=TK.
• Implement Basic Auth. This is also widely supported and very easy to do
• Have the provider sign each request it makes to the receiver and then verify the signature. This is the most secure technique because the first two require sending the auth token along with the request For more advanced information related to webhooks security, you can check this link.

Tips and best practices for creating Webhooks

When configuring Webhooks, keep the following in mind:

Webhooks are primarily tasked with posting data to an end-point. They do not provide an update on the delivery status. You have to manually watch out for 200 response status code, which indicates successful delivery of the post data.
Some webhooks will also pay attention to responses and resend requests if there are errors. But if your application processed the request, and still sent an error message, you can potentially experience data duplication.
Too many events getting triggered at the provider’s end can result in an equally high number of requests being posted to the receiver. Too many such requests can lead to ‘Distributed Denial of Service’ at the consumer’s end. That’s it, folks!

Final thoughts

Webhooks and APIs are a developer-friendly approach to building modern-day web applications. Devs from around the globe, prefer to do this. And we’re happy to announce that Squadcast strongly encourages the use of Webhooks and APIs to configure/automate your Incident Response.

In the next set of blogs, I will explain how you can use our APIs and Webhooks to automate incident management workflows at your end. You will then understand how powerful Squadcast’s Developer Portal is and the capability/ flexibility of our developer ecosystem.

Stay tuned, more to follow soon!

Squadcast is an incident management tool that’s purpose-built for SRE. Get rid of unwanted alerts, receive relevant notifications and integrate with popular ChatOps tools. Work in collaboration using virtual incident war rooms and use automation to eliminate toil.