"Twitter API pricing" and "X API pricing" are the same question with two brand names. Teams search it when a monitoring cron, creator scorecard, or research agent needs public profiles and posts. Then they land in X's developer console, which prices first-party access for a bigger product than "pull this handle."

Use the official X API when you need posting, OAuth-on-behalf-of, elevated first-party products, or a contract that must say "X." Use Social Fetch when you need public profiles, tweets, replies, search, communities, or transcripts without an X developer app. Prepaid credits, same envelope as TikTok and Instagram, charge only on completed lookups (not on our infrastructure failures). Confirm live X rates in the developer console; packaging has moved more than once.

Which path fits your job

If your ticket says "Twitter API" but the acceptance criteria are "confirm the handle exists and store follower count," you are not buying write scopes. You are buying a profile GET.

What "Twitter API pricing" usually means

Three different products get collapsed into one phrase:

1. Official X developer products: apps, scopes, rate limits, and whatever credit model X is selling this quarter. Source of truth: developer.x.com (pricing lives in the console and X's docs; it changes).
2. Public enrichment APIs: third-party REST for publicly visible profiles and posts. No X developer app. You pay the vendor's credit or unit meter.
3. Scrapers and Actors: run-based or browser automation. Useful for custom fields; a different ops and compliance model than sync REST.

Mixing (1) and (2) is how budgets blow up. Official access is priced for X's product surface (writes and elevated reads). Public enrichment is priced for "lookup this URL / handle and return JSON."

If someone on your team still asks whether X has an API at all, see Does Twitter (X) have an API?.

Why official X pricing hurts enrichment jobs

A few structural reasons show up in almost every evaluation, regardless of the exact dollars on X's page today.

Official products assume apps, review, and scopes. That overhead is correct when you post as users. It is dead weight when you only enrich public handles.

Packaging moves. X shifted from free allowances and fixed monthly tiers toward pay-per-use credits for new signups. Legacy plan names still float around in old blog posts and RFPs. Treat third-party "Basic is $X" screenshots as history until you confirm in the developer console.

Search and read volume dominate enrichment bills. Brand monitors and research crons care about keyword search and profile reads. On X's pay-per-use meter, reads often bill per resource returned: a search that returns 20 posts can be 20 post reads, not one API call. Pay-per-use also carries a post-read cap (commonly cited at 2 million reads per month before Enterprise). That is exactly where official math hurts first, and where a public-data alternative is easiest to justify.

Multi-platform tax. If Instagram and TikTok already live on one vendor key, adding a separate X developer stack means a second auth model, a second error shape, and a second invoice, even when the product only needed a public bio.

The official API is aimed at a different buyer than a profile-card cron. That is a meter mismatch, not a quality judgment.

Social Fetch credit math for public X data

Social Fetch exposes public X data under /v1/twitter/...: profile by handle, profile tweets, tweet detail, replies, tweet transcript, keyword search, hashtag search, community detail, and community tweets. Same { data, meta } envelope as the rest of the catalog. Same x-api-key.

Billing rules (from our pricing page and the Twitter API reference, not invented for this post):

New accounts get 100 free credits, no card. Pay-as-you-go packs do not expire. Starter is $14 for 1,000 credits; larger packs are on pricing.

Most Twitter routes cost 1 credit per completed lookup (profile GET, single tweet, transcript, community routes). Search, hashtag search, profile tweet pages, and reply pages are documented at 2 credits. Check the credit badge on each operation before you model a cron.

Charge on completed lookups. Trust meta.creditsCharged on every response. Validation errors and our infrastructure failures (lookup_failed, 503 temporarily_unavailable) do not debit. A completed not_found still ran upstream and can bill.

No required subscription for PAYG. Optional monthly plans if volume is steady. No enforced RPS cap on paid metered routes; your limit is credit balance.

You do not get posting, DMs, or X's elevated first-party products. Those belong on X's API.

Full route list: X (Twitter) platform hub. Search filters and pagination: Twitter search API. Vendor shortlist: Best Twitter/X data APIs in 2026.

Rough cost shape (not a fake rate card)

Do not paste a third-party blog's X dollar table into your spreadsheet and call it current. Open X's developer pricing (or the console) and read what they charge for the endpoints you will call.

For new pay-per-use signups in 2026, X commonly bills per resource fetched (for example, post reads around $0.005 each and user reads around $0.010 each). Writes and URL-bearing posts cost more. Rates and caps change. The console is the source of truth.

For Social Fetch, model from known pack math:

If half your calls are search or paginated tweet/reply pages, multiply by the documented 2-credit cost before you compare vendors. Empty result pages can still complete a lookup. Budget for that, or cache known-good queries.

Side-by-side with sync peers who also cover X: Social Fetch vs EnsembleData (daily unit resets) and Social Fetch vs SociaVault (PAYG peer). Marketplace discovery path: vs RapidAPI.

When to stay on the official X API

Stay (or go) official when any of these are true:

• You need write paths (post, reply, like, follow) or member OAuth
• Procurement or counsel requires X-signed access and compliance products
• You need elevated first-party surfaces that third parties cannot honestly sell
• Your product is X-native and the official meter already fits the P&L

In those cases, Social Fetch is a complement for public enrichment elsewhere in the stack. It is not a substitute for X's write API.

Alternatives worth comparing

Frequently asked questions

How much does the Twitter / X API cost in 2026?

Official prices live on X's developer site and console; they have changed more than once. New signups in 2026 typically land on pay-per-use credits, not the old fixed Basic / Pro tiers. Do not trust a screenshot from an old tier post without checking current packaging. For public enrichment on Social Fetch, start from pricing: 100 free credits, packs from $14 / 1k, search and other heavier Twitter routes at 2 credits per completed lookup.

Is there a free Twitter API?

X's free and low tiers have been restricted or reworked over time. Treat "free" as whatever X documents today, not as unlimited production search. Social Fetch gives 100 free credits with no card. That is enough to verify a profile GET and a search call, not a substitute for free infinite reads.

Twitter API vs X API: different prices?

Same platform. "Twitter API pricing" and "X API pricing" refer to the same official products under the rebrand. Public-data alternatives are a separate category.

Do I pay when a handle is missing on Social Fetch?

A completed lookup that returns not_found can charge. The upstream ran. You are not charged for lookup_failed or 503 temporarily_unavailable. Details: pricing billing FAQ and meta.creditsCharged on every response.

Where do I compare vendors without rebuilding a spreadsheet?

Start with Best Twitter/X data APIs in 2026, then the compare pages for EnsembleData, SociaVault, Apify, and RapidAPI.

Smoke-test a profile or search in the playground, or start with 100 free credits on pricing. Route docs and examples: X (Twitter) hub.