If you’re a developer or
site reliability engineer, you might have noticed options to use webhooks in your cloud monitoring or automation settings. And if you have a great deal of experience developing APIs, you probably know what a webhook is. For the rest of the world, a webhook (also known as a web callback or an HTTP push API) is a way for an application to provide other applications with information in real time. Webhooks are a lightweight and useful way to implement event reactions—a common use case might be if you want to take an automated action to make a configuration change based on specific types of events occurring in your cloud infrastructure, you can use a webhook.
Webhooks can provide lightweight functionality to deliver data in near real time. Instead of repeatedly calling an API to poll often to capture real-time data, a webhook delivers data through the HTTP post method. While polling can be easy to implement, each time you need to make a polling request, you must make an API call. If you’re of a certain age, think of this as calling information to get the current time. You get the information immediately, but if you want to get the time five minutes later, you must call again. Webhooks are more like a service outputting the time every 30 seconds without action.
This means your web application can send automated messages or information to other applications in response to a specific event—if you want a transaction taking place against a Stripe
® API to send a call to Twilio
® to send a text message (SMS) to confirm a transaction, you can execute all of this using webhooks. The architecture of a webhook request is a payload, which is typically JSON sent to a unique URL, which effectively acts as the endpoint for the application receiving the message.
How Do I Make My Application Consume a Webhook?
The challenge to adding webhooks to most applications is ensuring the implementation process is successful. Typically, as part of the API build process, an application will have a URL provided to the webhook provider. This URL, in most cases, needs to be available over the public internet. In secure environments, you may need to add webhook IPs or URLs to your allow list. In most cases, the webhook will perform an HTTP POST action, typically in the form of a JSON document, though rarely you may encounter webhooks supplying XML. Most web software frameworks will do the work of interpreting the data. However, in some cases, you may need to write a function to consume the payload.
While this is a basic overview of webhooks, they’re formally defined as “user-defined callbacks made with HTTP,”
per Jeff Linsday, who was one of the first to conceptualize webhooks. They get the name webhooks because they’re software hooks or functions executing when a given event happens. Their security is typically based on the obscurity of the unique, random webhook URL, though for more robust security, you should consider securing them with a key or a shared access signature. You can also force transport layer security (TLS) encryption for your connections, which requires communications to take place over HTTPS. Most webhooks rely on a combination of adding a URL token combined with basic authentication. Since webhooks connect two or more different applications, they rely on HTTP status codes to provide status. If the application receives a callback message with a status code of 302, it indicates the call was successful, while an application receiving a 404 status will be indicative of failure.
How Are Webhooks Different From APIs?
An API is a full language for an application, with functions defining calls to add, edit, and receive data. If you need to build an application for interacting with another application with an API, you must include methods for calling the other API and scheduling those calls. Since webhooks are only specific to one part of application behavior and are event driven, the code and the implementation are more straightforward than a full-blown API.
Gotchas With Webhooks?
One of the essential things to understand when using any web-based system is how the system deals with a degraded state. After a webhook delivers data to an application, it may stop paying attention after making a request after delivering it. This can lead to data loss if your application has an error while receiving a message. The key takeaway is understanding how your webhook provider deals with various error responses so you can develop applications with proper error handling. The other problematic aspect of webhooks is the frequency of requests. While webhooks are lightweight, if they’re called thousands of times a second, you can effectively ‘distributed denial-of-service (DDoS) attack’ your own application. Ensuring the application can sustain itself under the load of webhook calls should be part of your application architecture.
Getting Started With Webhooks
Like anything else in software development, the easiest way to get started with webhooks is to build your own or build an application to interact with someone else’s webhooks. And since many services use webhooks, it can be fairly easy to get started with them.
Webhooks let you easily handle events and manage event response within your application. The next time you think about an HTTP callback, think about webhooks and how they can work
with your applications. And you should look in the advanced settings of any of your web applications from software-as-a-service (SaaS) vendors and see if they also support webhooks.
To learn more about how SolarWinds uses webhooks in
AppOptics™, you can
check out our docmentation here. You can also see how
Pingdom® interacts with
webhooks and Slack® notifications and how it manages its state change webhooks
here.
