Modernize your API with webhooks

Don't be intimidated by webhooks. They are essentially the equivalent of “don't call us, we'll call you,” for the automated web. In the old days, if you wanted to act on changes to databases, websites, APIs, or online accounts, you would need to write a polling routine. Now, developers have a smarter option.

Why use webhooks versus polling? Polling involves writing an algorithm that checks the status of an endpoint for changes. Polling used to be the primary method for change notification at higher levels, but it’s not very efficient. Still, for low-level devices like printers, polling is your only option.

A study by Zapier found that 98.5 percent of polls were wasted because they nearly always brought back empty event data or polling messages. Meanwhile they soaked up system resources and had a tendency to swamp the I/O of the endpoint when polling intervals were set too close together.

Webhooks were introduced nearly a decade ago as a way to free up those resources. Webhooks send back notifications only when there are changes at the endpoint. Around 80 percent of developers surveyed preferred using webhooks over polling, but websites or APIs don’t support webhooks automatically.

When you expose your APIs to webhooks, it opens up a pathway for tighter, more efficient communications between you and your partners. Webhooks give your clients a good reason to fold your API integrations into their own systems. Before you do this, however, you should know a little more about the structure of webhooks.

The structure of webhooks

GitHub offers a great introduction to creating webhooks and a detailed look at their structure. Essentially, you will configure your own webhook URL to accept outside webhooks sent as HTTP POST requests.

Webhooks are composed of three main components:

• Your payload URL. This is where message payloads will be delivered.
• Content_type. This defines the media type of the response. The application/json content type includes JSON payload directly in the body of the POST. In some cases you may need to use the application/x-www-form-urlencoded to send the JSON payload as a form parameter.
• Events. These are the actions that will trigger a message. You can pull from a list of webhook events in GitHub's webhooks API reference page.

There are more tutorials available at GitHub. Note that developing with webhooks can be difficult if your local environment doesn’t have a public URL. Here are four options to solve that problem.

Best-in-class webhooks

To give you a better sense of their potential value for your business, here are a few real-world examples of great webhook implementations:

• Quickbooks. People care deeply about what happens to their money, and the sooner they know what happened and when the better. That might be why Intuit’s developers identified new webhooks as one of their most requested features. Their webhooks notify apps whenever there is a change to fields like SalesReceipt, BillPayment, or Purchase.
• Facebook. There's a wealth of data that can be pulled from consumer or business accounts on Facebook. Virtually every field on Facebook can send updates for aggregate data collection functions.
• Microsoft Dynamics CRM: Sales and marketing are the two work groups most sensitive to changes at their customers and prospects. Microsoft Dynamics pulls those changes directly into the company CRM for a massive efficiency advantage. Custom workflow activities collect change data and events from integrations with external web services.

Webhooks make APIs more valuable for developers and encourage clients to take a closer look at your services. They can serve as the foundation for an infinitely variable integration platform as a service (iPaaS). Using an iPaaS, you could develop and deploy cloud-based solutions without the need for middleware. Webhooks are great for expanding your market reach while delivering a better user experience in ways you haven't even considered yet.

Mark Geene is CEO and co-founder of Cloud Elements.

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.