Webhooks are a more efficient way for your app to consume data than polling, producing less server load and staying more up to date for better API integration.
The concept of polling is very simple: send a request for new events (specifically Create, Retrieve, and Delete events which signal changes in data) at a predetermined frequency and wait for the endpoint to respond. If the endpoint doesn’ t respond, there are no new events to share.
Similar to polling, webhooks provide your application with a way of consuming new event data from an endpoint. However, instead of sending repeated requests for new events, you provide the endpoint with a URL, usually within the endpoint UI, which your application monitors. Whenever a new event occurs within the endpoint app, it posts the event data to your specified URL, updating your application in real-time.
When using polling, the frequency of your polls limits how up-to-date your event data is. For example, if your polling frequency is every 12 hours, the events returned by any poll could have happened any time in the past 12 hours. This means that any time an event occurs in the endpoint, your app will be out-of-date until the next poll.
With webhooks, this problem is eliminated. Since events are posted immediately to your monitored URL, your apps will automatically update themselves with the new data almost instantly.
When over 160 developers were surveyed, 82% responded that they preferred webhooks over polling. Why? Beyond all of the advantages we’ ve already discussed, webhooks are much easier to implement and maintain. For most endpoints, there is a UI tool for setting up webhooks, so coding is only required to define what event data should be transferred.
As an example let’s compare the code needed to create a webhook to the code needed for a polling framework in Marketo:
That’s a lot of code! Within our polling framework, we are making GET requests to the endpoint at a certain time interval. We define how far back in time to look for changes, iterate through all of our lead data, and separate out leads associated with activities that occurred within our timespan. The more often we poll, the shorter the time period we have to loop through.
Theoretically, the framework should work the same way for every poll, but it’s likely that it will need to be changed with future versioning of the endpoint.
Now let’s see what we need for a webhook:
That’s it! Just provide a URL, specify a payload, and the rest is taken care of with a few clicks in the Marketo UI. In this example, Marketo posts an event to the URL anytime a lead visits a certain domain. The user’s instance of Slack monitors the domain and posts the lead’s name, company, and email address in one of its channels. Because the process is handled by the endpoint API, it is less likely that the webhook will break in future versions, unless the existing object names are altered, which is unlikely.
As the proliferation of the API economy continues, expect to see many more APIs begin to support webhooks. To stay ahead of the curve, check out the State of API Integration Report which goes into greater depth on the advantages of webhooks as well as which APIs support them.
