← Blog

How to Use the Twitter (X) API in Python (2026)

By Nikhil Kumar. Last updated September 2026.

You want an account’s tweets in a Python script, you install Tweepy, and then you hit the part nobody warns you about: X’s API has no free tier anymore, and reading costs real money per tweet.

You have four ways to get X data in Python: the official API through Tweepy or plain requests, a dwindling set of free scrapers, your own browser automation, or a third-party data API. The official route works but now costs $5 per 1,000 reads with a 2-million monthly cap and no free tier. The free scrapers mostly died in 2023. For read-only work, a third-party API called from Python is usually the pragmatic choice. This guide walks all four.

Four ways to get Twitter (X) data in Python: official API via Tweepy, free scrapers, DIY browser automation, and a third-party data API.

How do you use the Twitter (X) API in Python?

You authenticate with a bearer token and call the v2 endpoints, almost always through Tweepy. You install tweepy, create a client with your token, resolve a username to an id, and page through that user’s tweets. Plain requests with the same bearer token works too if you would rather not add a dependency. Both hit X’s official API, which means its pricing and rate limits apply to every call you make.

Tweepy is the path of least resistance for the official API.

import tweepy
client = tweepy.Client(bearer_token="YOUR_BEARER_TOKEN")
user = client.get_user(username="nasa")
tweets = client.get_users_tweets(user.data.id, max_results=100)
for t in tweets.data:
print(t.text)

That is the whole read path. The catch is not the code; it is what sits behind the token.

Every one of those calls draws down a paid quota. Tweepy also handles rate-limit waiting for you, which is convenient until you realize the wait is there because the recent-search endpoint allows only 300 requests per 15 minutes. The library is fine. The account behind it is the constraint.

If you skip Tweepy and use plain requests, the shape is the same but you carry more yourself. You put the bearer token in an Authorization header, call the v2 endpoints directly, and page with the next_token cursor by hand. It drops a dependency and adds a little bookkeeping. Either way you first resolve the username to a numeric user id with one call, then fetch that id’s tweets with another, because the timeline endpoint keys on the id, not the handle.

What does the official X API cost in 2026?

As of early 2026 there is no free tier. New developers are on pay-per-use: about $0.005 per tweet read, $0.010 per profile, and $0.015 per post created, capped at 2 million reads a month, with search reaching back only 7 days. The old Basic ($200) and Pro ($5,000) plans are closed to new signups, and full-archive access starts at Enterprise, around $42,000 a month.

The pricing cliff is the whole reason this article exists.

TierCostWhat you get
FreeGoneDiscontinued for reads
Pay-per-use$0.005/read, $0.015/post2M reads/mo cap, 7-day search only
Basic (legacy)$200/moClosed to new signups
Pro (legacy)$5,000/moClosed to new signups
Enterprise~$42,000/mo+Full-archive to 2006, streaming, firehose

Read the middle row twice. Pay-per-use sounds flexible, and for a few thousand reads it is cheap. But the 2-million monthly cap and the 7-day search window mean that the moment your project needs either scale or history, the next step is not a bigger monthly plan, it is a jump to Enterprise and a five-figure invoice.

For context, one analysis put reading 100,000 tweets with profiles at roughly $1,500 a month on the official API. That is the number that sends people looking for another way.

The migration made this concrete. X began auto-moving the remaining legacy Basic subscribers onto pay-per-use on June 1, 2026, so accounts that had budgeted a flat $200 a month suddenly metered every read. If your volume is small and spiky, pay-per-use can beat the old flat fee. If it is large and steady, the 2-million cap turns a predictable bill into a wall you hit mid-month, with Enterprise as the only door past it.

Do the free Python scrapers still work?

Mostly not. snscrape, Twint, and Nitter all broke when X locked out anonymous guest access in 2023, and the Nitter instance network collapsed after. Twikit is the most actively maintained free scraper left, but expect it to break on X’s schedule, not yours. For a one-off academic pull where downtime is fine, a free library still has a place; for anything that has to stay up, it does not.

This is the graveyard most tutorials do not mention.

If you follow a 2022 blog post that tells you to pip install snscrape and pull tweets for free, you will hit a dead library and then, when you fall back to the official API, a rate limit on nearly your first try. That exact path shows up again and again in r/Python threads from 2025 onward.

The reason is structural. X killed the logged-out guest access those tools relied on, so the free-scraper era ended not because the libraries got worse but because the door they used got locked.

Twikit survives by doing more work: it logs in with a real account and mimics the app. That keeps it alive, and it also means you are running an account that X can rate-limit or ban, which is a different risk than a library that quietly stops returning rows.

Building your own scraper instead runs into the same wall from the other side. X binds a guest token to an IP and expires it within hours, rotates the internal query ids its own site uses every two to four weeks, and flags datacenter IPs within a request or two. So a DIY browser scraper means residential proxies, token refresh, and re-reading X’s markup every few weeks, which one guide put at ten to fifteen hours of maintenance a month. That is a part-time job, not a script.

How do you pull tweets in Python without the official API?

Call a third-party data API from Python with an ordinary GET request. It reads public tweets and returns JSON, with no developer account, no OAuth, and no app review. On ScraperSocial you send a handle to /v1/twitter/tweets and get the account’s recent posts back, billed 1 credit per tweet. The setup is one API key in a header, which is why read-only projects reach for it over Tweepy’s OAuth flow.

Here is the same “get a user’s tweets” task, without the developer account.

import requests
r = requests.get(
"https://api.scrapersocial.com/v1/twitter/tweets",
params={"handle": "nasa", "limit": 100},
headers={"Authorization": "Bearer sk_live_..."},
)
for t in r.json()["data"]:
print(t["text"], t["likes"], t["posted_at"])

No token exchange, no user-id lookup step, no OAuth app to register.

Two mechanics matter here. Billing is per tweet returned, so the limit parameter is also your cost dial: ask for 20 when you need 20, not 200 to display 10. And there is no cursor, so a second call re-reads from the top of the timeline rather than continuing deeper, which means this route is built for recent posts on a schedule, not for paging into an account’s distant past.

Be clear on the honest comparison, though. At 1 credit per tweet, this runs about $5 per 1,000 tweets, which is roughly the same per-read price as the official pay-per-use tier. The reason to use it is not that it is dramatically cheaper on raw reads. It is that you skip the developer account, the OAuth dance, the app review, the 2-million monthly cap, and the 7-day search wall.

If raw price per tweet is genuinely all you care about, some bulk providers undercut both, quoting figures like $0.05 to $0.20 per 1,000. The trade there is a narrower, less normalized response and a different vendor to trust. Match the tool to what you actually value: friction, breadth, or the last cent.

What data can you get from a tweet and a profile?

For a tweet you get the text, the engagement counters (views, likes, replies, retweets, quotes, bookmarks), the timestamp, the language, and flags for whether it is a reply or a retweet. For a profile you get the display name, bio, follower and following counts, verification, and post count. What no method reaches without logging in is a protected account, DMs, or a complete follower list.

The fields are enough for most real jobs.

Engagement analysis, competitor feeds, and LLM summarization all run on exactly this shape: text plus counters plus a timestamp. On ScraperSocial the tweets endpoint returns the timeline, the profile endpoint returns the account-level numbers, and the search endpoint takes a query instead of a handle when you want posts by keyword rather than by author.

Two honest caveats live in these fields. View counts are null on posts from before late 2022, because X did not display them then, so treat null as “not published” rather than zero. And the array includes replies and retweets, flagged with is_reply and is_retweet, so filter client-side if you only want original posts.

The profile side answers the other half of most questions. When you want how big an account is rather than what it just said, the profile endpoint returns the follower and following counts, the bio, and the verification flag in one call, without paying per tweet. Pairing the two, profile for size and tweets for recent activity, is how most account-scoring and influencer-vetting workflows are built.

Reading public tweets sits in the same contested space as any public-web collection, and this is not legal advice. A third-party reader sees only what a logged-out visitor sees, which US courts have generally treated more leniently than access behind a login, but you still own compliance for whatever you store. A tweet is someone’s public post, and the handle, name, and text attached to it are personal data under GDPR and CCPA the moment you keep them.

The rule of thumb is the boring one.

Collect only the fields you need, keep a retention window, and drop personal details you are not using. If you are building an aggregate view of a topic, you rarely need to store the author’s identity at all.

X’s own terms discourage automated collection, which is part of why it locked out guest access in the first place. Reading public pages is a well-trodden path, but treat the data as what it is, other people’s public speech, and handle it with the care you would want for your own.

How far back can you go?

Not far, on any affordable route. The official API’s cheap tiers only search the last 7 days; full-archive back to 2006 is Enterprise-only at around $42,000 a month. Third-party readers, ScraperSocial included, see what a logged-out visitor sees on a public profile, which is recent posts, not a deep archive. If you need one specific old tweet, fetch it by its URL; years of history in bulk is genuinely expensive everywhere.

This is the limit people discover last, so name it early in your design.

There is no cheap path to a deep archive of a public account. The official cheap tiers cut you off at 7 days, the free scrapers never reached far back, and a logged-out reader sees only what X shows on a public timeline, which is recent.

So if your project depends on 2019’s tweets, budget for Enterprise or reframe the project. If it depends on what an account has said this month, any of the read routes here handles it. Most projects, honestly, only need recent data and are quietly relieved to learn that is the affordable part.

Which method should you choose?

Match the method to the job. If you are posting tweets or building a compliant bot, use the official API through Tweepy and pay per action. If you are reading public tweets for a dashboard, a feed, or an LLM pipeline, a third-party data API from Python is simpler and has no monthly read cap. If you are a researcher on a zero budget who can tolerate breakage, a free library like Twikit still works, sometimes.

Here is the whole landscape in one view.

MethodSetupCostReliabilityBest for
Official API + TweepyOAuth, dev account$5/1K reads, 2M capHigh, but cappedPosting, compliant bots
Free scraper (Twikit)Log in with an accountFreeBreaks oftenZero-budget research
DIY browser automationPlaywright + proxiesProxy bill + upkeepYou maintain itFull control, custom fields
Third-party data APIOne API key~$5/1K, no capVendor-maintainedRead-only feeds, dashboards

The decision usually comes down to one question: are you writing to X, or reading from it? Writing means the official API, because only it can post. Reading public data means you are free to pick the route with the least friction, and for most Python projects that is a data API call, not an OAuth app.

Pull one account’s tweets

Take a handle you care about. Send it to the X tweets endpoint, read the JSON, and check the fields against what your project needs before you build on it. A key takes a minute on the quickstart, the pricing page lists the per-tweet cost, and 100 free credits pull a few hundred tweets before anything is billed. When you need posts by keyword instead of by author, the search endpoint takes a query.

Frequently asked questions

How do I use the Twitter (X) API in Python?

You authenticate with a bearer token and call the v2 endpoints, almost always through Tweepy. Install tweepy, create a client with your token, resolve a username to an id, and page through that user’s tweets. Plain requests with the same bearer token works too. Both hit X’s official API, so its pay-per-use pricing and rate limits apply. For read-only work with no OAuth, many developers call a third-party data API from Python instead.

Is there a free Twitter API in 2026?

No. X discontinued the free read tier, and as of early 2026 new developers are on pay-per-use pricing with no free credits. The old free scraping libraries that filled the gap, snscrape and Twint, broke when X locked out anonymous guest access in 2023. The closest thing to free today is Twikit, an actively maintained Python scraper that still works but breaks on X’s schedule, or a third-party API’s free trial credits.

How much does the X API cost in 2026?

On pay-per-use it is about $0.005 per tweet read ($5 per 1,000), $0.010 per profile, and $0.015 per post created, capped at 2 million reads a month with search limited to the last 7 days. The legacy Basic ($200/mo) and Pro ($5,000/mo) plans are closed to new signups. Full-archive search back to 2006 requires Enterprise, which starts around $42,000 a month.

Do snscrape and Twint still work in 2026?

Mostly no. snscrape, Twint, and Nitter all broke when X locked out anonymous guest access in 2023, and the Nitter instance network collapsed afterward. Twikit is the most actively maintained free Python scraper left, but you should expect occasional breakage when X rotates its internal query ids. For anything that has to stay up, a maintained third-party API is more reliable than a free library.

How do I get tweets in Python without a developer account?

Call a third-party data API from Python with an ordinary GET request. It reads public tweets and returns JSON, with no X developer account, no OAuth, and no app review. On ScraperSocial you send a handle to /v1/twitter/tweets with your API key and get the account’s recent posts back, billed 1 credit per tweet. The whole setup is one key in a request header.

How far back can I pull tweets?

Not far on any affordable route. The official API’s cheap tiers only search the last 7 days; full-archive back to 2006 is Enterprise-only at around $42,000 a month. Third-party readers see what a logged-out visitor sees on a public profile, which is recent posts, not a deep archive. For one specific old tweet, fetch it by its URL. For years of history in bulk, expect it to be expensive everywhere.

Keep reading

Try it on your own URLs

100 trial credits on signup, no card. Enough to run a real batch before you decide.