X API reference
X API pay-per-use pricing, after the tiers
On 6 February 2026 X replaced its Free, Basic and Pro subscriptions with prepaid credits spent per request, so there is no longer a tier to qualify for — only a balance, a per-resource rate, and a cap of 3 million post reads per billing cycle.
What actually changed
| Before | Now | |
|---|---|---|
| How you get access | Apply, pick a tier, pay monthly | Buy credits in the Developer Console and spend them |
| Free tier | Existed, with a tiny read allowance | Closed to new signups |
| Basic | $200/month | Closed to new signups; existing subscribers auto-migrated to pay-per-use from 1 June 2026 |
| Pro | $5,000/month | Closed to new signups |
| Enterprise | ~$42,000/month | Unchanged, and still the route above the pay-per-use cap |
| What you are billed for | A monthly allowance of requests | Each resource a response returns |
| Ceiling | Your tier's allowance | 3 million post reads per monthly billing cycle |
The question this makes obsolete
“Which tier do I need for the bookmarks endpoint?” was the right question for years, and it now has no answer. There is no tier to be on, no monthly minimum to clear and no application to be approved. Bookmark read access sits on the standard pay-per-use account: you add credit, you make the call, the balance goes down by the number of resources that came back.
This is worth stating plainly because the constraint people remember is real, it was just removed. On the old Basic tier, 10,000 reads a month were shared across the entire application — roughly three active users before a bookmarks product stopped working. That limit is where “X bookmarks apps do not scale” came from. Under pay-per-use the bookmarks endpoint has no per-app rate limit at all, only a per-user one, so throughput now scales linearly with customers and marginal cost per post is the only real constraint.
What it costs to run, in practice
Because billing follows resources rather than calls, a cost model is arithmetic rather than forecasting. One post read is $0.005; a user object is $0.010; a response containing neither is free. From there:
| Action | Resources returned | Cost |
|---|---|---|
| A one-result freshness check | 1 post | $0.005 |
A full page, max_results=100 | 100 posts | $0.50 |
| Importing a 1,000-bookmark history | 1,000 posts | $5.00 |
The same import with expansions=author_id | 1,000 posts + ~400 users | $9.00 |
| Hitting the monthly cap | 3,000,000 posts | $15,000 |
Three controls to configure before you ship
Pay-per-use moves the risk from “will I be allowed enough quota” to “what happens when my code loops”. All three of these live in the Developer Console and all three should be set before the first real user arrives.
| Control | What it does | The catch |
|---|---|---|
| Spending limit | A hard cap per billing cycle. Requests are blocked once it is reached. | This is your blast radius. Every cost-control assumption in your own code is a piece of code, and code has bugs. |
| Auto-recharge | Tops the balance up automatically. | At most one top-up per five-minute window, and it pauses at a zero or negative balance — so a burst can still run you out of credit. Size the top-up to outlast five minutes of peak spend. |
Usage API — GET /2/usage/tweets | Returns daily post-consumption counts. | Wire it into your own monitoring. A dashboard nobody opens is not a control. |
One more detail worth knowing: a balance can go slightly negative, after which requests are blocked until it is covered. So “out of credit” is a state your application will eventually be in, and it should behave like a temporary outage rather than losing data. The cheapest way to stay far from it is to lean on the 24-hour deduplication window and never ask for a resource twice in a day — and to check the arithmetic against your own library size with the sync cost calculator.
We built the thing this describes
Sift reads your bookmarks once, sorts them into categories, and emails you what you saved. The rules on this page are the reason it costs what it costs — a one-result probe instead of a full page, one paid pass per UTC day, and never an expansion parameter.
Connect X