Webhook or API Polling: What Is the Difference?

There are two ways for one app to learn what happened in another. It can ask, or it can be told. Asking is called polling. Being told is a webhook.

Polling: you keep asking

Polling means calling an API at intervals to see if data is available¹. An API is the set of requests an app accepts from other software. A polling setup sends one question again and again. Any new orders?

Most answers are "no." A few are "yes." Between checks, a new order can sit unseen until the next question goes out.

You've probably met polling without the name. A refresh button is polling done by hand. A tool that checks on a timer is polling on a schedule.

Webhooks: the app tells you

With a webhook, the app speaks first. When the event happens, it sends a web request to the address you set up². Stripe calls this pushing live data to the endpoint³.

You set this up once. Then you wait for messages that only arrive when there's something to report.

Side by side

GitHub's documentation lists the claimed advantages of webhooks over its API. They require less effort and fewer resources than polling an API, and they allow near real-time updates¹.

It adds a point about scale. If you monitor many resources, calling the API for each one may hit your API rate limit quota quickly. With webhooks you subscribe to several events and receive information only when one happens¹. A rate limit is a cap on how many requests an app lets you make in a set time.

When polling still fits

Webhooks aren't always the better choice. The same GitHub page makes this point. Say you need information only once in a while, or from a small set of resources with no plans to grow. Then you can call the API when you need it¹.

Polling also suits an app that offers no webhooks. Check the maker's documentation for a list of events before you plan around one.

Using both

Some setups use both. A webhook announces that something changed, and the receiver then asks the API for the full record. Stripe describes this in its own guidance, which says you can use the API to retrieve any missing objects³.

How to tell which one an app uses

1. Look in the app's settings for "webhooks," "event subscriptions" or "notifications to a URL."
2. If you find one, the app can push. You'll be asked for a URL.
3. If you only find "sync every so often" or "refresh," the app likely polls.
4. Read the maker's documentation to confirm. Menu names vary from app to app.

A webhook still has weak points. Messages can fail on the way, so the receiver has to cope with that. Retry rules are covered under missed messages. The contents of a message are laid out in the anatomy of a request.