X API followers: the request that can cost $10

#Quick answer

Reading follows on X API v2 is priced per user returned, not per request. Following/Followers: Read is $0.010 a head and max_results goes to 1,000, so one page of a stranger's followers is a $10 call and a 100,000-follower account is about $1,000 in credits. Your own list is the exception: it qualifies for Owned Read pricing at $0.001, a hundredfold difference for the identical route. Writing follows is cheap and rate-limited to 50 per 15 minutes, which is twelve times looser than the 400-a-day ceiling X enforces on the account itself.

Last updated: November 2026

Everything here is checked against the live API description at api.x.com/2/openapi.json, version 2.174, X's follows, blocks, pricing and rate-limit pages, the published Python SDK wheel, and X's own follow-limit help page. All read on 9 November 2026.

#Four documented routes, and two that are not

X documents four follow endpoints:

Note the path asymmetry on the writes. You follow at /2/users/{id}/following with the target in the body, and you unfollow at /2/users/{source_user_id}/following/{target_user_id} with both ids in the path. Same relationship, two different parameter names for the same acting account.

Then there are two more. Spec 2.174 declares GET /2/users/me/followers and GET /2/users/me/following, each with a description written by a human: "Same results as GET /2/users/{id}/followers with your own user ID, without looking it up." They save you a lookup, which at $0.010 a profile is not nothing.

Here is what they do not have: a reference page, an entry in docs.x.com/x-api/llms.txt, a row in the rate-limit tables, a line in the changelog, and a method in the generated Python SDK. The string me/followers appears zero times in the documentation index. A codegen client built from the spec will have them; a developer reading the docs will never learn they exist.

They also do not accept an app-only Bearer token, which makes sense, and they are not listed on the Owned Reads table, which does not.

#The cost of a follower list

Following/Followers: Read sits at $0.010 per resource. Resource means user row, so the arithmetic is linear and unforgiving:

Paging does not change the total. A thousand calls of 100 and a hundred calls of 1,000 both bill $1,000 for a 100,000-row account; the large pages just burn fewer requests out of your rate-limit budget.

What does change the total is whose list it is. Both follower routes are on the Owned Reads table, which drops to $0.001 per resource when the {id} in the path matches the authenticated user and that user owns the developer app. So your own 100,000 followers cost about $100, and somebody else's cost about $1,000. Same endpoint, same payload, 100x apart on a condition that lives in your token rather than your query string. The rest of the card has the same shape, mapped in X API pricing.

Two things take the edge off. Resources dedupe inside a 24-hour UTC window, so re-reading the same follower twice in a day is free, and X describes that as a soft guarantee rather than a promise. And blocks and mutes read at $0.001 instead of $0.010, because those list routes return less: in the spec, GET /2/users/{id}/blocking and GET /2/users/{id}/muting declare only max_results and pagination_token, with no user.fields parameter at all. The follower routes take the whole 27-value field enum described in X API user lookup. You pay ten times more because you can ask for ten times more.

Which is worth knowing because the blocks page's own example passes user.fields=username,description to the blocking route. That parameter is not declared there.

No way to audit the bill

There is one programmatic usage endpoint, GET /2/usage/tweets, and it reports Post consumption. The published monthly cap is 3 million Post reads per billing cycle. Neither covers user reads. If a background job pages a large follower list on a loop, the only place that spend shows up is the Developer Console balance, after the fact.

Set a spending limit before you build anything that paginates. At the full 300 requests per 15 minutes with 1,000-row pages, the theoretical ceiling on follower reads is 300,000 billable rows a quarter hour. Nothing in the API stops that, and nothing in the API tells you it happened.

#Rate limits, and the ceiling that actually applies

Two of these deserve a second look.

Reads are capped at 300 per 15 minutes per user as well as per app, unlike plain profile lookups, which give a user token 900. Adding a second authorising user does not buy you a bigger pool here. More of those asymmetries are collected in X API rate limits.

The writes are the interesting case. 50 follows per 15 minutes works out to 200 an hour and 4,800 a day. X's own help page puts the account-level limit at 400 follows per day, and calls it "a technical account limit only" before listing the behavioural rules that sit on top. So the API will happily accept your 401st follow call of the day and the account will refuse it. The rate limiter is not the ceiling; the account is. The full set of platform-side numbers is in X daily limits.

#What the follow response actually tells you

Request bodies here are tightly specified. FollowUserRequest requires exactly one key, target_user_id, typed as a string matching ^[0-9]{1,19}$, with additionalProperties: false. Pass an integer instead of a string, or add a stray key, and it is a hard 400.

Responses require two booleans:

{
  "data": {
    "following": true,
    "pending_follow": false
  }
}

pending_follow is the one people miss. Follow a protected account and the call succeeds as a follow request: following comes back false and pending_follow comes back true until the person approves it. A client that branches on data.following alone will log that as a failure and retry, which is how you turn one legitimate follow request into a burst of identical ones.

Unfollow is asymmetric here too. UnfollowUserResponseData requires only following, with no pending_follow counterpart, so there is no documented way to cancel a pending request and confirm it through the response shape.

Both sides also return errors as an array of problem objects alongside data, which means a 200 can carry a partial failure. Check the array, not just the status.

#Blocks are Enterprise, mutes are not

This is the restriction most likely to break a plan you have already made. X's Blocks page says it plainly: "The block and unblock users endpoints are only available under the Enterprise plan." Reading your block list on pay-per-use is fine. Writing a block is not.

Mute and unmute have no such gate. POST /2/users/{id}/muting and DELETE /2/users/{source_user_id}/muting/{target_user_id} are ordinary 50-per-15-minute write endpoints, and unmute even gets its own discounted Mute: Delete row at $0.005 where a generic Interaction: Delete is $0.010.

One gap is worth flagging: the live OpenAPI description declares all four block operations with normal block.read and block.write OAuth 2.0 scopes, no deprecated flag, and nothing marking them enterprise-only. The restriction exists in one sentence of prose on one hub page. Generate a client from the spec and it will give you a block_user method that cannot work on your plan. The official Python SDK, as it happens, ships no block or unblock method at all, only the DM-specific block_dms and unblock_dms, so the generator and the spec disagree about this too.

#Where the rules bite, not the rate limiter

Everything above is about whether a request succeeds. Whether you should send it is a different page.

X's follow limit and ratio page names two behaviours directly. Follow churn is following and then unfollowing large numbers of accounts to inflate your own follower count. Indiscriminate following is following or unfollowing a large number of unrelated accounts in a short period, and X's wording singles out doing it "particularly by automated means." Separately, once you follow 5,000 accounts, further follows are governed by a ratio X calculates from your own numbers and does not publish.

The platform manipulation and spam policy covers artificially inflating account metrics, and the automation rules cover what you may do programmatically. Holding a valid API token does not exempt you from any of it. The endpoint is sanctioned; a follow-unfollow loop running through it is not, and the enforcement happens against the account rather than against the app.

If what you want is to see who left, that is a read problem rather than a write one, and who unfollowed me on X covers doing it without paying by the row. If you want to clean up a bloated following list, how to unfollow everyone on X walks the limits and the tools.

#Should you build on these endpoints

For reading, yes, with a budget. Follower analysis, audience overlap, a dashboard over your own list: the Owned Read rate makes your own data cheap, and the 300-per-15-minute cap is generous enough for a nightly sync. Store ids rather than handles, cache aggressively to use the 24-hour dedupe window, and set a spending limit before the first deploy.

For writing, be honest about what you are building. The API gives you 4,800 follow calls a day against an account that permits 400, and the rules that govern the difference are written about behaviour rather than about interfaces.

If the actual goal is to grow by posting and replying well rather than by follow volume, the API is an expensive way in. X-Autopilot works the other way: it drives your own logged-in session in your own browser on your own Mac, so your session cookie never leaves the machine and there is no shared cloud IP pool or delegate account in the path. That is a lower detection surface than a cloud scheduler, not a safe one, and automating engagement through a browser rather than the API is a gray area rather than a sanctioned route. The API is the sanctioned one. Pick it when sanctioned access is what you need, and price the pagination before you write the loop.