Polling

Polling is calling an API on a schedule to see whether anything changed. It is the default pattern for watching anything, and it used to be almost free.

Under per-resource pricing it is the single largest cost in most integrations, and the arithmetic is worth doing before the loop is written.

What changed

Request-based tiers charged you once per call, however much came back. Per-resource pricing charges per item returned. A search that comes back with 100 posts is 100 charges, not one.

one search returning 100 posts, hourly, for a month
  = 100 × 24 × 30 = 72,000 charged resources

At half a cent per post that is $360 a month — for one keyword, one query, refreshed hourly. We worked the whole pricing sheet out in the post on X's 2026 pricing.

The two things that cut it

1. Re-read known items; discover sparingly. Some providers only charge once per resource per 24 hours, so re-reading a set you already have is near-free while finding new items is not. That inverts the usual instinct: cache the identifiers you are watching, not the payloads, because the identifier list is what lets you re-read cheaply instead of re-searching.

2. Poll at the cadence of the data, not of your curiosity. A follower count that moves a few times a day does not need a check every minute. Matching the interval to how fast the number actually changes is usually a bigger saving than any optimisation in code.

Polling against webhooks

Most public social data has no webhook available at all, so polling is not a choice. What is a choice is how often, and against what.

The alternative nobody prices

If the question is "is this growing", polling a live API is the expensive way to build a time series you could have read from an archive that already has it. One query against stored history against thousands of charged reads is not a close comparison — and it is why the archive exists as a separate product rather than a feature of the live routes.