Table of Contents
Webhooks might seem like an API at first, but they are slightly different. The main difference between them is that webhooks do not need to give a request to get a response, while APIs need to send a request to get a response. Webhooks let you receive, while APIs require you to retrieve.
An example would be the GitHub Webhook vs the GitHub API. For the GitHub API, you need to send a GET request every time you want a piece of information. Compared to the GitHub webhook, where it is a setting that you turn on and add a URL to send POST data to. Once the webhook is properly set, anytime you update information on your GitHub, data will automatically be sent to the URL you have in your webhook settings.
To clarify better, we can look at the two cases: using a webhook and using an API.
1. Using API: Let's say we want the latest commit date of a Github repo for a service. The Service API will first need to have a function that auths to the GitHub repo’s owner account, and then have another function that calls the correct endpoint for a GET request to the latest commit date.
2. Using a webhook: The Service Webhook will need to create its own webhook URL and then the URL needs to be put into the GitHub repo’s settings. Once that URL is set, anytime any event happens on the repo, GitHub will send a POST request with all updated data to our webhook URL. If the webhook is working, the latest commit date from the webhook data can easily be displayed on the service.
As you can see in the image above, using a webhook makes retrieving data more automated. GitHub Webhooks throw data over to our service whenever there’s an update, whereas GitHub APIs require us to retrieve data from GitHub.
Some downsides of webhooks are compatibility and support. Since APIs are more detailed and manual, it is easy to integrate them quickly from point A to point B. Some services do not support web hooks yet, which makes setting them up more difficult. Whereas every service will usually offer an API.