You want a user's recent posts, or the results of a search, and you do not want to buy official API credits to get them. There are four realistic options in 2026. Each one works; each one costs something different, and the cost is rarely the invoice.
First, the boundary
This post is about public data — posts, profiles, and search results that any logged-out visitor can see. Reading public pages is broadly defensible; scraping behind a login, evading access controls, or republishing personal data at scale is a different activity with different consequences under X's terms, the CFAA, and the GDPR.
Nothing below is legal advice. If your product depends on the answer, get one from a lawyer rather than a vendor's blog — very much including this one.
1. A managed read API
Someone else runs the collection infrastructure and you call an HTTP endpoint with a key. This is the option with the lowest total cost of ownership and the least control.
Good when: you want data in your app this afternoon, your volume is predictable, and maintaining a scraper is not the job you want.
Bad when: you need a hard contractual guarantee of availability, or your volume is so low that any subscription is overkill.
What it looks like — the Probe Uranus version, though the shape is similar across providers:
JavaScript
const res = await fetch(
"https://api.probeuranus.fun/v1/user/tweets?userName=elonmusk&limit=20",
{ headers: { Authorization: `Bearer ${process.env.PROBE_API_KEY}` } },
);
const { data, meta } = await res.json();Cost comparison across the managed options is on /compare and in X API alternatives.
2. Self-hosted scraping
Run an open-source X client yourself against X's internal GraphQL endpoints, with your own session cookies and proxies. Free in licence terms, expensive in every other sense.
What you are signing up to maintain:
- Query IDs that rotate. X's GraphQL operations are keyed by hashes that change without notice. When they change, your calls 404 until someone re-extracts them.
- Request signing. Endpoints expect a client transaction ID derived from the web app's own JavaScript. Getting this wrong looks exactly like being rate-limited.
- Session rot. Cookies get flagged, throttled, and killed. A single account is not a system; you need a pool, health checks, cooldowns, and a way to revive or replace dead sessions.
- Response drift. The JSON shapes change. Timeline entries move between instruction types. Fields you depend on go missing for a week and come back.
- Proxies. Datacentre IPs get blocked quickly, so you are renting residential egress, which is a recurring bill and an ongoing supplier-quality problem.
Good when: the collection pipeline is your product, or your volume is high enough that the engineering time is genuinely cheaper than any per-call rate.
Bad when: you have other things to build. The honest figure is not the server cost, it is a recurring share of an engineer's week, indefinitely.
3. A headless browser
Drive Playwright or Puppeteer against x.com and read the rendered page. Conceptually the simplest and operationally the worst at any scale.
Good when: you need a handful of pages occasionally, or a screenshot, or you are prototyping and correctness matters more than throughput.
Bad when: you need volume. A browser per request is orders of magnitude more CPU and memory than an HTTP call, bot detection targets automated browsers specifically, and selectors break on every front-end deploy.
4. The official API
Worth including because for some jobs there is no substitute: writes, DMs, ads, filtered streams, and any case where you need a contract. It is also the most expensive per read by a wide margin — $5.00 per 1,000 post reads, priced per resource returned rather than per call. The full breakdown is in X API pricing in 2026.
Choosing
| If you... | Use |
|---|---|
| Need it working today, modest volume | Managed read API |
| Need writes, DMs, ads, or streaming | Official X API |
| Are building a data business on X data | Self-hosted, with the staffing to match |
| Need a few pages, occasionally | Headless browser, or just open a tab |
| Have unpredictable, bursty volume | Metered third-party API |
Four things that catch everyone
- Deleted and protected posts. Whatever the source, a post can vanish between your read and your render. Handle the gap instead of assuming permanence.
- Pagination cursors expire. Do not persist a cursor overnight and expect it to resume.
- Empty is not always an error. Several surfaces legitimately return nothing — private accounts, removed posts, regions without trends. Retrying an empty response in a tight loop just burns quota.
- Cache aggressively. Profiles change slowly. A short TTL in front of profile lookups typically removes most of the traffic, whichever option you pick.
If option 1 is where you land, Probe Uranus is a flat monthly plan with a free trial — pricing, docs, and a public llms-full.txt for agents.