Webhooks v.s. Polling | You're Better Than This

By Vivek Ravishankar in GET/technical Posted Jun 15, 2017

The ultimate goal of any API integration is the efficient sharing of data between apps to provide greater value to your users. In order to facilitate this, an integration must provide a method to detect changes, events, that occur in the endpoint application. Currently, two of the most popular event management tools are polling and webhooks.


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.

Zendesk API Webhooks

Similar to polling, webhooks provide your application 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.

Be Nice… to Your Servers

While polling and webhooks both accomplish the same task, webhooks are far more efficient. Zapier found that over 98.5% of polls are wasted. In contrast, webhooks only transfer data when there is new data to send, making them 100% efficient. That means that polling creates, on average, 66x more server load than webhooks. That’s a lot of wasted time, and if you’re paying per API call, a whole lot of wasted money.

You're better than this - API Polling and Webhooks

Data is Always Old (Unless You Use Webhooks)

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.

webhook vs polling timeline

Developers Know Best

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: 

Source: 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:

Source: Marketo

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. Stay ahead of the technical trends with our Definitive Guide to API Integration.

Grab your copy