Communication is important, both in life and work environment. According to a research on the "Measurement of Time Spent Communicating", the relative amount of time people spend in workday activities, which was estimated by both an observational and questionnaire method and the results from professional, technical, administrative and clerical people in a communications research and development laboratory, shows that 50%–80% of the workday is spent in communicating, and two-thirds of that in talking.

Technology and services help us reduce the amount of time and help us communicate more effectively. But when we have too many services that we are using on a daily basis, we find ourselves in a need to make these services communicate with each other.

We know that APIs can do that, but we need to write some code in order to utilize them. However, in most cases, this could be an overkill or ineffective especially for syncing data between services that are changing frequently. Most likely we would be using mechanisms that could be performance draining such as polling.

There is a better way to do that; Webhooks.

What is a Webhook?

Wikipedia defined the webhooks like the following.

A webhook in web development is a method of augmenting or altering the behavior of a web page, or web application, with custom callbacks.

Simply, a webhook, which is also known as a web callback or HTTP push API, provides real-time data of the implementer web application to the other web applications.

Because of the nature of the web, and because everything we do on it could be described as events, webhooks became popular.

Sounds like an API?

Well, because it is with a bit of a twist. Let's say we are building an application that is requiring some data from Github.

We usually send a request, from a web application to an API asking it for something or to do something. For instance, we are going to send a GET request to which would return the following data in JSON format.

  "login": "anasshekhamis",
  "id": 8655220,
  "avatar_url": "",
  "gravatar_id": "",
  "url": "",
  "html_url": "",
  "followers_url": "",
  "following_url": "{/other_user}",
  "gists_url": "{/gist_id}",
  "starred_url": "{/owner}{/repo}",
  "subscriptions_url": "",
  "organizations_url": "",
  "repos_url": "",
  "events_url": "{/privacy}",
  "received_events_url": "",
  "type": "User",
  "site_admin": false,
  "name": "Anas Shekhamis",
  "company": null,
  "blog": "",
  "location": "Helsinki - Finland",
  "email": null,
  "hireable": null,
  "bio": "A software engineer who specializes in architecting and developing web applications and services. Primarily, I use Python, Node.js, JavaScript, Ruby, and PHP.",
  "public_repos": 6,
  "public_gists": 0,
  "followers": 2,
  "following": 1,
  "created_at": "2014-09-04T11:59:45Z",
  "updated_at": "2018-03-19T13:52:00Z"

However, a Webhook will be triggered when an action happened. Let's say for example that we are pulling the bio above and using it as a bio for the profiles on this blog. We would have to register a Webhook on GitHub that whenever the bio is changed, it'll send a POST request to a certain URI on this blog to update the bio on the profile. I would like to think of it as a programmable IFTTT.

Why using Webhooks?

No one wants to use "Polling". It's a waste of resources for the server and the client alike. Hitting the server to see if the something was updated is better done by webhooks. But an API hitting the server once every second is not that big of a deal, right? Well, it is when we have thousands or hundreds of thousands of APIs that are doing so. Server processing, dealing with the traffic, and probably restoring the data from a data store could be avoided with webhooks. Besides, even hitting the server every second, we might be still not actually in the real-time, but a most likely split of a second gap depending on how long the polling takes.

This is one use of them, but it does not stop there. Webhooks also could be receiving data, process it in some way, and pass it along to some URL or even another Webhook. It's exactly how "pipes" commands in Linux work. For instance, this command will list all the files/directories in the current directory for the month March.

$ ls -al | grep Mar

An example of the "pipe" Webhook could be writing a piece of code that creates a Twitter message and have it triggered by a WebHook whenever a new post on my website is published.

Webhooks could save development time when an extra feature is not much requested but could add a value to a certain group of users. For example, we had a certain customer who was using a customized software that could only send one request at a time. The customer wanted to be able to create a new user and add some additional information, that could only be added after the user was created, in one call. Piping that second API call in a Webhook did what the customer requested without changing anything in the API.

Webhooks in the wild

While there is no specification for Webhooks, there are some movements from the community to provide a common ground for it. For example, Rest Hooks.

REST Hooks itself is not a specification, it is a collection of patterns that treat webhooks like subscriptions. These subscriptions are manipulated via a REST API just like any other resource.

Webhooks could be found on multiple services that we are using on a daily basis.

Finally, your application could actually support Webhooks. It could be a challenge to support it but should be considered whenever the users find a need for that.