Twitter "This Request Looks Like It Might Be Automated" — Error 226, and How to Fix It

Error 226 is X's automation block. X runs automation checks on the client that made the login request (and on later requests from that client), and when the activity looks like a script rather than a person, it returns the block instead of the content or action you asked for.

Critical distinction — the 226 is in the response body, not the HTTP status. The transport-layer status code your client receives is HTTP 403 Forbidden. The string 226 is the X-specific error code carried in the JSON body — typically {"errors":[{"code":226,"message":"This request looks like it might be automated..."}]}. RFC 7231's HTTP 403 means "server understood the request, but refuses to authorize it"; X uses 226 as its app-level identifier for why it refused. A correct error handler reads both layers: branch on HTTP status first (403 vs 401 vs 429), then on body code (226 vs other 4xx X error codes) for the precise reason.

It is not just about credentials. A correctly authenticated request can still return 226 if the behavior around it looks scripted. Equally, a real person on a VPN or a fresh device can get it as a false positive.

What 226 is not: it is not the rate-limit error — that is HTTP 429 with body code 88, and it has its own page. It is not an authentication error — that is HTTP 401. And note that HTTP 226 itself is a real but unrelated HTTP status (RFC 3229's "IM Used" for delta encoding); X is not returning that, and confusing the two costs you debug time. 226-in-body always rides on HTTP 403. It is also not the sign-in refusal that tells you to use the official X app (LoginError.AttestationDenied); that is a device and app integrity check at log-in, covered in our guide to the official X app sign-in error.

If you are searching for the wording to find this page, here are the variants — they all mean error 226:

In the web or mobile app: a banner or modal that reads "This request looks like it might be automated. To protect our users from spam and other malicious activity, we can't complete this action right now." Usually with no obvious way to dismiss it.

In an API response: the JSON body carries {"errors":[{"code":226,"message":"This request looks like it might be automated. To protect our users from spam and other malicious activity, we can't complete this action right now. Please try again later."}]}

In a Python script using tweepy: a tweepy.errors.Forbidden or generic API error containing the 226 code and message in its body.

In a browser-automation tool (twikit, browserless scrapers): typically a navigation error or a redirected page that loads only the block screen. The underlying response is the same 226.

Before changing anything, work out where the block came from. Three questions settle it:

Was a script involved? If a bot, scraper, browser-automation tool or library logged in as your account, the 226 is about that script. If you were only using the official app or website by hand, it is most likely a false positive.

Where did it appear? In the app it shows as a banner on an action such as posting, following or logging in. In code it shows as HTTP 403 with code 226 in the body. A 429 with code 88 is a rate limit, and a 401 is an authentication problem; neither is 226.

What changed recently? A new device, a VPN or Tor connection, a burst of likes or follows, or a newly deployed script are the usual triggers. Whatever changed just before the first 226 is the thing to undo.

If you are not running a bot or a scraper, this is almost always temporary. In order:

Stop the action that triggered it. If you were on a burst (many likes, follows or replies in a short window), pause. Retrying the same action over and over keeps the block in place.

Wait. The block often clears on its own within minutes to a few hours, once your activity looks normal again.

Recover the account. Add a phone number and confirm your email if you have not. If X shows a captcha or SMS challenge, complete it; that usually lifts the block immediately. If you are on a VPN or Tor, switch to your normal connection and try again.

Do not install a "fix". Tools that ask for your password, install browser extensions or route your traffic through their servers are either scams or a fast route to a permanent suspension. The verification path is the only safe one.

If your tweepy / twikit / Selenium / Puppeteer script started returning 226, treat it as a signal about the script, not a puzzle to solve. The script is logging in as a real account and producing traffic X does not allow from a user session.

Stop the script now. Kill the job, the cron entry and any retry loop. Every further attempt from the same account adds to the record that triggered the block, and repeated attempts are what move an account from a temporary block toward a lock or suspension.

Wait, then recover the account by hand. Give it a few hours. Then log in through the official app or website, complete any verification X asks for, and change the password if the script stored it somewhere. Revoke any session cookies or tokens the script held.

Do not restart the same script. Proxies, new user agents and slower loops change how the traffic looks, not what it is: an automated client acting as your account. The same account will hit the same wall, and the account is what you stand to lose.

Read public data through an API key instead. If the script existed to collect public posts, profiles or searches, that part does not need your X login at all. It can run through a data API that you authenticate with a key, which keeps your personal account out of the pipeline entirely.

The path most developer projects end up on is moving the public-data read off the logged-in account entirely and onto an API you call with a key.

TwitterAPI.io is one of those APIs. You authenticate with an X-API-Key header, not an X login, so there is no account of yours for X to block, and a busy script gets data back instead of 226. Tweet endpoints cost $0.15 per 1,000 tweets returned, pay-per-use with no monthly minimum.

The cost is easy to reason about. A project pulling 100,000 posts a month costs about $15 at that rate. For comparison, the official X API lists $0.005 per post read (docs.x.com/x-api/getting-started/pricing), which is about $500 for the same 100,000 posts.

It is not the right path for every project. If you need ads data or other official-only data, the official API is the only route, and a write action (posting, following) always runs as an X account whichever API sends it. For the common case of reading public posts, profiles and searches, an API key removes the account from the equation. See the pricing page for the per-result rates; an API key is one Google sign-in, and new accounts that pass the automatic bot check get up to $1 of free credits (at most 100,000 credits, one per person or network, expiring after 31 days), enough for end-to-end testing.

The snippet below replaces a logged-in script with a single keyed API call that returns the same kind of data. The endpoint is /twitter/user/last_tweets: one HTTP GET, no browser, no X login.

Swap the userName for any public account and the same pattern collects its timeline. For broader collection (keywords, hashtags, multi-account watchlists), the search endpoint takes a full advanced-search query — same shape, same predictability.