X (Twitter) API alternative: Social Fetch vs the official X API

In March 2023 Twitter replaced its free v1.1 and v2 access with three tiers: a Free tier that mostly allowed posting (1,500 posts a month), Basic at $100 a month with 10,000 read requests, and Enterprise. A $5,000-a-month Pro tier followed in May 2023 with 1 million post reads and full-archive search. For three years, reading public data at any real volume meant a fixed monthly bill with a hard read quota.

In February 2026 X launched pay-per-use credits and limited free access to apps it classifies as Public Utility Apps; recently active Free users got a one-time $10 voucher. Legacy Basic plans started moving to pay-per-use after June 1, 2026, and legacy Pro plans after September 1, 2026, each at the end of the subscriber's billing cycle. So if you are reading a 2024 blog post that quotes Basic or Pro limits, it no longer describes what you can buy.

For the full pricing breakdown, see X API pricing: official vs public data. This page is about choosing between the two.

X charges for what comes back, not for the call. Recent search returns up to 100 posts per request, and each one is a $0.005 post read. Looking up users costs $0.010 each. Reads of your own account's data are cheaper at $0.001, and the same resource requested twice in one UTC day is only charged once, which helps if you poll the same accounts repeatedly.

For a brand monitor pulling 2,000 new posts a day, that is about 60,000 post reads a month: roughly $300 on X. Through GET /v1/twitter/search, the same posts arrive in pages of up to 20, so at least 3,000 requests: about $5 at the Scale pack rate. Overlapping polls and short pages add requests, so budget some headroom, but the order of magnitude holds.

Pay-per-use is also capped at 3 million post reads per monthly billing cycle. Past that, X's answer is an Enterprise plan. On Social Fetch the only ceiling is your credit balance, with guidance of about ~500 concurrent requests.

If your product posts, replies, likes, follows, or sends DMs, you need X's API. Social Fetch is read-only and never acts as a user. The same goes for OAuth on behalf of your users, impression and click metrics for your own posts, the real-time filtered stream, and the X Activity API, which pushes a user's new posts to your webhook with sub-second latency (each event billed as a post read). Social Fetch Monitors poll on a schedule, at best once a minute.

X also documents full-archive search back to 2006 for pay-per-use and Enterprise customers. Social Fetch search accepts X operators such as from: and since:, but we don't document a guaranteed archive depth, so test historical queries in the playground before you rely on them.

Then there is the licence. X's API comes with the Developer Agreement and Policy, a contract with the platform that owns the data. If procurement, counsel, or a customer contract needs that, the official API is the only honest answer.

X's Terms of Service prohibit crawling or scraping the service without X's prior written consent. Social Fetch returns publicly visible X data; it is not an X partner product and cannot pass you X's data licence. Whether reading public data through a third party fits your use case depends on your jurisdiction, what you collect, and what you do with it. This is not legal advice; read X's terms and talk to counsel if you are collecting at scale.

What Social Fetch does take off your plate: no developer account, no app review, no per-post meter, and no scraper to maintain when X changes its front end. For the wider trade-off, see Social Fetch vs DIY scraping.

Profiles by handle or ID (GET /v1/twitter/profiles/{handle}), profile timelines (/v1/twitter/profiles/{handle}/tweets), keyword and hashtag search (/v1/twitter/search, /v1/twitter/hashtags), single posts, replies, quotes and reposts (/v1/twitter/tweets, /v1/twitter/tweets/replies), follower and following pages, lists, communities, Spaces, and video transcripts. Each route costs 1 credit per completed request. A not_found still counts as a completed lookup; lookup_failed and 503 temporarily_unavailable are not billed. Read meta.creditsCharged on every response.

For "tell me when this account posts", Monitors poll /v1/twitter/profiles/{handle}/tweets on your schedule and send a signed webhook with the new posts, billed at the route's normal price. Full route list: X (Twitter) platform hub. Parameters and response schemas: API reference.

Most read integrations map one-to-one. GET /2/users/by/username/:username becomes GET /v1/twitter/profiles/{handle}. GET /2/users/:id/tweets becomes /v1/twitter/profiles/{handle}/tweets, with no need to resolve the handle to an ID first. GET /2/tweets/search/recent becomes /v1/twitter/search, with the same style of operators in query (the advanced search builder compiles them for you).

Field names differ, so plan an afternoon of mapping and a test run. Keep anything that writes on X's API. A common setup is hybrid: X's API for posting and account actions, Social Fetch for public reads across X and the 23 platforms on one key.

X's pay-per-use API is the only option if you post, act for users, need private metrics, or need a contract with X. For read-only work, the deciding number is posts per call: X charges $0.005 for every post returned, Social Fetch charges one credit per request. Single profile lookups are close (and cheaper on X than on a small Starter pack); timelines and search are much cheaper on Social Fetch. Many teams run both: X for writes, Social Fetch for public reads.