my cheat sheet on webhooks

All about not having to poll for data or events but have a server deliver the information via a webhook notifications to the clients.

They work in reverse from regular APIs and invert the server/client concept. Instead of the client creating a request toward the server, a client subscribes to a specific webhook. This is done by creating a POST request to the webhook endpoint. The POST request usually contains more data, such as authentication data, which events the client wants to subscribe to, which address and port should be notified, and other data. This puts the client on a list of subscribers for particular events. When those events happen on the server, another POST request is used to notify the client and provide them with event data. This is called a webhook notification and it needs to be caught by the client. These notifications can contain the data of the event or just a reference to this data, which can then be read over a regular API.

Consuming a webhook requires detailed knowledge of the API. In contrast to polling the API, where similar to pressing the reload button, each poll has a reaction (even if it is an error), webhooks only become active when they have to. Some webhooks will pay attention to the client response and will retry sending the data, while others will make a request, then forget about the data. This is why it is important to thoroughly test and debug the webhook, using tools like Hookbin or ngrok.

As with APIs, webhooks present another attack target for potential attackers. Security, authentication, and authorization mechanisms are the same as with regular APIs; use HTTPS for encryption, use different access levels for different events, delegate credentials to users via a secure channel, and so on.

In the real world, you would commonly subscribe to a public webhook from a secure enterprise network that features a firewall, which blocks most of the incoming requests. Therefore, your machine usually is not accessible from the public web. To get around exposing your machine to the world, a common practice is to use webhook forwarding services or reverse HTTP proxies that securely

Take a look at a simple example of how webhooks can be used to integrate different products. Imagine that you are a software developer in charge of integration between Cisco Webex Teams and a ticketing system. Your company uses Webex Teams for internal communication as well as for communication with customers. The support department uses a dedicated room for reporting errors, because the customers do not have access to a ticketing system. Each time a new message gets posted into that room, a new ticket needs to be automatically opened in the ticketing system.

Webhooks are used in many areas:

Marketing (newsletters, advertisement distribution) Monitoring (listen for alarms and errors on other systems) Social networks (notifications) Many other event-driven services