28 October, 2022
Top Books Every Web Developer Should Read
17 November, 2022
You may have seen webhooks integrations in a few of your applications, and you’re wondering what they are and if you should be using them. Webhooks are definitely in demand, so let’s see what exactly they are.
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.
Basically, webhooks are used to communicate the occurrence of an event in one system to another system, and they often share data about the event.
It’s easier to understand with the help of an example: let’s say you’ve created an application using the Foursquare API that tracks when people check into your cafe/restaurant. You ideally want to be able to greet customers by name and offer a complimentary drink when they check-in.
Here, webhook notifies you when someone enters the restaurant, so you’d be able to run any processes that you had in your application once this event is triggered.
The data is then sent over the web from the application where the event originally occurred to the receiving application that handles the data.
As more and more of what we do on the web include events, webhooks are becoming more and more applicable. These are incredibly useful and resource-light ways to implement event reactions.
Now, let’s get into the process to get a better image of how webhooks work.
First of all, Webhook sends an HTTP request. To receive webhook requests, you have to register for one or more of the events/topics for which the platform offers a webhook.
Webhooks are most common in SaaS platforms like GitHub, Shopify, Stripe, Twilio, and Slack because they support different types of events based on the activities that happen within them.
Once the webhook registration for an event is complete, you will receive webhook requests at the destination URL you provided each time the event occurs.
A single webhook request can also be distributed to multiple destinations that require the information, in a process known as fanning out. This allows source systems to speak to more applications and better distribute information across the web.
You should also make the webhook request operation at your end idempotent, as the same webhook request from some source applications can be sent more than once. In this case, you want to ensure that your response to a webhook request is not duplicated as this might lead to a compromised system.
Another thing you should know, before receiving a webhook request - you can get them as GET or POST requests, dependent on the webhooks provider. GET webhook requests are simple and have their payload appended to the webhook URL as a query string. POST webhook requests have their payload in the request body and might also contain properties like authentication tokens.
Webhooks, as mentioned above, simplify a lot of processes on your application. They automate the pull requests, merging, pushing, and others. You can create a topic that would trigger the webhook request which will do the work for you.
To add Webhooks in GitLab, you should:
Now that you have a good understanding of how webhooks work, let’s see when it is then appropriate to go with webhooks.
You should use webhooks when you require the following:
A lot of SaaS applications use webhooks for communication. For instance, Shopify uses webhooks to communicate events like when somebody updates a shopping cart or makes a sale. Stripe uses webhooks to communicate events like account updates, payments, etc.
Notification and Information Sharing:
Hopefully, this article helped you understand the advantages and limitations of the webhooks process, and the right places to implement it.