Twitter (X) Developer API — Getting Started in 2026
The Twitter (X) developer API is the single biggest data source for anyone building products around social conversation — sentiment analytics, cashtag trackers, brand monitoring, election research, competitor intel. In 2026 the landscape has consolidated to two practical entry points: X's own developer.x.com platform (post-2022 restructure) and third-party gateways that resell the same underlying data at per-call pricing.
This getting-started walks the current 2026 landscape end-to-end — what each tier costs, what auth setup looks like, what endpoint families exist, and how to pick the right path for your workflow. Concrete code, real cost math.
The 2026 landscape — 2 practical paths
Path A — X official (developer.x.com): X's own API platform. 4 tier grid: Free (write-only, essentially demo), Basic ($200/mo, small read/write), Pro ($5,000/mo, mid-scale), Enterprise (custom contracts from ~$42,000/mo per docs.x.com/x-api/enterprise/getting-started).
Path B — twitterapi.io (third-party gateway): pay-per-use gateway on top of X's public data. $0.00015 per returned tweet, $0.00018 per profile lookup per twitterapi.io/pricing. No tier gate; signup + API-key.
Why not others? Historical scraper-based paths (Apify, Bright Data, DIY Playwright) still exist but sit in a browser-automation gray zone with breakability + ToS ambiguity. For 90%+ of new-build workflows in 2026, Path A or Path B is the answer.
Path A — X official 4-tier grid
Free — 500 posts/month write, 100 reads/month app-level. Not a viable production tier; positioned for testing + light write bots.
Basic ($200/month) — 50K posts/month write, 15K reads/month app-level. Recent-search only (~7-day window). Reasonable for hobbyist / prototype work.
Pro ($5,000/month) — 300K posts/month write, 1M reads/month app-level. Still recent-search only for reads. Suitable for small-scale production apps.
Enterprise — Custom contract, typically $42,000+/month with per-post surcharges. Full-Archive Search (2006-present), DataStream (real-time firehose), account-manager relationship. Only tier with truly historical read access.
All tier pricing per docs.x.com/x-api/getting-started/pricing (verified 2026). Rate limits per docs.x.com/x-api/rate-limits.
Path B — twitterapi.io pay-per-use
Pay-per-tweet / per-profile pricing per twitterapi.io/pricing. No monthly minimum, no tier ceiling on volume. Historical archive (2006-present) available on standard endpoints without Enterprise contract.
Practical use case: 10K tweets/day workload = ~$45/month on twitterapi.io vs $200/month X Basic (and Basic caps at ~500/day reads). For any read-heavy workflow above small-scale, twitterapi.io economics dominate.
Write operations (post tweet, follow, etc.) are supported via session-cookie auth — good for automation workflows; less clean for native-X-app integrations where you want X-issued OAuth tokens.
First-call bootstrap comparison
X official first call (~30 min):
1. developer.x.com → Sign up + apply for a tier
2. Create a Project + App inside the Developer Portal
3. Generate API Key + Secret + Bearer Token in the app settings
4. (For write ops) Configure OAuth 2.0 callback + tweet.read / tweet.write scopes
5. Install tweepy or use raw requests with Bearer header
twitterapi.io first call (~5 min):
1. twitterapi.io → Sign up (Google OAuth or email)
2. Copy API key from dashboard
3. curl -H 'X-API-Key: ...' — done
# First call comparison — same intent (search recent tweets), 2 auth patterns
import os, requests
# ---- twitterapi.io ----
HEADERS = {"X-API-Key": os.environ["TWITTERAPI_IO_KEY"]}
r = requests.get(
"https://api.twitterapi.io/twitter/tweet/advanced_search",
headers=HEADERS,
params={"query": "openai lang:en min_faves:10"},
timeout=15,
)
print(f"twitterapi.io returned {len(r.json().get('tweets', []))} tweets")
# ---- X official (via tweepy) ----
import tweepy
client = tweepy.Client(bearer_token=os.environ["X_BEARER_TOKEN"])
resp = client.search_recent_tweets(query="openai lang:en min_faves:10", max_results=100)
print(f"X official returned {len(resp.data or [])} tweets")
# Cost per call:
# twitterapi.io: N × $0.00015 per twitterapi.io/pricing
# X official Basic: N × $0.005 per docs.x.com/x-api/getting-started/pricingEndpoint families you'll actually use
Search (/twitter/tweet/advanced_search on twitterapi.io, /2/tweets/search/recent on X official) — the workhorse for most workflows. Full search-operator grammar. See /blog/twitter-search-operators-api-guide-2026 for operator reference.
User lookup (/twitter/user/info / /2/users/by/username) — resolve handle → profile + metrics. See /blog/twitter-username-lookup-api-reference.
Followers / following (/twitter/user/followers, /twitter/user/followings / /2/users/:id/followers) — social-graph enumeration. Cursor-paginated. See /blog/twitter-export-following-list-api-tutorial.
Timeline — recent tweets by a specific account. Handled via search with from:@handle.
Streaming (twitterapi.io + X official Enterprise) — real-time push of new tweets. See /blog/twitter-streaming-api-real-time-guide.
Write ops (create tweet, retweet, follow, etc.) — POST endpoints with user-context auth. See /blog/twitter-automation-2026 for patterns.
Cost math at 4 workload sizes
Per-tweet cost only. Ignore per-request overhead + free-tier rate-limit ceilings.
Two takeaways: (a) twitterapi.io economics dominate for read-heavy at every workload size; (b) if your workflow is <50K reads/mo AND you need X-native OAuth for write ops, X Basic is still viable — pick based on read-vs-write mix.
When to pick which path
Pick X official when: (a) native X OAuth token needed (in-app 'Sign in with X' flows, first-party integrations); (b) write operations are >30% of your workload; (c) Enterprise data compliance (regulated industries, election-integrity research); (d) already on Enterprise for other X-side workloads.
Pick twitterapi.io when: (a) read-heavy workload at any scale above hobby-tier; (b) historical archive access needed without Enterprise procurement; (c) want session-cookie / API-key simplicity for automation; (d) cost-sensitive at production scale.
Hybrid works too: use twitterapi.io for read-heavy analytics + X official for the small write-op surface. Both API keys in your .env, route reads to one + writes to the other.
# Production-grade first workflow: sentiment analytics + cost tracking, both paths.
import os, requests, csv
from pathlib import Path
from datetime import date
HEADERS = {"X-API-Key": os.environ["TWITTERAPI_IO_KEY"]}
BASE = "https://api.twitterapi.io"
BRAND = "stripe"
COMPETITORS = ["paypal", "square"]
EXCLUDES = " ".join(f"-{c}" for c in COMPETITORS)
query = f"{BRAND} {EXCLUDES} lang:en min_faves:5 -filter:retweets"
tweets, cursor = [], None
for _ in range(10):
params = {"query": query}
if cursor: params["cursor"] = cursor
r = requests.get(f"{BASE}/twitter/tweet/advanced_search", headers=HEADERS, params=params, timeout=15)
r.raise_for_status()
resp = r.json()
tweets.extend(resp.get("tweets", []))
cursor = resp.get("next_cursor")
if not cursor: break
print(f"{BRAND} signal-only tweets: {len(tweets):,}")
print(f"Cost per twitterapi.io/pricing: {len(tweets)} × $0.00015 = ${len(tweets) * 0.00015:.4f}")
# Persist for downstream sentiment analysis
out = Path(f"{BRAND}_signal_{date.today()}.csv")
with open(out, "w") as f:
w = csv.writer(f)
w.writerow(["id", "author", "followers_count", "created_at", "favorite_count", "retweet_count", "text"])
for t in tweets:
a = t.get("author", {})
w.writerow([
t.get("id"), a.get("userName"), a.get("followers_count", 0),
t.get("created_at"), t.get("favorite_count", 0), t.get("retweet_count", 0),
(t.get("text") or "").replace("\n", " ")[:280],
])
print(f"saved {out}")
# Next steps: pipe text column through your sentiment classifier (LLM, VADER, transformers)Questions readers ask
Is the free tier of X's API usable for anything?
Barely. Free tier is 500 posts/month write + 100 reads/month app-level — enough to demo an app or run a light bot. Any production workload needs Basic ($200/mo minimum) or twitterapi.io pay-per-use.
Can I use OAuth with twitterapi.io for write ops?
twitterapi.io uses session-cookie auth for write operations (login flow → cookie → POST endpoints). Not X-issued OAuth. If you specifically need X-issued OAuth tokens (for in-app 'Sign in with X' flows), you need X official Basic tier or above.
How long is the historical archive on twitterapi.io?
Back to Twitter's launch (March 2006). Full archive. Query via since: and until: operators on /twitter/tweet/advanced_search. See /blog/twitter-historical-data-archive-api-guide.
Can I try before I buy on twitterapi.io?
Yes — new signups get trial credits sufficient for ~1000 tweet reads to test integration end-to-end before adding a payment method.
Does twitterapi.io throttle at the same rate as X's official rate-limits?
twitterapi.io has its own per-key throughput ceiling (comfortable for thousands of requests/hour on typical accounts). Not the same as X's per-user rate-limit heuristics. Practically: harder to hit than X official Basic-tier limits.
What about X Basic's 'Sensitive/Elevated' access — is that still a thing?
Post-2022 X restructure removed the old Elevated tier gating. Current tiers (Free/Basic/Pro/Enterprise) don't have per-endpoint elevation. All endpoints available at each tier are enabled by default.
Any GDPR / data-sovereignty concern with third-party gateway?
For public tweet data, both twitterapi.io + X official process the same categories. For workflows involving private DMs or user-consented data, use X official OAuth 2.0 with proper scope declaration for GDPR/compliance clarity.
Continue
- twitterapi.io — pricing
- X API — pricing (docs.x.com, 2026 verified)
- X — rate limits reference
- X — authentication (OAuth 2.0)
- Twitter (X) API — cluster hub
- Twitter (X) API pricing breakdown
- TwitterAPI.io vs official X API
- Twitter (X) search operators API reference
- Twitter (X) scraping developer guide
- twitterapi.io pricing
Stop reading. Start building.
Starter credits cover real testing on real data. Google sign-in, no card, no application queue.
Get an API key