Most explanations of X (Twitter) monitoring tools skip the part that determines everything else: how the data is obtained. X's API is metered, tiered, and repriced often enough that any specific number written down goes stale quickly. The shape of the constraints, though, has been stable for years, and understanding that shape explains why free monitoring fails and why X tooling is thinner than Reddit tooling.
The shape of the constraints
Four limits interact, and a tool has to live inside all of them at once.
A volume cap. How many posts you may retrieve in a billing period. This is the binding constraint for monitoring, because monitoring means repeatedly asking for results whether or not anything new exists.
A request rate limit. How often you may call an endpoint in a short window. This caps how frequently you can poll, which caps your latency.
Endpoint gating by tier. Lower tiers do not merely get less volume; they may not get search endpoints at all. This is the detail that surprises people, and it is why a free key is not a smaller version of a paid key.
A historical window. Standard search endpoints reach back a limited period; deeper history is a separate, more expensive product. Monitoring cares about this less than analytics does, but it matters for backfilling a new query.
As of writing, the specific numbers attached to each of these have changed several times, and any tool or article quoting exact figures should be checked against current documentation.
Why the free tier does not work for monitoring
X's free access level has consistently been oriented toward posting and light testing rather than reading at volume. For monitoring, it fails on two counts independently.
First, search access. Monitoring requires querying for posts matching your terms on an interval. If the free tier does not include a usable search endpoint, no amount of clever engineering produces a monitoring tool from it — the capability is simply absent.
Second, volume arithmetic. Even where reads are permitted, a monitoring setup consumes them relentlessly. Consider twenty queries polled every fifteen minutes: that is roughly 1,900 requests a day before you have found a single relevant post, and the requests that return nothing cost the same as the ones that return a lead. Free allowances are not sized for that pattern, and the pattern is not optional — you cannot know a query matched nothing without asking.
The polling arithmetic every tool faces
The core trade-off is between latency, query count, and cost, and improving any one worsens another.
| Polling interval | Worst-case latency | Relative consumption | Fit for lead generation |
|---|---|---|---|
| Every 5 minutes | 5 minutes | Very high | Excellent |
| Every 15 minutes | 15 minutes | High | Good |
| Hourly | 1 hour | Moderate | Marginal |
| Every 6 hours | 6 hours | Low | Too late to reply usefully |
| Daily | 24 hours | Minimal | Archival only |
Recall the timing rule from our 2026 playbook: a reply inside the first hour is likely to be read, and a reply after a day is read by nobody. That places the usable band for lead generation at hourly or better, which places a hard floor under what the capability costs to provide.
What this means for the tools you can buy
X monitoring is structurally more expensive than Reddit monitoring. This is the main reason the Reddit tooling market is crowded and the X market is not, and it is why a competitor covering only Reddit is making a cost decision rather than a product decision.
Free X monitors are doing something else. Polling rarely, covering few queries, sampling, or using access methods outside the official API. The last of these is the least stable — scraping-based tools break without warning when the platform changes, and they break at the worst possible moment.
Per-keyword pricing exists for a real reason. Each additional tracked query multiplies request consumption. Vendors charging per keyword are passing through an actual marginal cost rather than inventing a pricing axis.
Semantic filtering changes the economics favourably. Retrieval costs are fixed by the polling schedule, but the human cost of reading results is not. Scoring matches with a model means the same retrieval budget produces a queue of five worth reading instead of a feed of two hundred.
If you are considering building it yourself
A reasonable thing to evaluate, and the sums are worth doing before you start.
Budget for the API tier that actually includes search at your polling frequency, not the cheapest tier that technically has a key. Then add the parts people forget: deduplication across overlapping queries, backoff and retry handling when rate limits hit, storage so you can tell new posts from ones you already saw, a review interface, and the semantic filtering layer without which you have built a firehose.
The retrieval is a weekend. The deduplication, the state management, and the filtering are the actual product, and they are where the maintenance lives. If you are monitoring one or two keywords for a side project, building is sensible. If you need twenty queries with hourly latency and want to spend your time replying rather than maintaining a pipeline, it usually is not.
Questions to ask a vendor
What is your polling interval per query? This is the latency answer, and any vendor unwilling to give a number is giving you one.
Is coverage complete or sampled? Sampling is fatal for low-volume intent queries and harmless for brand volume tracking.
Do you use the official API? Scraping-based tools are cheaper and break, and they break silently, which is worse than breaking loudly.
What happens when I add a keyword? Whether the polling budget is split across queries or scales with them tells you what the twentieth keyword will actually get you.
How do you handle rate limiting? Whether the answer involves backoff and queueing or just dropping results determines what you silently miss.
FREQUENTLY ASKED QUESTIONS
Questions about X API limits
Can I monitor X keywords using the free API tier?
In practice, no. Free access has been oriented toward posting and light testing rather than reading at volume, and monitoring consumes read requests continuously whether or not anything matches. Check current documentation, since tiers change.
Why is X monitoring more expensive than Reddit monitoring?
Data access terms differ. X meters reads and gates search endpoints by tier, so the cost of continuous polling is substantial and unavoidable. That cost difference is why far fewer tools cover X.
How often do monitoring tools actually poll?
It varies widely and is rarely disclosed. Ask directly, because polling interval determines worst-case latency, and for lead generation anything slower than roughly hourly means arriving after the conversation ended.
Is scraping X a viable alternative to the API?
It is cheaper and structurally fragile. Scraping-based tools break when the platform changes, often silently, and they may conflict with the platform's terms. For anything you depend on, official access is the safer basis.
LATENCY IS THE PRODUCT
Coverage you can rely on, on a schedule that still lets you reply.
MentionSpot monitors X and Reddit continuously and scores every match for buying intent, so the retrieval budget turns into a short queue rather than a long feed.
Get the 7-day pass