Why Every API Needs Webhooks


Posted on

hookThe Web got its name because the links between pages look like what a spider produces. Over the last several years the Web has become even more interconnected due to APIs. Functionality and data from one site can be used within another site. As these applications have become more complex, they’ve required real-time streams of information. Most APIs simply provide a response when a developer supplies a request. That model does not meet all the needs of today’s apps. Webhooks flip the model and most APIs have a real-time use case that would benefit from a more proactive approach.

A webhook lets a developer provide a URL to which an API will send data. For example, Twilio uses a webhook to send inbound SMS details so an application can react to the text message in some way. Our own SendGrid Parse API similarly sends the pieces of an email (including attachments) for use in customer service tools, intelligent responders or many fun applications. SMS and email are examples well-positioned for real-time use cases. Outside of communications, webhooks are also useful.

Zapier zaps

Just browse the IFTTT recipes or Zapier Zaps. Both services allow anyone to connect APIs together based on something happening. If you’re tagged in a Facebook photo, for example, perhaps you want to save that photo to Dropbox. For either of these services to perform that action, they first need to check Facebook for new tagged photos. If you don’t get tagged very often, they end up polling the Facebook API many times as they wait for that rare tag. A webhook from Facebook could proactively send information about a new tagged photo only when there’s a new tag.

Weather API Metwit recently added webhooks for monitoring precipitation. Applications can let Metwit know the locations where they want to know about precipitation. Should it start raining, snowing, or otherwise precipitating at a location you request, you’ll get the details pushed to your callback URL. Weather data is popular with developers, but usually you need to ask to receive the conditions or forecast. Metwit sends them to you.

Wherever data is added or updated in an API is a good opportunity for a webhook. Software-as-a-service applications often have APIs to help customers integrate into business systems. Webhooks make that integration instantaneous. Since integrations may make a customer three times more likely to pay for a product, it makes sense to grease the wheels to get apps the data they need.

SendGrid has a couple different webhooks. The Parse API was mentioned above, but perhaps the more powerful webhook is the Event API. Your application can receive information about bounces, clicks, unsubscribes and a bunch of other events.

Webhooks aren’t the only way to enable real-time interactions with APIs. There are streaming solutions with persistent connections, PubSubHubBub and XMPP. But most APIs don’t have any alternative to polling for changes. Webhooks are the simplest way to get apps just the information they need when they need it. And more APIs need to provide this ready access to data, because every API and its users could benefit from being more real-time.

Photo by Steven Taschuk


Adam DuVander speaks fluent "developer" while serving as Developer Communications Director. He helps SendGrid connect to coders of all stripes. Previously Adam wrote for Wired, Webmonkey and edited ProgrammableWeb, the leading resource for APIs.

One thought on “Why Every API Needs Webhooks

  1. Great article :) I wouldn't oppose PubSubHubbub and Webhooks though, as PubSubHubbub is just a webhook system with a "verification of intent" (so that you don't need to create user account to enter you hook information). We (http://superfeedr.com) have been working hard on the latest PubSubHubbub v0.4 spec to simplify it!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>