Skip to content

Polling

Polling is an integration pattern where one system repeatedly requests another system to check whether information has changed.

Polling is an integration pattern where one system repeatedly requests another system to check whether information has changed.

It is the opposite of waiting for an event-driven notification such as a Webhook.

What It Means in Practice

An integration might run every five minutes:

10:00 → Any new orders?
10:05 → Any new orders?
10:10 → Any new orders?
10:15 → Any new orders?

Most of those requests may return:

Nothing new.

The approach can still be appropriate when the external system does not provide webhooks.

Polling vs. Webhooks

Polling → receiving system asks repeatedly.

**Webhook** → source system sends a notification when something happens.

GitHub's REST API guidance recommends using webhooks rather than polling for events where webhook support exists. GitHub REST API best practices

When Polling Is Useful

Polling can make sense when:

  • No webhook exists
  • Changes do not need to be immediate
  • The external API is simple
  • Data can be checked periodically
  • Scheduled synchronization is acceptable

A weather feed updated hourly, for example, may not need a real-time webhook.

Why It Matters

Polling frequency affects:

Checking every ten seconds for information that changes once per day creates unnecessary work.

Common Problems

Common problems include:

  • Polling much more frequently than necessary
  • Re-downloading the complete dataset every time
  • Ignoring Rate Limits
  • Several jobs polling the same API
  • No record of the last successful synchronization
  • Missing updates because timestamps are interpreted incorrectly
  • Polling used when a webhook already exists

How to Improve

Choose a frequency based on the actual freshness requirement.

Where possible:

  • Request only changed records
  • Store the last successful state
  • Use conditional requests
  • Respect Rate Limits
  • Switch to Webhooks when appropriate