The official X API
Everything, the long way around
- Built for everything — and priced like it
- Plumbing first: OAuth, cursors, raw envelopes
- You stitch multi-call jobs together yourself
Compare · X API alternative
xfetch vs. the official X API
A focused alternative to the official X API for read-heavy work — a single API key, credits-only pricing, clean JSON, and stable workflow endpoints. Clear scope: reads only, no account automation.
xfetch
The read path, sharpened
- Built for the read jobs teams actually run
- One key, clean JSON, opaque tokens
- Workflow endpoints return the whole job in one call
01At a glance
The scorecard, line by line.
- 01AuthOAuth 1.0a / 2.0 flowsSingle API key✓
- 02PricingTiered monthly plansUsage-based credits✓
- 03Data shapeRaw API envelopesClean, stable JSON✓
- 04PaginationProvider cursorsOpaque tokens✓
- 05WorkflowsCompose many callsStable /v1 workflow endpoints✓
- 06Agent contextNot offered/llms.txt + /openapi.json✓
- 07Failed callsCount against quotaNever charged✓
Rate limits scale with your plan — 60 / 300 / 600 / 900 / 1,500 / 2,400 req/min by plan. Failed calls, rate limits, and service-side errors are never charged.
02Migration
The switch, in three moves.
- 01
Keep your mental model
Profiles, tweets, search, followers — the same /2 read paths you already use keep working.
- 02
Swap host and token
Point your client at api.xfetch.io and swap the bearer for your xfetch key — no OAuth dance (see below).
- 03
Reach for /v1 when you need more
Need richer blocks or a whole job in one call? Move that one request to a /v1 workflow endpoint.
Before · official X API
curl -H "Authorization: Bearer $OFFICIAL_BEARER" \ https://<official-host>/2/users/by/username/jack
After · same request against xfetch
curl -H "Authorization: Bearer $XFETCH_API_KEY" \ https://api.xfetch.io/2/users/by/username/jack
What carries over to /2: supported request paths, official-style pagination tokens, count parameters where xfetch can honor them, the supported field selectors, and the official response body — credit metadata lives in headers, not your payload.
03What xfetch adds
Beyond parity.
Workflow →
Workflow endpoints
/v1/profiles/by-username and /v1/tweets/:id/context assemble what a job needs — profile + recent tweets, or tweet + author + context — in one call.
Enrichment →
Deduped author enrichment
search.enriched returns tweets plus a single deduplicated authors array, so you join less by hand.
AI & agents →
Built for AI and agents
Normalized JSON drops into RAG and agents, with machine-readable /llms.txt and /openapi.json context.
Predictable cost →
Credits-only, public pricing
Single-object lookups cost 1 credit; collections, search, and workflows scale by returned primary items. Usage is reported in stable endpoint keys.
04Same task, two shapes
"Get a profile and recent tweets."
A common warm-up for any social feature. On the official X API you assemble it across calls and a manual join. The xfetch workflow makes it a single named-block response.
Approach A · official-style2 calls + glue
1 — resolve the user
GET /2/users/by/username/jack?user.fields=id,username,name → get the user id from the supported field subset
2 — fetch recent tweets
GET /2/users/:id/tweets → then merge user + tweets, page, and dedupe yourself
2 round trips + manual joinyou write the glue
Approach B · xfetch workflow1 call
single request
GET /v1/profiles/by-username/jack
response · named blocks
{
"data": {
"user": { "username": "jack" },
"recent_tweets": [ …5 normalized tweets ]
},
"meta": { "credits": { "charged": 7 } }
}1 round tripxfetch writes the glue
05Scope boundaries
Clear read-API boundaries.
These boundaries keep the self-serve contract stable: xfetch is built for read workflows, migration-friendly reads, and predictable credits.
Boundary
Read APIs only
Posting, liking, reposting, following, and DMs stay outside the self-serve API.
Boundary
Not a full mirror
We don't expose every endpoint that exists. Each one maps to a real user workflow.
Boundary
No universal query DSL
No GraphQL, no single catch-all endpoint — just workflow endpoints with stable contracts.
Boundary
No account automation
Account control, bulk actions, and automation workflows stay outside the read API.