Twitter API Cost per 1,000 Tweets: Workload Examples

This guide is the calculation layer: how to turn a workload (tweets read, profiles looked up, posts written, DMs sent) into a monthly dollar figure you can defend in a budget review. For the current official price list itself, see the Twitter API pricing page; the numbers below use those verified rates as inputs.

TL;DR: 1,000 billable Post reads cost $5 at the official standard rate; the same thousand tweets cost about $0.05 through GetXAPI when calls return about 20 results. Scale is linear until the official 2M monthly Post-read cap ($10,000), where Enterprise takes over. The formulas below let you reproduce every number for your own volumes.

The Assumptions Behind Every Number Here

All calculations in this article use these inputs, verified August 4, 2026 against the official pricing table:

Input	Value used
Official standard Post read	$0.005 per resource
Official User or follower read	$0.010 per resource
Official standard Post create	$0.015 per request
Official Post create containing a URL	$0.200 per request
Official DM interaction create	$0.015 per request
GetXAPI standard call	$0.001 per call
GetXAPI premium, DM, Create Tweet calls	$0.002 per call
Tweets per GetXAPI standard call	~20 (search and list responses)

If any of those inputs looks stale when you read this, take the current values from the pricing page and rerun the formulas; the method does not change.

The Two Units That Decide Everything: Resources vs Requests

The official X API bills reads per resource. One request that returns 100 posts is billed as 100 Post reads ($0.50), not one request. Per-call providers bill per request, so the effective per-tweet price depends entirely on average results per call.

That single difference is why quoted multipliers vary so much, and why "per request" is only a fair unit when both sides return one thing:

• Single-resource operations (one tweet detail, one profile lookup): $0.005 or $0.010 per resource officially vs $0.001 per call, a 5x to 10x difference, and here per resource and per request are the same number.
• Multi-result reads (a 20-result search page): officially that request bills 20 Post resources, $0.10 for the request, vs $0.001 flat, about 100x per request AND about 100x per tweet ($0.005 vs $0.00005).
• Writes: both sides bill per request, $0.015 official standard Post create vs $0.002, 7.5x.

Never compare a per-resource price against a per-call price directly; convert both to the same unit (per operation for single-resource work, per tweet for collection work) first.

Formula to reuse:

effective cost per tweet = price per call / average results per call
monthly read cost        = (tweets needed / avg results per call) x price per call   [per-call APIs]
monthly read cost        = tweets needed x price per resource                        [official X]

Average results per call is workload-specific: broad search queries and timelines typically fill pages (~20), niche queries and quiet accounts return fewer. Measure your own average on a small sample before you extrapolate; it is the single most sensitive input in the model.

Read Workloads at Common Volumes

Using the standard Post-read rate and 20-result GetXAPI calls:

Tweets per month	Official X (per resource)	GetXAPI calls needed	GetXAPI cost
1,000	$5	~50	~$0.05
10,000	$50	~500	~$0.50
100,000	$500	~5,000	~$5
1,000,000	$5,000	~50,000	~$50
2,000,000	$10,000 (cap)	~100,000	~$100

Two million is where the official pay-per-use path ends: the current table lists a 2M monthly Post-read cap, and larger workloads route to custom-priced Enterprise. There is no published Enterprise floor, so above the cap the only honest budget line is "get a quote."

User lookups scale differently because they are single-resource on both sides: 100,000 profile lookups cost $1,000 officially ($0.010 each) versus $100 on GetXAPI ($0.001 each), a flat 10x rather than ~100x.

A Mixed Workload, Worked End to End

A realistic monitoring product, monthly volumes:

Operation	Volume	Official X	GetXAPI
Tweets collected (search + timelines)	200,000	$1,000 (200K Post reads)	~$10 (10K calls)
Profile lookups	20,000	$200 ($0.010 each)	$20
Posts published (no URL)	500	$7.50 ($0.015 each)	$1 ($0.002 each)
Posts published (with URL)	100	$20 ($0.200 each)	$0.20
DMs sent	1,000	$15 ($0.015 each)	$2
Monthly total		$1,242.50	~$33.20

The pattern to notice: reads dominate almost every real bill. The write lines look scary per unit (especially the $0.200 URL post), but unless you are a scheduling tool publishing at volume, collection volume is where the money goes, so that is where to optimize first.

Adjustments That Change the Bill

Deduplication. The official table describes a 24-hour deduplication period (resetting at midnight UTC): re-reading the same resource within it is generally not charged again, though X calls this a soft guarantee. If your pipeline re-polls the same accounts hourly, your billable reads can be far below your raw request-log count. Model it as: billable reads = unique resources touched per UTC day, summed over the month.

Owned reads. The $0.001 owned-read rate applies only when the authenticated user ID equals the app owner's user ID. It is not a discount for client accounts or managed profiles, so leave it out of the model unless you are literally reading your own account.

Retries and failures. Backoff retries and transient errors add real call volume, but the rate is pipeline-specific, so measure it: instrument one week of logs and use your actual retry percentage. Until you have that number, run the model as a sensitivity table at 0%, 5%, and 10% extra volume and budget from the middle scenario. On per-resource billing, a retried read of the same resource inside the dedup window generally does not double-bill, but retried unique reads do.

Polling cadence. Correct cursor pagination costs nothing extra at the end of a timeline: X omits next_token on the final page, so a well-built client stops without another request. The cost that does scale silently is polling frequency, since every poll of an account costs at least one call even when nothing is new. Polling 1,000 accounts hourly is ~720,000 calls per month before a single new tweet is collected; halving the cadence halves that line.

The Budgeting Method, Start to Finish

1. Count resources, not requests, for the official side; count requests for per-call providers.
2. Split the workload by operation: Post reads, User reads, follower reads, each write action, DMs. Each has its own price; there is no single "read price" or "write price."
3. Measure average results per call on a 100-call sample of your actual queries.
4. Apply the dedup rule to repeated polling of the same resources.
5. Use the owned-read rate only if the identity condition genuinely holds.
6. Add a retry allowance from your measured retry rate, or run 0%, 5%, and 10% sensitivity scenarios until you have one, and price your polling cadence explicitly.
7. Stop the official pay-per-use model at 2M monthly Post reads; above it, budget from an Enterprise quote, not a public rate.
8. Rerun the numbers with current prices from the pricing page whenever you revisit the budget.

Or skip the spreadsheet: the Twitter API cost calculator runs this exact model interactively, side by side for the official API and GetXAPI, at whatever volumes you plug in.

What These Calculations Do and Do Not Tell You

They tell you the metered cost of a workload at current listed rates. They do not tell you when those rates took effect (the official page publishes no effective date), what any legacy account pays, or what Enterprise costs (custom, unpublished). And price is one axis: the official API is the first-party path with official OAuth and policy-defined capabilities, while GetXAPI is a third-party route to public data and account-authenticated actions. The pricing page keeps the current facts with sources and verification dates; this article stays the arithmetic on top of them.

The Verdict

For read-heavy workloads, the per-tweet unit decides the bill: about $5 per 1,000 tweets officially versus about $0.05 per 1,000 through GetXAPI at typical result counts, roughly 100x, while single-resource operations sit nearer 5x to 10x. Run your own volumes through the formulas above or the calculator, attach the current prices from the pricing page, and re-verify inputs before every budget cycle.