What is a Webhook and How to Use It

Automated notifications make our lives easier, safer and more efficient in a range of real-world scenarios. Low fuel warning beeps keep us from being stranded on the side of the road, security system alerts help us protect our homes, and invite notices on our Apple Watches ensure we stay on top of work meetings.

Similar communications also occur in the applications world. Apps can notify other apps by sending real-time data whenever a given event happens, such as when PayPal alerts your accounting app that a customer has paid their invoice or when Twitter informs your marketing app that someone has mentioned your company in a tweet. These automated bulletins free you from the manual work of routinely checking whether a particular activity has occurred, thereby boosting your efficiency while making sure important information is fully captured.

The number of apps that send and receive automatic notifications is on the rise, in large part because of a simple yet powerful technology called webhooks. Webhooks are an increasingly popular tool that can save your company significant time and energy—and ultimately result in a better, more streamlined experience for your end users.

In simple terms, webhooks, sometimes called “HTTP callbacks,” are a way for apps to communicate with one another that removes any manual effort out of the equation.

Now you may be thinking that you already have a tool that does this: polling requests to an API  (application programming interface). In the polling requests model, you set some amount of time as an interval and then send HTTP requests to the server/API at every interval to see if there’s any new data. For example, suppose you need to know when a new user has been authenticated by your identity provider (which happens to be Ping!) before you can allow them to perform certain actions in your app. You would set up a polling request that would check authentications periodically, and whenever new users appear, that information would then be passed back to you. Whether a post request or a get request, that’s a lot of HTTP requests.

There are a few drawbacks to this method, however. In this “pull” model, where you’re pulling information out of the other app, the timing of the intervals can be difficult to optimize. Make them too fast and you’re wasting resources; make them too far apart and you’re slow to get updates. It’s like the kid in the backseat asking “Are we there yet?” over and over, where each question is a request to the server to say, “Hey, any update yet?” At some point the answer will be yes, but it’s an inefficient (and annoying) way to operate.

Webhooks, on the other hand, are a “push” model. An event triggers information to be automatically pushed from one app to another, and you just passively wait for notifications to be sent to you. In this analogy, the trigger would be getting to the destination, and a patient kid would wait for the parent to update them when they arrive.

To use another analogy, polling your APIs would be like muting all your Slack channels and relying on going through each of them manually, one-by-one to see if you have any new messages. Using webhooks, by contrast, would be like the default mechanism, where the event—a new message—triggers an update to you.

Right off the bat, you can probably see why you would want to use webhooks. From the consumer side, they’re great for when you’re looking to get information in real time. And from the producer side, webhooks are great for sharing updates. You don’t have to worry about getting spammed with requests, which could use up valuable resources, especially in a SaaS situation.

But it isn’t all sweetness and light. To take advantage of webhooks, the provider (for example, an identity provider like Ping) needs to implement webhooks that you can make use of. No webhooks, no way for you to apply them. Beyond that, though, there are some limitations. Webhooks aren’t usually very sophisticated, typically just passing descriptive data about an event. Nor are they dynamic, since you have to define them per event you want to monitor. 

And, they aren’t used for business logic. They pass plain data back for an app to do something with, but they can’t tell that app to make calculations based on that event to do different things. That type of logic would have to take place on the receiving app’s side.

Still, webhooks can come in quite handy. Consider a few identity provider use cases. You could set up webhooks to notify you when a user has authenticated, when a user pairs a new device for multi-factor authentication, or even when a new user is created.

To see how webhooks work with PingOne for Customers, you can start with webhook.site. This is a cool site where you can get a glimpse at what the body of a webhook notification will look like.

You can use webhooks with PingOne for Customers in a variety of ways (check out the webhooks api). Splunk and New Relic are two of the more popular SIEMs (security information and event management platforms) out there. They’re helpful for running your own logging system with information fed in via webhooks. We have formats for each to help the SIEMs consume the information.

IFTTT and Zapier are great for having your webhook trigger another action with one of the apps they support (and there are a lot!). You can configure a “Zap” or an “If This, Then That” conditional where the webhook triggers another app to perform some action. With all of the apps they support, the possibilities are endless.

Ngrok can be useful for its ability to replay requests. There’s no need to re-trigger the event or action that sent a notification through the webhook, as ngrok can replay your requests. This makes it a lot easier to debug and test.

RequestBin is another cool web application that can help you analyze what the web requests will look like. Then you know what values or variables you can use in your code, a great step toward automation.

Lastly, there’s your app! If you’re writing a custom app, you can use notifications to replace the inefficient polling technique to make your app aware of some event. Point the webhook at a URL your app hosts and sit back and wait for an event to trigger a notification. Then, with the payload of that notification, perform some custom business logic.

Setting up a webhook is a simple 5-step process:

1. Find a site that is a webhook producer. Webhook producers, such as Github or PingOne, produce notifications based on some event and send them to an external endpoint.
2. Find a third-party site that supports consuming webhooks. These sites provide an endpoint that will accept notifications from the webhook producer.
3. Obtain the webhook URL. The third-party site or app should give you a URL. Copy it!
4. Pass that URL to the webhook provider. Paste the URL into the URL spot of your webhook provider (such as Ping Identity) so they know where to send the notification.
5. Watch what happens. Now, you can test out the webhook by triggering whatever event you’re watching and see the notification get passed to your app.

And that’s the basics of webhooks! You can check them out for yourself when you sign up for a PingOne free trial.