An Alternative to Building a Twitter/X Listening Tool

X doesn't make you fight anti-bot defenses to pull tweets the way TikTok or Instagram do — it has an official, documented API. That's exactly why building a listening tool against it looks deceptively simple: sign up, get a key, start reading. What's easy to miss until the first invoice is that X switched its default developer pricing to pay-per-use in February 2026, and the economics of "just call the official API yourself" changed with it.

If you're an agent (or building one) reading this rather than a human, the full machine-readable schema for every endpoint below lives at mindcase.co/skills.md.

What does X's own API actually cost now?

As of February 2026, pay-per-use is the default tier for new X API v2 developers: $0.005 per post read, capped at 2 million reads a month. Posting costs separately ($0.015 per post created, $0.20 if it contains a link), which doesn't matter for a listening tool, but the read price does — every tweet your tool pulls for a keyword search or a handle's timeline is a metered read against that cap.

Cross 2 million reads in a month and there's no higher pay-per-use tier to step up to — the next stop is Enterprise, which starts around $42,000 a month. For a listening tool tracking even a modest set of keywords across an active month, that ceiling is closer than it looks: a few thousand mentions a day across a dozen tracked terms adds up fast once you're counting every tweet returned by every search as a billed read.

What does building the integration itself cost, separate from the API bill?

The API being official doesn't mean the client work disappears. A production listening tool still needs:

• OAuth 2.0 app-only auth, token refresh, and the app-review step X requires before a project can pull at any real volume.
• Query construction against X's search operator syntax (from:, min_retweets:, since:, and the rest) — a small DSL to learn and get right, not a plain keyword field.
• Pagination and rate-limit handling tuned to whichever pay-per-use window you're metered against, so a burst of mentions doesn't silently drop results or blow through the monthly read cap faster than expected.
• Response parsing for X's own schema shape, kept in sync whenever the API version changes underneath you.

None of that is exotic engineering, but it's ongoing — the kind of thing that's a day of work to stand up and then shows up again every time X revises a field or a rate limit.

How do you get the same data without the integration work?

Say you're monitoring how often three competitor products get mentioned on X this week, replies and quote-tweets included.

curl -X POST "https://api.mindcase.co/v1/data/twitter/tweets/run?wait=true" \
-H "Authorization: Bearer $MINDCASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "params": {
    "query": "\"acme widget\" OR \"acme pro\" -is:retweet",
    "maxResults": 200
  }
}'

# $0.00025 per tweet

Twitter/X Tweets API takes the same search-operator query syntax X's own API uses, so the query-construction knowledge transfers — you're not learning a second DSL. It returns 35 fields per tweet, including likes, retweets, replies, quotes, and views, so a single call gives you both the mention and the engagement it's getting, without a second lookup. At $0.00025 per tweet, that 200-tweet pull costs $0.05 — 20 times cheaper per unit than X's own $0.005-per-read pay-per-use rate, with no OAuth flow, app review, or query DSL to build first.

When does building your own actually make sense?

One case: X data is a core part of your product, at a volume where an in-house team pulling directly from X's official API — and negotiating Enterprise pricing once you're past 2 million reads a month — genuinely costs less than a metered API bill. That's a small set of teams, and they're usually already past the "listening tool" stage into something closer to a dedicated X data product.

Below that line — tracking a product launch, a handful of competitor mentions, or a keyword list for a weekly report — you're trading a recurring per-tweet cost that never requires app review or a rate-limit rewrite for the ongoing work of maintaining a direct integration against an API whose pricing model itself changed once already this year.

What can't you get from Mindcase?

Two cases.

Posting or replying. This endpoint only reads tweets — there's no write path for posting, replying, or any other action on an account. If the workflow needs to post as part of the loop, that still goes through X's own API and its per-post pricing.

Full-archive historical search. query supports the same search operators X's own recent-search endpoint does, but it's scoped to recent tweets, not the full historical archive. A project needing years of back-history is a different problem than an ongoing listening tool.

Which endpoint should you use for which job?

FAQ