Updated June 2026: rebuilt around the February 6 pay-per-use rollout and the April 20 X API price change, with current per-request read costs and the 2026 status of open-source scrapers.
Key Takeaway The official X API requires a developer account, but public X data can be read without one using a third-party API, web scraping, or public datasets. Since February 2026 it is pay-per-use with no free read tier, and managed APIs need only an API key.
The official developer portal is no longer the only door to X data. Sorsa API, an alternative Twitter/X API provider, reads public profiles, tweets, search results, and follower graphs through a single key in an ApiKey header: no OAuth, no app review, and no approval queue, with setup in about three minutes. Billing is flat per request from $49 for 10,000 requests, and a read costs one request no matter how many records it returns.
That matters because the official program is built around the two things a data team most wants to skip: a use-case review and a per-resource meter. This guide covers what actually changed at X in 2026, the three honest ways to pull public data without an account, where each one breaks, what reads really cost now, and the line between reading data and writing it. For the official path, when you do want it, see our walkthrough on getting an X API key the official way.
Table of contents
- Do you still need a developer account for the X API in 2026?
- Why the official developer portal pushes developers away
- Three ways to get X data without a developer account
- Read vs write: what an unofficial Twitter API can and cannot do
- What read access costs: official X API vs a flat-rate API
- How key-based access works in practice
- What switching looks like for a small team
- Getting started
- Frequently asked questions
Do you still need a developer account for the X API in 2026?
Yes. The official X API cannot be used without a developer account, even though the pricing model changed. According to X's developer documentation, you sign in at console.x.com, accept the Developer Agreement, create an app to generate credentials, and load prepaid credits before any request runs. The account itself is quick to create. The friction is what comes after.
What changed is the billing. On February 6, 2026, X replaced its subscription tiers with pay-per-use as the default for new developers. The old Basic and Pro plans survived only for accounts that subscribed before the cutover, and even those are being migrated to pay-per-use after June 1, 2026. There is no standalone free read tier anymore: a new developer must hold a credit balance to make calls, and reads stop when the balance or the monthly cap is reached.
Approval is no longer a guaranteed multi-week wait. Standard, well-described use cases are now approved automatically, often within minutes. The catch sits in the exceptions: AI, bot, and bulk-data collection use cases can still trigger an additional manual review, and those are exactly the categories most data and research projects fall into. The queue did not disappear. It moved to the workloads that need volume.
A third-party API sidesteps all of it. There is no application, no use-case form, and no credit math: a key in a header returns JSON. That is the practical meaning of "without a developer account," and it is why a researcher on a deadline or a team shipping a feature reaches for one.
Why the official developer portal pushes developers away
The portal pushes people away for two durable reasons: cost and uncertainty. The pay-per-use model bills per resource, so a single query that returns 20 posts and their authors is charged for 20 post reads plus 20 user reads, and the bill climbs fast on anything analytical. The review step adds timing risk that no roadmap likes.
Pricing is the sharper edge. Reading other accounts' data is metered at $0.005 per post and $0.010 per profile, and a heavy monitoring job can hit the monthly ceiling of 2 million post reads, above which only an Enterprise contract (historically starting around $42,000 per month) raises the cap. We cover the full breakdown in our piece on the official API's pay-per-use pricing and on why official pricing climbed.
Rate limits are the quiet third reason. Pay-per-use did not remove them: X still enforces 15-minute rolling windows per app and per user, so throughput is capped by time as well as by spend. For a team that only needs to read public data, paying per resource and managing windowed limits is a lot of overhead for data that is public to begin with.
Three ways to get X data without a developer account
There are three routes that never touch the official portal: a managed read-only API, scraping with open-source libraries, and downloading public datasets. They differ most on reliability and on whether the data is live.
1. A managed read-only data API. A provider runs the infrastructure and exposes documented REST endpoints; you authenticate with a key and get structured JSON back. This is the most reliable route for production and for research with a deadline, because the provider absorbs the breakage when X changes its internals. It is the route we operate, covering profiles, tweets, search, followers, lists, and communities.
2. Scraping and open-source wrappers. Browser automation (Playwright, Puppeteer, Selenium) or reverse-engineered libraries call X's public or internal endpoints directly. The 2026 reality is harsh: snscrape has been largely broken since active maintenance paused in 2023, Twint has had no updates since 2022, and Twikit and Twscrape still run but break whenever X ships an interface change. Free to start, costly to keep alive once proxies, rate detection, and maintenance are counted. Our deep dive covers the scraping route in detail.
3. Public datasets. Academic repositories on Kaggle, Harvard Dataverse, and similar platforms publish large tweet datasets. They are legal and usually free, and they are excellent for historical or machine-learning work. The limit is that they are static snapshots: no real-time data, and no way to query a specific account or topic on demand.
| Method | Setup | Reliability in 2026 | Data | Typical cost |
|---|---|---|---|---|
| Managed read-only API | API key, minutes | High, provider-maintained | Real-time and historical | Flat per request, from $49 / 10K |
| Scraping or open-source wrappers | Build plus proxies | Low, most legacy libraries broken | Real-time, often incomplete | "Free" plus dev and proxy time |
| Public datasets | Download | Static, no live updates | Historical only | Usually free |
If the data must be current and the integration must stay up, a managed API is the route that does not collapse under maintenance. Datasets are for history, and DIY scraping is for throwaway experiments.
Read vs write: what an unofficial Twitter API can and cannot do
"Unofficial Twitter API" covers two very different jobs, and mixing them up causes most of the bad advice online. Reading public data (profiles, tweets, search, followers) is one job. Writing (posting, replying, liking, following, sending DMs) is a separate one with separate risk.
Reading public data without an account is well-supported and stable through managed data APIs. Writing is not. The reverse-engineered libraries that automate posting through X's internal endpoints are fragile and run against the platform's terms, and they put the acting account at real risk of suspension. The supported route for write actions is the official X API with its OAuth credentials, full stop.
This is the honest concession for the whole category: a read-only API does not post, like, or message, by design. We built Sorsa read-only on purpose, because removing write permissions removes a class of account-level risk and keeps read access predictable. If a project genuinely needs both, the clean pattern is a read-only data API for collection plus the official API for the handful of write actions, rather than trusting an internal-endpoint hack to do both.
What read access costs: official X API vs a flat-rate API
For read-heavy work, a flat per-request API is dramatically cheaper than the official per-resource meter. The official API charges for each item returned; a flat-rate API charges one request whether it returns one record or two hundred. On Sorsa's Pro plan ($199 for 100,000 requests), the per-unit math lands tens of times below the official rates.
The difference comes from how each side counts. The official API bills the author profile attached to a tweet as a separate user read; a flat-rate API returns that author inside the same response at no extra charge. Batch endpoints widen the gap further: one request to a bulk tweet endpoint returns up to 100 complete tweets with authors, still a single request.
| What you fetch | Official X API (pay-per-use) | Flat-rate API (Sorsa Pro, $199 / 100K) |
|---|---|---|
| 1,000 user profiles | $10.00 (1,000 x $0.010) | ~$0.01 (5 requests, 200 profiles each) |
| 1,000 post reads (search or timeline) | $5.00 (1,000 x $0.005) | ~$0.10 (about 50 requests) |
| 100 tweets by ID, with authors | $1.50 ($0.50 reads plus $1.00 author reads) | $0.00199 (one bulk request) |
| Authentication | OAuth 2.0, developer account, prepaid credits | Single ApiKey header, no approval queue |
| Free option for new users | None | In-browser tools free; API from $49 / mo |
The single honest caveat: the official API is required if you need to write (post, DM, follow). For reading public data at volume, the flat per-request model wins on cost, on rate-limit simplicity (a flat 20 requests per second on every plan, with no 15-minute windows), and on setup. If you are moving an existing integration over, our guide to migrating off the official API maps the endpoints.
One note for accuracy: the official API's cheapest read rate, $0.001 per resource, applies only to your own account's data, not to the third-party accounts a data project usually reads.
How key-based access works in practice
Without a developer account, authentication collapses to one step: send your key in a header. There is no OAuth handshake, no bearer-token refresh, and no callback URL. Every endpoint takes the same ApiKey header, and every response comes back as JSON.
A profile lookup is a single GET request:
curl -H "ApiKey: YOUR_API_KEY" \
"https://api.sorsa.io/v3/info?username=elonmusk"
Search is a POST with a JSON body, and it accepts standard advanced-search operators such as from: and since::
import requests
resp = requests.post(
"https://api.sorsa.io/v3/search-tweets",
headers={"ApiKey": "YOUR_API_KEY"},
json={"query": "from:nasa climate", "order": "latest"},
)
data = resp.json()
for tweet in data["tweets"]:
print(tweet["full_text"])
next_cursor = data["next_cursor"] # pass this back to fetch the next page
Follower lists page the same way, returning up to 200 profiles per request through a next_cursor. For language-specific patterns, see our guide to reading X data from Python, with the API key authentication and quickstart pages for the full setup. Teams building with AI assistants can reach the same data through our Model Context Protocol server.
What switching looks like for a small team
A roughly ten-person analytics team came to us after a brand-monitoring build stalled on the official portal: their bulk-data use case had been kicked into manual review, and the per-resource pricing made continuous mention tracking expensive to model. They needed to read public mentions and profiles, nothing more.
Moving the collection layer to a flat per-request API removed both blockers at once. Authentication dropped to a single header, so there was no OAuth plumbing to maintain, and because author profiles arrive inside tweet responses, their mention-tracking cost fell by roughly 30 to 50 times against the official per-resource rates, the same order of savings anyone reading at volume sees. The honest limit held: for the few automated replies they ran, they kept a separate official-API path, since a read-only API does not post.
Getting started
Reading X data without a developer account takes three steps: pick a route, get a key, and make a request. For one-off checks, the free in-browser tools on the Sorsa playground run lookups like ID conversion and a shadowban check without any key at all. For programmatic access, a key returns JSON immediately, with no application and no approval queue, and plans start at $49 for 10,000 requests with a flat 20 requests per second. Full pricing and request quotas sit on the plans page, and for help choosing between providers there is a comparison of third-party Twitter API providers.
Frequently asked questions
Can you get Twitter data without a developer account?
Yes. Public X data such as profiles, tweets, search results, and follower lists can be read without an X developer account by using a third-party API, web scraping, or public datasets. A managed third-party API needs only an API key in a request header, so there is no application form and no approval wait.
Do you still need a developer account for the official X API in 2026?
Yes. Since February 6, 2026 the official X API runs on pay-per-use pricing, but you still create a developer account at console.x.com, accept the Developer Agreement, register an app, and load prepaid credits before any call. Standard use cases are approved automatically, while AI, bot, and bulk-data use cases can trigger an additional review.
Is there a free Twitter API without a developer account?
Not for ongoing data collection. The official X API no longer offers a free read tier for new developers, and most third-party APIs charge per request or per month. Free in-browser tools can handle one-off lookups such as ID conversion or a shadowban check, but pulling data programmatically at scale needs a paid plan.
Can you post tweets or send DMs without a developer account?
Not reliably. Posting, replies, and direct messages are write actions, and the supported route for them is the official X API with its OAuth credentials. Reverse-engineered libraries that automate posting through internal endpoints break often and risk account suspension. Read-only data APIs, including Sorsa, do not post or send messages by design, which keeps read access stable.
Which unofficial Twitter APIs still work in 2026?
Most legacy open-source scrapers are unreliable in 2026. snscrape has been largely broken since active maintenance paused in 2023, and Twint has had no updates since 2022. Twikit and Twscrape still run but break whenever X changes its internal structure. Managed third-party data APIs are the more stable option because the provider maintains the endpoints.
How much does third-party Twitter API access cost compared to the official API?
It is usually much cheaper for reads. The official X API bills per resource, so 1,000 user profiles cost about $10 and 1,000 post reads about $5. A flat per-request API like Sorsa charges one request regardless of items returned, so the same workloads run for roughly cents, often 30 to 50 times cheaper on read-heavy jobs.
Reviewed by Keksich, founder of Sorsa, marketer and X API researcher.
This guide draws on our team's hands-on work operating Sorsa's read endpoints, on the live API and its documentation, and on the official X developer documentation for the current pay-per-use model and developer-account flow. The official per-resource read rates and the no-free-tier status were re-verified against X's developer documentation on June 13, 2026; the three no-portal access routes were compared on reliability, cost, and data freshness.