# Get the Accounts a Twitter User Follows Canonical: https://www.twitterapis.com/answers/how-to-get-who-a-twitter-account-follows Description: user/following and following_v2 page the outbound graph edge by username. Stop on an empty users array, not a null cursor. Pages bill $0.0008 each. Generated: 2026-08-26T06:52:18.631Z ---[Pricing](/pricing)[Docs](https://docs.twitterapis.com)[Blog](/blogs) Compare and Tools [MCP Server](/mcp)[Integrations](/integrations)[Language Clients](/sdk)[Free Tools](/tools)[Twitter ID Finder](/tools/twitter-id-finder)[Twitter API Cost Calculator](/twitter-api-cost-calculator)[Twitter Search API](/twitter-search-api)[Twitter Followers API](/twitter-followers-api)[Twitter Scraper](/twitter-scraper)[Twitter API Use Cases](/twitter-api-usecases)[Twitter API Rate Limits](/twitter-api-rate-limits)[Twitter Unofficial API](/twitter-unofficial-api)[Twitter Free API](/twitter-free-api)[Twitter API Alternatives](/twitter-api-alternatives)[TwitterAPIs vs Tweepy](/twitterapis-vs-tweepy)[TwitterAPIs vs RapidAPI](/twitterapis-vs-rapidapi)[TwitterAPIs vs GetXAPI](/twitterapis-vs-getxapi) Company [About](/about)[Status](/status)[Affiliates](/affiliates)[Trust](/privacy-and-data-handling)[Changelog](/changelog)[Contact](/contact) [Start Free](/signup) 1. [Home](/) 2. /[Answers](/answers) 3. /How do you get the accounts a Twitter user follows? # How do you get the accounts a Twitter user follows? Last updated August 24, 2026 Two endpoints read the outbound edge: user/following and user/following\_v2. Both accept a username without the leading @ plus a cursor, and both hand back users, count, and next\_cursor. Follower graph responses keep sending a non-null cursor even on the final page, so the loop terminates on an empty users array. Every page is billed at $0.0008. Every rate here is the pricing TwitterAPIs publishes. The billed rate is $0.0008 per call; $0.04 per 1,000 tweets is derived from it at a full 20-tweet page, which is the default page size rather than a guaranteed yield (source: [twitterapis.com/pricing](/pricing)). ## Outbound and inbound are separate routes Following is the set an account chose. Followers is the set that chose the account. No direction flag switches between them, because they are different paths: user/following reads the outbound edge, user/followers reads the inbound one, and each has its own v2 sibling. The payload shape is identical in both directions, which is exactly why the mistake is easy to make and hard to notice, since a wrong-direction export looks perfectly well formed. Name the output file after the direction you requested rather than after the account, and the error becomes visible the moment somebody opens the folder. Both directions also carry a v2 sibling with exactly the same split, so there are four graph reads to keep straight rather than two, plus one verified-only route that exists on the inbound side alone. ## The request takes a handle, not an identifier username is the only required parameter and it is the handle with the leading @ removed, so naval rather than @naval. cursor is the optional second parameter. That is the whole request surface for both variants: there is no count argument on these routes, no verified filter and no sort order, so every narrowing decision belongs in your own code. Send the key as a bearer token in the Authorization header, or as x-api-key holding the same value. Note that this family keys on the handle while the pairwise relationship probe keys on numeric identifiers, which is a real difference to encode once rather than rediscover. The documented examples for both variants use naval, and neither accepts a numeric identifier in place of the handle. ## What one page of the roster contains Three fields come back. users is an array of full user objects for this page, each carrying id, username, name, followers\_count and verified among the standard profile fields, which means a roster export is already enriched enough to sort or filter without a second lookup per row. count is the number of entries on this page. next\_cursor is the token for the following request. The documented v1 example returns a single account, id 2178758961 with the username balajis, a followers\_count of 1000000 and verified true, alongside a cursor beginning DAABCgABF. There is no has\_more flag on these routes, unlike some other families in this API that do send one, so count and next\_cursor are the whole of the paging metadata you get to work with. ## The termination trap on graph routes This family does not signal completion the way the List routes do. The shared cursor contract is explicit about the split: List and affiliate routes set next\_cursor to null once the collection is exhausted, while follower graph routes keep returning a cursor that still looks perfectly usable after the last real page. So the stop condition here is the collection, not the token. Break when users comes back empty. A loop copied from a List integration, written to wait for a null cursor, will run past the end of the roster and keep issuing requests against a feed that has nothing left to give it. The contract note is attached to the shared next\_cursor field itself rather than to any single route, which is why it holds across every member of this family. ## What the wrong stop condition costs The failure is quiet rather than loud, which is what makes it worth a paragraph. No error is raised, no exception surfaces, and the records already collected are correct, so a test on a small account passes and the bug only shows up in the bill and in a job that never finishes. Each wasted iteration is a billed request at the standard rate and one slot against the per minute allowance, so an unattended overnight run can burn tens of thousands of requests returning empty arrays. Assert on the empty collection, and log the page count so a run that returns far more pages than the account's following\_count implies is obvious the next morning. ## What following\_v2 changes user/following\_v2 serves the same relationships through a more consistent cursor model and a wider user object, and it is documented as the preferred variant for new integrations. The concrete difference in the payload is created\_at, the account registration timestamp, which appears in the v2 example and not in the v1 one. That is an account age signal, useful for scoring a roster for bot-likeness or seniority without any extra call. Migration is close to free: the parameter list is unchanged, username and cursor behave the same, and the termination rule is the same, so the diff is usually the path string and a widened row type. The inbound side is paired the same way, so in practice a migration touches both routes in one change rather than one at a time. ## Verified filtering exists on the inbound side only There is one verified-only route in this family and it faces inbound: user/verified\_followers pages just the badged accounts following a handle, taking the same username and cursor arguments. No outbound counterpart is published, so trimming a following roster down to verified accounts means pulling the whole thing and filtering locally on the verified boolean that every user object already carries. That costs nothing extra in requests, since the field arrives either way, but it does mean the request count is set by the full roster size rather than by the size of the answer you wanted. Its documented example returns a badged account with verified true and a followers\_count of 1000000, the same object shape the unfiltered routes send, so nothing downstream has to change to consume it. ## Writing the export as you go Each page is a self-contained JSON document, so the natural output format is one record per line appended as the response arrives, with the cursor that produced it recorded alongside. Memory then stays flat regardless of roster size, and an interrupted run restarts from the last recorded cursor instead of from page one, which matters when the roster runs to thousands of pages. Key rows on the numeric id rather than the handle so the file stays joinable after somebody renames themselves, and keep the raw page bodies if you may want fields you did not parse the first time. Recording the page index next to the cursor also makes an anomalous run easy to spot afterwards, since the page count is the number that gives away a loop that failed to stop. ## How long a large roster takes to land Throughput decides the wall clock, not billing. A key may hold 20 requests open at once and issue 600 in a minute, so a roster of 2,000 pages takes a little over three minutes at the ceiling and costs $1.60. Price scales linearly with page count, which makes a large export cheap but not instantaneous, and it means the useful optimisation is avoiding re-fetching what you already hold rather than shaving the per-page rate. Store the last cursor and the run timestamp so an incremental pass starts where the previous one stopped. The two ceilings worth planning around are the per minute rate and the concurrency limit, so a long export is a scheduling question rather than a budgeting one. $0.0008 a call, per the rates we publish. ## Follower graph routes by direction and variant Endpoint Edge direction What is different about it user/following Outbound, accounts this handle chose The v1 shape: users, count, next\_cursor user/following\_v2 Outbound, preferred for new work Adds created\_at to every user object user/followers Inbound, accounts that chose this handle Same fields, opposite direction user/followers\_v2 Inbound, preferred for new work Adds created\_at on the inbound side user/verified\_followers Inbound, badged accounts only No outbound equivalent is published > When an API response contains more results than can be returned at once, use pagination to retrieve all pages of data. X Developer Platform, pagination documentation. [Source](https://docs.x.com/x-api/fundamentals/pagination) ## Questions and answers Which endpoint gives me the following list rather than followers? user/following, or user/following\_v2 for the wider payload. Both take username without the @ and return the accounts that handle has chosen to follow. The similarly shaped user/followers goes the other way. Since the two response bodies look alike and neither carries a direction marker, the safest habit is naming your output after the direction you requested rather than after the account. Do I pass a handle or a numeric identifier? A handle, with the leading @ stripped, so naval rather than @naval. That is worth flagging because the pairwise relationship probe in this same API requires numeric identifiers instead. Two routes that answer neighbouring questions take different key types, so a helper that resolves both forms once and hands the right one to each route saves a recurring class of 400s. When should I stop paging? When the users array comes back empty. Follower graph routes keep returning a cursor that still looks usable after the roster is exhausted, so a non-null token is not evidence that more data exists. Waiting for null here means looping past the end of the collection and paying for requests that return nothing useful, with no error raised to tell you. Why does the cursor keep coming back after the last page? It is documented behaviour for this family rather than a bug you can work around. The shared cursor contract records that follower graph routes emit a non-null cursor even on the final page, which is why the collection itself is the stop signal. Treat the token as a way to request more, never as a claim that more exists, and the loop stays correct. Do the List routes behave the same way? No, and that is the trap. List routes and affiliate routes set next\_cursor to null once their collection is complete, so a loop written against them terminates on the token. Point that same loop at a following roster and it never exits. If one piece of code serves both families, break on an empty collection, which is correct under either rule. Is following\_v2 worth switching to? For anything new, yes. It is documented as the preferred variant, keeps the parameter list identical, and widens the user object: the example payload carries created\_at, an account age signal the v1 shape omits. Migration is usually the path string plus a widened row type, since username, cursor handling and the termination rule all stay exactly as they were. The inbound followers route is paired the same way, so both usually move in a single change. Can I fetch only the verified accounts a user follows? Not directly. The verified-only filter exists on the inbound side as user/verified\_followers, and no outbound counterpart is published, so you read the full following roster and filter on the verified boolean each user object already carries. Filtering locally adds no request overhead, but the request count is set by the roster size rather than by how many badged accounts it holds. How should the exported records be stored? One JSON object per line, appended as each page returns, with the cursor that produced it written alongside. Memory stays flat regardless of roster size, and an interrupted run resumes from the last recorded cursor rather than starting over. Key rows on the numeric id so the file remains joinable after a rename, and keep the raw bodies if you might want unparsed fields later. How long does a large roster take to pull? Throughput sets the clock rather than billing. A key holds 20 requests open at once and issues up to 600 a minute, so 2,000 pages take a little over three minutes at the ceiling and cost $1.60. The productive optimisation is not re-fetching rosters you already hold, since the per page rate is flat and there is nothing to negotiate down. Can I get someone's following count without paging the whole list? Yes. A profile lookup returns following\_count directly in the user object, so one request gives the number without touching the roster at all. In the documented example that field reads 421 for the account being resolved. Page the graph only when you need the identities, and use the count when you only need the size or want to sanity check a completed export. ## Keep reading - [Twitter Followers API](/twitter-followers-api?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-how-to-get-who-a-twitter-account-follows) - [Twitter Analytics API](/twitter-analytics-api?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-how-to-get-who-a-twitter-account-follows) - [Python SDK](/sdk/python?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-how-to-get-who-a-twitter-account-follows) - [How does Twitter API pagination work?](/answers/how-does-twitter-api-pagination-work?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-how-to-get-who-a-twitter-account-follows) - [Rate limits](/twitter-api-rate-limits?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-how-to-get-who-a-twitter-account-follows) ### Start with $0.50 in free credits No credit card. Roughly 12,500 tweets to test every endpoint. [Get your API key](/signup?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-how-to-get-who-a-twitter-account-follows)[See pricing](/twitter-followers-api?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-how-to-get-who-a-twitter-account-follows) [ TwitterAPIs](/) The cheapest pay-as-you-go Twitter and X API. $0.0008 per call, which works out to $0.04 per 1,000 tweets on a full 20-tweet page. No subscriptions and no developer account. ## Product / API - [Pricing](/pricing) - [Pay-Per-Use Pricing](/pay-per-use-pricing) - [Cost Calculator](/twitter-api-cost-calculator) - [Rate Limits](/twitter-api-rate-limits) - [MCP Server](/mcp) - [Integrations](/integrations) - [Language Clients](/sdk) - [Changelog](/changelog) - [Status](/status) ## Developers - [Documentation](https://docs.twitterapis.com) - [API Reference](https://docs.twitterapis.com/docs/reference/search/tweet-advanced-search) - [User Info](https://docs.twitterapis.com/docs/reference/user-reads/user-info) - [User Tweets](https://docs.twitterapis.com/docs/reference/user-reads/user-tweets) - [Advanced Search](https://docs.twitterapis.com/docs/reference/search/tweet-advanced-search) - [Verified Followers](https://docs.twitterapis.com/docs/reference/follower-graph/user-verified-followers) ## Resources / Compare - [Answers](/answers) - [Reviews](/reviews) - [Free Tools](/tools) - [Twitter ID Finder](/tools/twitter-id-finder) - [Get a Twitter API Key](/twitter-api-key) - [Official X API Comparison](/twitter-api-pricing) - [Twitter API Use Cases](/twitter-api-usecases) - [Twitter API Alternatives](/twitter-api-alternatives) - [Twitter Unofficial API](/twitter-unofficial-api) - [Twitter Free API](/twitter-free-api) - [TwitterAPIs vs twitterapi.io](/twitterapis-vs-twitterapi-io) - [TwitterAPIs vs GetXAPI](/twitterapis-vs-getxapi) - [TwitterAPIs vs TweetAPI](/twitterapis-vs-tweetapi) - [TwitterAPIs vs TwexAPI](/twitterapis-vs-twexapi) - [TwitterAPIs vs RapidAPI](/twitterapis-vs-rapidapi) ## Legal - [About](/about) - [Security](/security) - [Trust](/privacy-and-data-handling) - [Terms of Service](/terms-of-service) - [Affiliates](/affiliates) - [Contact](/contact) - [Jobs](/jobs) © 2026 TwitterAPIs. All rights reserved. TwitterAPIs is an independent third-party API for developers and researchers. Not affiliated with, endorsed by, or sponsored by X Corp. All systems operational