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

Error 226 is X's automation-detection block. The platform runs behavioural analysis on every request — request patterns, cookies, headers, IP signals, the cadence and shape of your activity — and when the combined signature looks enough like an automated client, it returns the block instead of the content 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 authorise 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 trigger 226 if the behaviour around the request looks scripted. Equally, a misconfigured browser or VPN can trigger it on a real human — false positives are the trade-off X chose to keep automation suppressed.

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.

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.

X's anti-automation push is deliberate and not reversing.

Behavioural profiling, not IP profiling. Detection used to be IP-based — block a known scraper IP, done. It now runs on the full request signature: timing, header order, TLS fingerprint, cookie consistency, mouse-and-scroll patterns on the web. A clean IP with the wrong signature still gets blocked; a normal residential IP from a real browser session usually does not.

Anti-bot is a platform priority. Since the ownership change, suppressing automation has been one of the platform's stated priorities — both to fight spam and abuse, and as part of the broader move to paid API access. The walls that frustrate legitimate scrapers also push developer use onto the paid API, which is the strategic direction.

False positives are accepted. Real users do get hit by 226 — a clean install of the app on a new device, a VPN connection, a burst of normal-looking activity. The platform tolerates that cost; the trade-off has been chosen.

If you are not running a bot or a scraper, this is almost always temporary and resolvable. In rough order of effectiveness:

Wait. The block often clears on its own within minutes to a few hours. If the action that triggered it was a one-off, the system usually backs down once your subsequent activity looks normal again.

Verify your account. Add a phone number and confirm an email if you have not. Verified accounts are flagged far less aggressively because the platform has more confidence that you are a real person. A captcha or SMS challenge may appear automatically — completing it usually lifts the block immediately.

Turn off the VPN or Tor. VPN and Tor connections are heavy 226 triggers. If you are using one, switch to your normal connection and try again — most VPN-driven 226s clear instantly.

Reduce activity rate. If you were on a burst — many likes, follows or replies in a short window — slow down. The behaviour was the trigger, not the credentials.

Do not try to "bypass" it. Searches for bypasses turn up tools that ask for your credentials, install browser extensions, or proxy your traffic — most are either scams or will get the account permanently suspended for going around the block instead of resolving it. The verification path is the only safe one.

If your tweepy / twikit / Selenium / Puppeteer script suddenly started returning 226 in production, the story is different. The patches that used to work — rotating proxies, randomising headers, slowing the request rate — were calibrated against an IP-based detector that no longer exists. The behavioural detector sees through them.

Three things that look like fixes but no longer are:

Proxies. Rotating residential or datacentre proxies used to reset the IP-block. Detection moved up the stack — request signatures, cookie histories and timing patterns persist across IPs, so a new IP alone does not look like a new user.

Header and user-agent spoofing. Browsers leak many signals beyond user-agent — TLS fingerprint, header order, JS environment quirks, screen and timezone. Matching one or two is easy; matching all of them consistently across a real session is harder than building the data pipeline you actually wanted.

Slowing down the script. Going from one request per second to one per minute helps a little against pure rate-based detection. Against behavioural detection that fingerprints your client, it just makes the block take slightly longer to land.

Building and maintaining a scraper that stays ahead of 226 has become a full-time job, and the platform has more engineers on the other side of the wall than you do. The economics stop making sense well before the technical fight does.

The path most developer projects end up on, once they have exhausted the patches, is moving the public-data read off scraping entirely and onto a compliant API.

TwitterAPI.io is one of those APIs. It reads public X data through authenticated, compliant channels — there is no anti-bot wall to fight, and a busy script does not collect 226 blocks instead of tweets. Pricing is pay-per-use at about $0.15 per 1,000 tweets with no monthly minimum, so cost scales with what you actually pull.

The economics usually break decisively in the API's favour. A project pulling 100,000 posts a month runs about $15 on a pay-per-call API, against a typical residential-proxy infrastructure bill of several hundred dollars a month — and that proxy spend buys you a fight you are still slowly losing. The engineering time spent on "just one more proxy" is the larger cost, but the dollar comparison alone usually settles it.

It is not the right path for every project. If you genuinely need write access, ads metadata or other official-only data, the official API remains the only route. For the much more common case — pulling public posts, profiles, searches — a compliant data API removes the 226 problem entirely. See [the pricing page](/pricing) for the per-call rates; an API key is one Google sign-in and a trial credit covers end-to-end testing.

The snippet below replaces a scraper that was returning 226 with a single API call that returns the same kind of data. The endpoint is /twitter/user/last_tweets — one HTTP GET, no browser automation, no anti-bot tripwires.

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.