Webhook ¶

Real world analogy

There are two ways your apps can communicate with each other to share information: polling and webhooks.

Polling is like knocking on your friend's door and asking if they have any sugar (aka information), but you have to go and ask for it every time you want it.

Webhooks are like someone tossing a bag of sugar at your house whenever they buy some. You don't have to ask—they just automatically punt it over every time it's available.

Webhooks are a way for one application to provide other applications with real-time information. They allow one application to send a notification to another application when a certain event occurs rather than constantly polling for new data. This can help save on server resources and costs.
Instead of one application making a request to another to receive a response, a webhook is a service that allows one program to send data to another as soon as a particular event takes place.
Webhooks are sometimes referred to as push APIs or reverse APIs because instead of pulling data from one system to another, they push the data to update it in real-time. In either case, the webhook's meaning is the same; it enables you to share data. Webhooks work by making an HTTP request from one application to another.

Slack Example

Say for instance you want to receive Slack notifications when tweets that mention a certain account and contain a specific hashtag are published. Instead of Slack continuously asking Twitter for new posts meeting these criteria, it makes much more sense for Twitter to send a notification to Slack only when this event takes place. This is the purpose of a webhook––instead of having to repeatedly request the data, the receiving application can sit back and get what it needs without having to send repeated requests to another system.

Webhook VS API's¶

Webhooks are different from APIs, which allow for communication between different applications but work in a different way. An API is a set of protocols and routines for building and interacting with software applications, whereas a webhook is a way for one application to notify another application when a specific event occurs.

In other words, an API allows you to retrieve data, while a webhook allows data to be pushed to you. This means that instead of having to poll for new data, you can receive data in real time through webhooks.

Setting up Webhooks¶

Determine the events to be notified: Identify the events that you want to receive notifications for. For example, you may want to be notified whenever a new customer is added to a CRM system or a new order is placed in an e-commerce store.
Create the webhook endpoint: Set up a webhook endpoint in your application to receive the notifications. This endpoint should be a public URL that can receive HTTP POST requests. You may also need to add security measures, such as authentication and encryption, to protect against unauthorized access.
Register the webhook: Register the webhook with the application or service that will be sending the notifications. This may involve configuring settings in the application’s user interface or making API calls to register the webhook endpoint.
Handle the webhook notifications: When a webhook notification is received at the endpoint, parse the payload and handle the data or event accordingly. This may involve triggering a custom action, storing data in a database, or sending notifications to users
Handle errors and retries: Webhooks can fail for various reasons, such as network errors or server downtime. Make sure to handle these errors gracefully and implement retry logic to ensure that missed notifications are resent.
Monitor and maintain: Monitor the webhook endpoint and the application’s logs to ensure that notifications are being received and processed correctly. Make updates and improvements as needed to maintain the webhook architecture.

Why webhook is limited?¶

Also, unlike APIs, webhooks do not allow the sending system to add, update and delete data on the receiving end, which is why webhooks alone are too limited to offer full integration between two applications.

Limitations of Webhooks¶

In the case of webhooks vs. APIs, you might wonder why anyone would still use an API since they're less efficient and productive. A few limitations of webhooks include the following:

Not always supported¶

Unfortunately, not all applications support webhooks. However, several types of third-party app providers can help you send webhooks by connecting apps that don't have integrations and allowing them to pass data.

Less functionality than APIs¶

Webhooks only allow for data to be received from one application for another. Therefore, they can't be used for complicated integrations that require bi-directional communication.

Potential for lost data¶

With webhooks, you won't be alerted if an application or server is down for tails to send data.
Since you'll only receive data when events occur, you won't receive any information if the other system is down. However, with APIs, you'll receive an error response alerting you that the system isn't functional.
Webhooks will attempt to resend data, but they will only try so many times before stopping. Therefore, you'll need another system to know when an application is down to prevent you from losing information

Other issues ⚠️¶

Security risks: Webhooks require a publicly accessible endpoint, which can be a potential security risk if not properly secured. Malicious actors could potentially send fake or malicious payloads to your endpoint.
Debugging can be challenging: Since webhooks are triggered by external events, debugging issues can be more challenging. It may not always be clear why a webhook was not received or processed correctly.
Can be overwhelming: If you receive a large volume of webhooks, it can be challenging to process and handle all of them efficiently. This can cause performance issues or delays in processing.
Limited control: Since webhooks are triggered by external events, you have limited control over when they are sent or how frequently they are sent. This can make it challenging to predict when events will occur and how frequently you will need to handle them.