# How to Detect Bot Accounts on Twitter With an API Canonical: https://www.twitterapis.com/answers/detect-bot-accounts-on-twitter-api Description: There is no bot flag on the X API. Build a score from account age, follower ratio, cadence and audience quality for $0.0024 an account. Generated: 2026-09-02T20:48:39.740Z ---1. [Home](/) 2. / [Answers](/answers) 3. / How do you detect bot accounts on Twitter programmatically? # How do you detect bot accounts on Twitter programmatically? Last updated September 3, 2026 There is no bot flag on the X API, so detection means assembling signals yourself from account metadata and behaviour. Three reads carry most of the weight: user/info for age and follower ratio, user/tweets for posting cadence, and verified\_followers for audience quality. Each bills $0.0008, so screening 1,000 handles on all three costs $2.40. 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)). ## How do you detect bot accounts on Twitter programmatically? You assemble a score from public account metadata and behaviour, because no endpoint returns a verdict. Three reads carry most of the weight and each bills $0.0008: user/info gives account age, follower and following counts and post count; user/tweets gives posting cadence and how much of the output is original rather than retweeted; user/verified\_followers gives audience quality. Screening a thousand handles on all three costs $2.40. The work that decides whether the result is any good is not the fetching, it is the weighting: every individual signal has a large innocent population under it, so a rule built on one of them produces false positives at a rate that makes the whole thing useless. What follows is what each read gives you, how to combine them, what it costs at volume, and what to do with a positive. ## Is there an endpoint that just tells you if an account is a bot? The first thing to internalise is that no endpoint returns a boolean saying this account is automated. Platforms do not publish that judgement, partly because it would be immediately gamed and partly because automation is not itself against the rules. A scheduled posting tool, a support autoresponder and a coordinated inauthentic network are all automated, and only the last is what you usually mean. So any product that hands you a bot flag is running a classifier over the same public signals you can read yourself, and the useful question is not whether to score but whether you understand the scoring. Build it yourself and you control the threshold, you can inspect a false positive, and you can defend the decision to whoever it affects. That last property matters more than accuracy in most deployments, because a suspension or an exclusion you cannot explain is a support problem regardless of whether the model was right. ## Which signal is the strongest bot indicator? Posts per day since account creation, computed from account age and post count in a single user/info read. It needs no timeline call, it is one subtraction and one division, and the extreme tail is genuinely hard to explain innocently: an account averaging several hundred posts a day is not a person typing. That makes it the right first stage in a screen, because it rejects the obvious cases for a third of the cost of a full three-read pass. It is still not sufficient alone. High volume also describes a news aggregator, a sports-score account and a genuinely prolific poster, all of which are legitimate and all of which will sit in the same tail. Treat it as the cheapest discriminator rather than the verdict, and let the conjunction with ratio and audience quality do the actual deciding. ## How to use account age and post count to spot automation A single user/info call returns created\_at alongside statuses\_count, and the ratio between them is the most informative number on the page. Compute posts per day since creation rather than posts in the last week, because a dormant account that was repurposed last month will look quiet on a recent window and extreme on a lifetime one. Two shapes matter. A very young account with a very high lifetime rate is the classic disposable automation profile. An old account with a low lifetime rate but a sudden recent spike is the repurposed-account profile, which lifetime rate alone will miss, so if that case matters to you compute both and compare them. Account age also never changes, so cache it permanently and never re-read it, which is the single easiest saving in a repeated screen. ## What the follower to following ratio tells you The ratio separates accounts that are trying to be seen from accounts that are being seen. Following several thousand while being followed by a few dozen is the mass-follow pattern, and it is cheap to detect because both numbers arrive in the same user/info response you already paid for. The honest caveat is that the ratio is a poor signal at both ends of the size distribution. A brand new real person also follows more than follows them, because that is how you start a feed. A very large account has a ratio that tells you nothing except that it is large. The ratio earns its place in the middle of the distribution and in conjunction with cadence, not as a standalone rule, and any threshold you set on it should be validated against a hand-labelled sample from your own population rather than borrowed from a blog post. ## How to combine multiple signals into one score Each individual signal has a large innocent population sitting under it, which is exactly why single-signal rules produce so many false positives. A brand new account is usually a new user, not a bot. A high following count is a normal way to seed a feed. High volume describes a news account or a genuinely prolific poster. A default profile image describes somebody who has not finished onboarding. The signal is in the conjunction: a two week old account, following 4,000 while followed by 30, posting 200 times a day, almost entirely retweets, with an audience of accounts that share the same properties. Score rather than gate, weight the components deliberately, and set the threshold from a labelled sample you built by hand rather than from intuition. Then keep the sample, because it is what lets you tell whether a later change to the scoring made things better or merely different. ## What bot screening costs per account Each of the three reads bills at the standard $0.0008, so a full three-signal screen is $0.0024 an account. A thousand handles is $2.40 and ten thousand is $24, which is cheap enough that the interesting design question is not price but ordering. Run the cheapest discriminating signal first and stop early. Profile metadata alone rejects a large share of obvious cases for a third of the cost, so a two stage screen that only pulls a timeline for accounts surviving stage one typically cuts the bill substantially against screening everything on everything. Cache aggressively as well, because account age never changes and follower counts move slowly. Re-screening a stable account daily is spending for no new information. Screen on first sight, then re-screen on a schedule proportional to how much the decision matters. ## How often should you re-score an account? Re-score in proportion to what the score is used for, and cache the fields that cannot change. Account creation date is immutable, so read it once and never again. Follower and following counts move slowly for most accounts, so a weekly or monthly refresh is usually enough. Posting cadence is the field that moves, and it is also the one that catches the case re-scoring exists for: an account that was dormant and legitimate six months ago and is now posting two hundred times a day has changed hands or changed purpose. If the score only excludes an account from a metric, monthly is fine and the cost of being late is a slightly wrong number. If the score gates access to something, shorten the interval, because the cost of being late is a bad actor operating inside your system for however long the gap is. ## Using this to clean up your own follower count This is the best use of the technique, because the consequence is entirely reversible and the population is one you have standing to examine. Pull your own followers, screen them, and report an adjusted engaged-audience figure alongside the raw one rather than instead of it. Publishing both is what makes it analysis rather than spin, and the gap between them is usually the interesting number. Two cautions. Do not delete or block on the strength of a score alone, because a false positive there removes a real person who followed you on purpose. And do not publish a claim that a named third party's following is inflated: that is a different act with a different risk profile, it rests on a classifier you built from public metadata and cannot fully substantiate, and aggregate findings about a population carry the point without naming anyone. ## Do bot detection signals work in other languages? The structural signals travel and the text signals do not. Account age, posts per day, follower to following ratio and audience composition are arithmetic over numbers that mean the same thing everywhere, so they behave consistently across languages and regions. Anything reading the text does not: repetition detection tuned on English will behave differently on languages with richer inflection, and a heuristic keyed to Latin script will simply not fire on accounts posting in another one. The practical failure mode is subtle and worth naming, because it looks like success: an unvalidated threshold tends to over-flag whatever language groups were absent from the sample you tuned on, so the model appears accurate on your test set and quietly discriminates in production. If your population is multilingual, validate the threshold separately per language group and be prepared to hold different thresholds. ## What should happen when an account scores as a bot? A detection pipeline is a system that makes decisions about people, and it will be wrong sometimes in both directions. Decide in advance what a positive triggers, and prefer reversible consequences. Excluding an account from a metric is cheap to undo. Blocking, publicly labelling or reporting is not, and a false positive there costs a real person something. Keep the component scores rather than only the verdict, so a disputed case can be examined rather than re-litigated from scratch. Re-score on a schedule, because accounts change hands and dormant accounts get repurposed. And avoid publishing individual verdicts about named accounts: aggregate findings are defensible, while a public accusation about one named person rests on a classifier you built from public metadata and cannot fully substantiate. ## How to avoid false positives Three habits do most of the work. Keep the component scores rather than only the verdict, so a disputed case can be examined rather than re-argued from scratch, and so you can see which signal drove a wrong call. Build a hand-labelled sample from your own population before you set any threshold, because a threshold borrowed from someone else's corpus is calibrated to their mix of account types and not yours. And prefer reversible consequences at the top of the score range: excluding an account from a metric costs nothing if you are wrong, while blocking or publicly labelling one costs a real person something and is hard to undo. The uncomfortable arithmetic is that in most populations genuine automation is a small minority, so even a low false-positive RATE produces more wrong flags than right ones unless the threshold is set deliberately high. ## Signals, what each read gives you, and what it costs Signal Endpoint What it discriminates Cost per account Account age and post count user/info Implausible posts per day since creation $0.0008 Follower to following ratio user/info Mass following with little reciprocation Included above Posting cadence and retweet share user/tweets Machine-regular timing, low original content $0.0008 Audience quality user/verified\_followers A following composed of empty accounts $0.0008 Full three stage screen All three Conjunction of the above $0.0024 > Rate limits control the number of requests you can make to each endpoint. Exceeding limits results in a 429 error until the window resets. X Developer Platform, rate limits documentation. [Source](https://docs.x.com/x-api/fundamentals/rate-limits) ## Questions and answers Is there an endpoint that just tells me if an account is a bot? No, on any provider. Platforms do not publish that judgement, and automation is not by itself prohibited, so there is no field to expose. Every bot score you have seen is a classifier over public signals. Building your own means you can inspect a false positive and explain a decision, which usually matters more in practice than a small difference in accuracy. Which single signal is strongest? Posts per day since account creation, computed from account age and post count in a single profile read. It is cheap, it needs no timeline call, and the extreme tail is difficult to explain innocently. It is still not sufficient alone, because high volume also describes news accounts and aggregators, which is why it belongs in a conjunction rather than in a rule. What does screening cost at scale? $0.0024 an account for all three reads, so $2.40 per thousand and $24 per ten thousand. Order the checks so the cheapest discriminating one runs first and only pull a timeline for accounts that survive it, which usually cuts the bill by a large fraction because most obvious cases are rejected on profile metadata alone. Can I run this on a list of accounts I already have? Yes, and that is the usual shape. The three reads all key on a handle or a user id, so a screen is a loop over your list rather than a discovery problem. Order the reads so the cheapest discriminator runs first and only pull a timeline for accounts that survive it, which typically cuts the bill substantially because most obvious cases are rejected on profile metadata alone. Cache account age permanently, since it cannot change. Does a high score mean the account broke platform rules? No, and conflating the two is the most common misuse. Automation is not itself against the rules: scheduling tools, support autoresponders and syndication accounts are all automated and all legitimate. What your score measures is how machine-like the account's public behaviour looks, which is a different question from whether it is doing anything prohibited. Keep your own language precise for the same reason, and describe an account as scoring high on automation signals rather than as a bot. How large a labelled sample do I need to set a threshold? Enough to see the false-positive rate move, which in practice means a few hundred hand-checked accounts drawn from your own population rather than from a public bot dataset. Public datasets are useful for sanity checks and misleading for calibration, because their mix of account types is not yours. Label a sample, plot the flag rate across candidate thresholds, and pick the point where the wrong flags stop being acceptable for whatever the score gates. ## Keep reading - [Twitter user API](/twitter-user-api?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-detect-bot-accounts-on-twitter-api) - [Twitter followers API](/twitter-followers-api?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-detect-bot-accounts-on-twitter-api) - [How to get a Twitter user ID](/answers/how-to-get-a-twitter-user-id?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-detect-bot-accounts-on-twitter-api) - [How to get who a Twitter account follows](/answers/how-to-get-who-a-twitter-account-follows?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-detect-bot-accounts-on-twitter-api) ### 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-detect-bot-accounts-on-twitter-api)[See pricing](/twitter-user-api?utm_source=aio&utm_medium=organic&utm_campaign=aeo-answers-detect-bot-accounts-on-twitter-api) [ 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