A Few Hours of Webhook Research

I started my day off wanting to learn more about webhooks and what drives them. This led to a rabbit hole of sending, receiving, posting, pushing, and pulling data. Then to a cool tool that explains more about building a webhook endpoint. Then back to the CLI and comparing webhooks to piping.

The term webhook has always been confusing to me and the light clicked on the moment I read the words reverse API, in this article. All a webhook boils down to is it is a custom call back function that comes over HTTP. It could be from your source code or a third party, and will push data to your endpoint when an event is triggered. According to the same article above, it is usually used for small data sets, since it is event driven you only really want to know about the event and update what is connected to that event in your data.

This line of thought led to, "why wouldn't I use an API for that", and the answer is because I do not want to continuously make repetitive calls when a webhook will let me know. With an API I would have to make the call and wait for it to be returned, while with a webhook the third party will send the data to my endpoint when something changes. That something is an event that I can select, in my case from a list of predefined events, that will push an event object to my end-point that will then parse it and keep me up to date with the data I need.

This led to Stripes webhook docs where they have an interactive custom webhook endpoint builder. It walks you through setting up the endpoint, how to handle the requests and event, then explains how to test the endpoint you built.

In this interesting article by Jeff Lindsay he compares webhooks to piping in a Unix based terminal. Instead of polling for the data from a feed, Lindsay states webhooks are the high level of equivalent of piping, you wait for data to be pushed and modify it as you see fit.