FREE TOOL
Twitter Follow Checker
How do I check whether one X account follows another?
The Twitter Follow Checker is a browser tool that reads the follow relationship between two X accounts and reports it in both directions at once. Following is not symmetric, so the useful answer is really two answers: whether the first account follows the second, and whether the second follows back. Enter two handles and the tool resolves each to its numeric ID, then reads the live relationship between that pair.
Enter the accounts: handle, URL or ID
Each box takes an account in whatever form you have it. A bare handle works, with or without the leading @, and so does a profile link copied from the address bar on x.com or twitter.com, including the mobile and www variants. The tool strips the link down to the handle before it looks anything up. A value made only of digits is read as a numeric user ID instead, which is the form to use when you are checking an account whose handle has changed, because the ID survives a rename and the handle does not.
Order matters. Account A is the source and Account B is the target, so the first verdict answers whether A follows B and the second answers whether B follows back. Swapping the boxes swaps the two verdicts and nothing else. If a handle does not match any account the check stops at that step and says so, rather than reading a relationship for an account that is not there.
How fresh is the data?
As fresh as the moment you press the button. Every check runs its three reads live, in order, while you watch the step counter under the button, and the page keeps no copy of an earlier answer to serve you instead. There is no nightly crawl behind this tool and no database of follow edges that might be days old, which is the usual reason two follow checkers disagree about the same pair.
The practical limit on freshness is X itself. A follow or unfollow that happened seconds ago appears once X reflects it in the relationship it returns, and a check run before that point reports the earlier state. If an answer surprises you, run the same pair again a minute later. A result that flips between two runs is a change that was still settling, not a fault in either read.
No account access or X login
You never sign in to X here, never hand over a password, and never authorise an app against either account. The relationship between two public accounts is public information, so reading it needs no access to the accounts themselves. Neither account is followed, messaged or touched in any way, and neither is told that a check took place.
The only credential involved is a TwitterAPIs key, because the lookups are live reads and a read is billed to a key. A key you paste is used for that single request. It is not written to storage, not put in the URL and not logged. The route behind the page can reach exactly three read endpoints, profile by handle, profile by ID and the relationship read, so it cannot be pointed at a write action even by a crafted request.
What a follow relationship actually contains
A relationship read returns a directional record between a source account and a target account. The two fields that matter for most questions are following, which is true when the source follows the target, and followed_by, which is true when the target follows the source. A mutual follow is both fields true at once. The record also carries block, mute and DM-eligibility state, and those fields are populated only when the caller has an authenticated view that can see them, so treat a null in that group as unknown rather than as a negative answer.
If you need the full list rather than a single pair, the followers API pages the followers and following lists with a cursor, and the user API page covers the profile object that carries the follower counts.
Pick followers or following when you need the list
A pair check answers a yes or no question about two accounts you already know. When the question is open, who follows this account or who does this account follow, you want a list instead, and the direction decides the endpoint. GET /twitter/user/followers returns the accounts that follow someone, and GET /twitter/user/following returns the accounts they follow. Both page with a cursor and return full user objects, so every row arrives with its bio, counts and verification state rather than a bare ID. Keep paging until the users array comes back empty, because the follower graph keeps sending a cursor even on its last page.
Do not page a list to answer a pair question. X returns these lists in fixed chunks of at most about 100 accounts, so finding one name inside a 50,000-follower list is at least 500 calls, about $0.40, where a single relationship read is $0.0008. The reverse also holds: if you need the whole list anyway, one export is cheaper than thousands of pair checks. For a shorter, higher-signal list, GET /twitter/user/verified_followers returns only the verified accounts that follow someone.
The same check in code
The relationship endpoint accepts numeric IDs or handles. IDs are the stable choice for a script: resolve each handle once, store the ID, and reuse it, so a later rename cannot break the job.
curl "https://api.twitterapis.com/twitter/user/check_follow_relationship\
?source_user_id=745273&target_user_id=2178758961" \
-H "Authorization: Bearer YOUR_API_KEY"
# {"relationship":{"following":true,"followed_by":false, ...}}Resolve a handle to an ID first with the Twitter ID finder, or in code with the user info endpoint shown on the quickstart.
Three read calls per check, priced out
This page spends three reads on every check: one to resolve each account and one for the relationship. At $0.0008 a read that is $0.0024 a check, and it buys you a confirmation of which account each handle actually resolved to before the answer is shown. That is worth paying for when a human types the handles, because a typo that lands on a real but wrong account is the most common way to get a confident wrong answer.
A script does not need the extra reads. With IDs already stored, each pair is one call, so 1,000 pair checks cost $0.80 rather than $2.40. The endpoint also takes source_username and target_username directly and resolves them itself, and a handle that matches no account comes back as a 404 that is not billed. Failed calls are free in general, so a retry loop around a timeout costs time rather than credit.
Audit mutual follows across a whole team
A common job is checking who follows whom inside a known group: a company's staff accounts, a set of partners, or a shortlist of creators who are meant to amplify each other. Because one relationship read returns both directions, you only need each unordered pair once, which is n times n minus one, halved. Ten accounts make 45 pairs. Add ten reads to resolve the handles the first time and the whole audit is 55 calls, about $0.044.
Store the result as a small grid, one row per pair with the two booleans, and the gaps are obvious at a glance: the pairs where neither follows, and the one-way pairs where only one side followed. Re-running the same grid next month costs 45 calls, because the IDs are already stored, and a diff against the previous grid shows exactly which follows were added or dropped in between.
Unfollow tracking from snapshots
No read returns a list of who unfollowed an account, because an unfollow leaves nothing behind to read. What you can do is take snapshots. Page the account's followers on a schedule, store the set of user IDs, and compare each snapshot with the one before it. An ID present yesterday and missing today is an unfollow, or an account that was suspended or deleted, which you can tell apart by reading that profile once.
The cost scales with follower count, not with how often people unfollow. At most about 100 followers come back per page, so an account with 5,000 followers is at least 50 calls a snapshot, about $0.04, and a daily snapshot runs about $1.20 a month. Compare on IDs rather than handles, since a renamed follower would otherwise show up as one unfollow and one new follow. The follower export guide covers the paging loop and checkpointing in full.
Frequently Asked Questions
It resolves each account you enter into its numeric user ID, then reads the directional relationship between those two IDs from the check follow relationship endpoint. The result has two independent halves: whether A follows B, and whether B follows A. Those are separate facts, which is why a one-way answer is not enough to tell you whether a follow is mutual.
No. Both accounts are read through the public profile and relationship endpoints, which is the same information a person would see by opening the two profiles. Nothing is followed, liked, messaged, or written. This tool only makes read calls, and the proxy behind it is restricted to three read endpoints so it cannot perform a write action even if asked to.
Three read calls at $0.0008 each, so $0.0024 for one check. Two of those calls resolve the handles you typed into numeric IDs, so the page can show which account each handle actually matched before it reads the relationship. If you are running this at volume in your own code, resolve each account once, cache the ID, and every subsequent check on that pair is a single call.
Not from a single check, and not from any honest tool that has no history of your account. Unfollows are a difference between two points in time, so seeing one means somebody stored your follower list earlier and compared it to the list now. This tool answers the present-tense question for a specific pair. To build unfollow tracking, snapshot your followers on a schedule with the followers endpoint and diff consecutive snapshots yourself.
Because block, mute, and DM state are visible only to an authenticated session that has standing to see them. When the endpoint has no authenticated view of that pair it sends null rather than guessing, and this tool prints Not returned instead of turning a null into a No. A null means the answer was unavailable, which is a different statement from the answer being negative.
Yes, through the API rather than this page. The relationship endpoint takes one source and one target per call, so a bulk job is a loop over your pairs, ideally with the IDs already resolved and stored. To check one account against many, the batch version takes up to 100 targets in one request and bills per item checked. One rate ceiling applies, 600 requests a minute and 20 concurrent per key, and there is no monthly minimum, so the cost of a bulk run is simply the number of pairs times the per-call rate.
Next read
Continue exploring related pages:
Twitter API use cases
14 use cases from sentiment analysis to lead generation.
Twitter API answers
Short, sourced answers to the most common Twitter and X API questions.
Twitter timeline API
Pull an account's full posting history over one REST endpoint.
Twitter list API
Read list members and list timelines with the same Bearer key.