How to Fix "This Request Looks Like It Might Be Automated" on Twitter/X
Key Takeaway
Error 226 is X's anti-automation filter. It blocks likes, replies, follows, and DMs when the platform detects bot-like action velocity -- not just daily limits. For regular users: stop all activity for 15-60 minutes, then resume slowly. For developers running scripts: the error means your request fingerprint is flagged. Switch to API-based data access or drastically reduce request frequency.
If you've hit this wall, you're not alone. The "This request looks like it might be automated" message has plagued millions of X users since mid-2023, and it got significantly worse after the platform's anti-bot crackdown in late 2024. The error strikes two very different groups: regular users who got caught in the crossfire while just scrolling and liking posts, and developers whose automation scripts broke overnight.
This guide covers both sides. We'll break down the exact triggers, realistic recovery timelines based on hundreds of user reports, and long-term prevention strategies. If you're a developer dealing with Error 226 on data collection scripts, we'll also explain why read-only API access (like what Sorsa API provides) sidesteps the problem entirely -- you never interact with X's frontend, so the anti-automation filter never fires.
Last verified: April 2026
Table of Contents
- What Is Twitter Error 226?
- What Triggers Error 226?
- What Error 226 Is NOT
- How to Fix Error 226 as a Regular User
- How Long Does Error 226 Last?
- How to Fix Error 226 as a Developer
- How to Avoid Error 226 in the Future
- FAQ
- Getting Started with Read-Only X Data
What Is Twitter Error 226?
Error 226 is X's official anti-automation response code. Its full name in X's internal system is AuthorizationError with code 226 and kind Permissions. When it fires, you see this 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."
The error can block virtually any action: likes, replies, new tweets, follows, DMs, bookmarks, and even profile edits. But here's a pattern that confuses people -- it often still allows retweets while blocking everything else. This is because X's enforcement logic treats each action type with separate detection thresholds. Retweets appear to have the most lenient threshold, which is why you can still retweet while being locked out of replies and likes.
Error 226 is a behavioral detection mechanism, not a simple daily quota. X doesn't just count how many actions you've taken today -- it analyzes the velocity, timing patterns, IP characteristics, session fingerprints, and account history of every request. You can be well within your daily limits and still trigger it by acting too fast.
The system was first widely reported during the rate limit crisis of July 2023, when X implemented aggressive throttling to combat bot traffic. It was significantly hardened in late 2024, with detection logic moving deeper into X's API gateway and behavioral analysis engine.
What Triggers Error 226? The Real Causes
The triggers differ significantly depending on whether you're a regular user or a developer running automated scripts.
Triggers for Regular Users
Velocity is the #1 trigger. Even 15-20 likes in quick succession -- clicking through your timeline rapidly -- can flag your session. X's system cares more about speed than total volume.
Specific patterns that trigger the error:
- Rapid-fire likes or replies -- 20+ actions in 2-3 minutes, even if you're well under daily limits
- Mass following on a new account -- following more than 10-15 people in an hour on an account less than a week old
- VPN or proxy usage -- many VPN IP addresses are already flagged in X's system
- Multiple simultaneous sessions -- being logged in on web, mobile app, and a third-party client at the same time
- Browser extensions -- auto-refreshers, ad blockers that interfere with X's scripts, or "engagement boost" extensions
- Account age -- new accounts (under 30 days) have dramatically tighter thresholds across all actions
Triggers for Developers and Automation Tools
Since late 2024, X has moved its detection logic from the frontend into its API gateway and behavioral analysis engine. This means traditional workarounds (rotating proxies, spoofed headers, randomized delays) are far less effective than they used to be.
Common developer triggers:
- Datacenter IPs -- AWS, Hetzner, OVH, Vultr, DigitalOcean IP ranges are heavily flagged
- Browser automation frameworks -- Selenium, Puppeteer, Playwright all leave detectable fingerprints
- Unofficial libraries -- Twikit, snscrape, and similar tools that hit X's internal endpoints without proper session management. The Twikit GitHub issue #170 documents this exact error in detail.
- Invalid or recycled cookies -- session tokens that have expired, been used across machines, or rotated too frequently
- Repetitive content patterns -- identical text, fixed posting intervals, or predictable action sequences
- High-frequency login attempts -- logging in, performing an action, logging out, and repeating
X's Action Limits (April 2026)
Understanding the hard limits helps you stay under them, but remember: Error 226 triggers on velocity even when you're within these daily caps.
| Action | Free account | X Premium | Short-window limit |
|---|---|---|---|
| Posts (tweets + replies + reposts + QTs) | 2,400/day | 2,400/day | ~50 per 30 minutes |
| Post reads (timeline scrolling) | 1,000/day (500 for new accounts) | 10,000/day | -- |
| Follows | 400/day | 1,000/day | ~40-50 per hour |
| Likes | ~1,000/day | ~1,000/day | Aggressive velocity detection |
| DMs sent | 500/day | 500+ (undisclosed) | -- |
Note that X Premium does not raise the posting limit (still 2,400/day) and does not disable velocity-based Error 226 detection. Premium users get flagged just as often as free users when they act too fast.
What Error 226 Is NOT
People in forums and comment threads routinely confuse Error 226 with other X restrictions. Here's how they differ:
| Error 226 (anti-automation) | HTTP 429 (rate limit) | Shadowban | Account suspension | |
|---|---|---|---|---|
| What it means | X thinks your behavior looks scripted | You've hit a hard request quota | Your content is deprioritized in feeds/search | Your account is disabled |
| What triggers it | Action velocity + behavioral fingerprinting | Exceeding published API rate limits | Unclear -- content quality signals, spam reports | Repeated ToS violations |
| What's blocked | Specific actions (likes, replies, follows) | All API requests until reset | Nothing is blocked -- just hidden | Everything |
| You get notified? | Yes -- the "automated" popup | Yes -- HTTP 429 response | No -- that's the point | Yes -- email + in-app notice |
| Duration | Minutes to days | Resets on schedule (15 min for API) | Indefinite | Until appeal is resolved |
| Action needed | Wait + slow down | Wait for reset window | Unclear -- modify content strategy | File appeal |
If you're unsure whether you're shadowbanned, X's behavior is different from the Error 226 popup. A shadowban silently reduces your visibility without telling you. You can check your account status using a shadowban checker tool.
How to Fix Error 226 as a Regular User
If you've just been hit with the "This request looks like it might be automated" message, here's what to do -- in order:
1. Stop all activity immediately. Don't keep clicking retry. Every failed attempt can extend the lockout duration. Close the tab, put down your phone, and walk away for a bit.
2. Wait. This is the fix that actually works for most people. The lockout duration depends on severity:
- First occurrence on an established account: 15-60 minutes
- First occurrence on a new account: 12-24 hours
- Repeat occurrence: see the timeline table below
3. Clear your browser state. After waiting, clear cookies and cache specifically for x.com and twitter.com. Don't nuke all your browser data -- just the X-related entries.
4. Disable browser extensions. Temporarily turn off all extensions, especially ad blockers, auto-refreshers, and any Twitter/X-related tools. Some extensions inject scripts that interfere with X's frontend and trigger detection.
5. Switch networks. If you're on WiFi, switch to mobile data (or vice versa). If you're on a VPN, turn it off. Some IP addresses are flagged from previous abuse by other users on the same network.
6. Log out and back in. This resets your session token. If the error persists after steps 1-5, a fresh login sometimes clears a stuck flag.
7. File a support ticket (if it lasts 24-48+ hours). Go to Settings -> Help -> Contact Us. Describe the error and mention that you're a regular user, not running automation. X's support is slow, but for persistent cases it's the only escalation path.
What NOT to Do
Don't keep retrying. Every failed action attempt reinforces X's suspicion that you're automated. The worst thing you can do is mash the like button 50 times hoping it works.
Don't create a new account. Your IP is likely flagged. A brand-new account on a flagged IP gets even stricter treatment -- new accounts already have tighter thresholds.
Don't pay for "unblock" services. There is no hack, no secret code, no paid tool that bypasses Error 226 for regular user actions. Anyone selling this is running a scam.
Don't change your password expecting it to help. Error 226 is tied to behavioral patterns and IP, not to your credentials. Several Reddit threads confirm that changing passwords does nothing.
How Long Does Error 226 Last?
This is the #1 question in every forum thread about the error, and the answer frustrates people: it depends. Based on aggregated reports from Reddit, the X Developer Community forums, and GitHub issues, here are realistic timelines:
| Scenario | Typical duration | What to do |
|---|---|---|
| First time, established account (30+ days old) | 15-60 minutes | Wait it out, resume slowly |
| First time, new account (under 7 days) | 12-24 hours | Don't touch the account for a full day |
| Second/third occurrence, established account | 1-3 days | Permanently reduce your action speed |
| Repeat occurrence, new account | 3-7 days | Some users report 2+ weeks |
| Chronic developer/automation trigger | Indefinite | Must change your approach entirely |
| Persistent case (months) | Rare, but documented | File support ticket; some users report 5+ months |
A few important notes on these numbers:
The timelines above are based on user-reported data from public forums, not official X documentation. X has never published official Error 226 lockout durations. Individual cases vary. The single most consistent finding across all reports: the lockout resolves faster if you completely stop all activity during the wait period. Users who keep retrying during the lockout consistently report longer recovery times.
How to Fix Error 226 as a Developer
If you're hitting Error 226 in code -- whether through Twikit, Selenium, Puppeteer, custom Python scripts, or any other automation tool -- the fix depends entirely on what you're trying to do.
Why Your Scripts Keep Breaking
X fundamentally changed its anti-automation architecture in late 2024. Detection moved from client-side JavaScript checks into the API gateway itself, where X now profiles every request across multiple dimensions: cookie entropy, signature tokens, device history, IP reputation, and behavioral patterns.
What this means in practice: the old playbook is dead. Rotating proxies, spoofing User-Agent headers, adding random delays between actions -- these techniques worked in 2023. They don't work reliably anymore. Even Twikit, the most actively maintained Python library for X scraping, regularly throws Error 226 on write operations. Users on GitHub issue #170 report that retrying 1-2 times after a few seconds sometimes works, but it's unreliable and degrades further over time.
The Write-Access Problem
If your use case requires posting, liking, following, or DMing programmatically, there is no clean workaround in 2026. Some services market themselves as "API bridges" that handle authentication and cookies for you, letting you post tweets through their infrastructure. These services work by logging into X with your credentials (or stolen session cookies) and mimicking browser behavior from their servers.
Be clear about what this is: you're handing your login credentials to a third party and relying on reverse-engineered, unofficial access that violates X's Terms of Service. Your account is at risk of permanent suspension. The service itself can disappear overnight when X patches whatever exploit they're using.
If you genuinely need write access at scale, the only legitimate path is the official X API v2. It's expensive. The rate limits are strict. But it's the one write-access method that won't get your account banned.
The Read-Only Solution
Here's what many developers miss: if your actual use case is reading data -- monitoring keywords, collecting tweets, analyzing user profiles, pulling engagement metrics, researching trends -- then Error 226 is a problem you can eliminate entirely.
The reason is straightforward. Error 226 triggers when your account performs actions on X's frontend or through unofficial endpoints. A read-only API like Sorsa API doesn't use your X account at all. It handles data retrieval on its own infrastructure, returning clean JSON through standard REST endpoints. Your application sends an HTTP request with an API key; you get structured data back. No cookies, no sessions, no browser fingerprinting, no Error 226.
Here's the contrast. This Twikit code triggers Error 226:
# Twikit approach -- vulnerable to Error 226
import twikit
client = twikit.Client()
await client.login(auth_info_1='username', password='password')
tweets = await client.search_tweet('python API', product='Latest')
# twikit.errors.CouldNotTweet: Authorization: This request looks like
# it might be automated. (226)
This Sorsa API call does the same data retrieval with zero Error 226 risk:
# Sorsa API approach -- no browser automation, no Error 226
import requests
response = requests.post(
"https://api.sorsa.io/v3/search-tweets",
headers={"ApiKey": "your_api_key"},
json={"query": "python API", "order": "latest"}
)
tweets = response.json()["tweets"]
# Clean JSON with full tweet data, user profiles, engagement metrics
Sorsa API covers 38 endpoints across user profiles, tweets, search, followers, communities, and lists. Every endpoint is read-only, authenticated with a single API key in the header, and priced per request (not per data unit) -- so a batch call fetching 100 tweets costs the same as fetching one. Detailed endpoint documentation is at docs.sorsa.io.
When You Genuinely Need Write Access
Use the official X API v2. Create a developer account at developer.x.com, set up OAuth 2.0, and build within X's published rate limits. It costs more and the limits are tighter, but it's the only write-access method that's sustainable long-term.
For hybrid workflows -- read data via Sorsa API (cheaper, faster, no 226 risk), write via official X API (authorized, compliant) -- you get the best of both worlds.
How to Avoid Error 226 in the Future
Prevention for Regular Users
The rule of thumb: no more than 40-50 actions per hour. This applies to all action types combined -- likes, replies, follows, retweets. If you're on a new account, cut that in half.
Specific prevention tips:
- Space out follows on new accounts. 5-10 per hour for the first week. Build up gradually.
- Don't use X on VPN. If you need a VPN for privacy, accept that it increases your Error 226 risk.
- Audit your browser extensions. Remove anything that auto-refreshes, auto-engages, or modifies X's interface.
- Avoid "engagement pod" tools. Services that coordinate mass liking/retweeting put your account directly in X's crosshairs.
Prevention for Developers
- For read-only data needs: use a managed API. Sorsa API's rate limit is 20 requests/second across all endpoints -- consistent, documented, and independent of X's anti-automation system.
- For write access: use the official X API with proper OAuth and respect published rate limits.
- Monitor your error rates. If you're seeing intermittent 226 errors on unofficial methods, they will only get worse. X is tightening detection, not loosening it.
- Never deploy browser automation to production for X interactions. It worked in 2022. It barely worked in 2023. It doesn't work in 2026.
FAQ
Does X Premium protect against Error 226?
No. X Premium raises some daily limits -- follows go from 400 to 1,000/day, post reads from 1,000 to 10,000/day -- but it does not disable velocity-based Error 226 detection. Premium users report getting flagged at the same frequency as free users when acting too fast. Multiple Reddit threads from 2023-2025 confirm this, including users paying for X Premium / Twitter Blue who still hit the block.
Can I get permanently banned from Error 226?
Error 226 alone doesn't lead to permanent suspension. However, repeatedly triggering it while continuing bot-like behavior can escalate. X's moderation system treats persistent 226 triggers as a signal that your account may be automated, which can lead to temporary restrictions or manual review. If you stop the triggering behavior, the error resolves on its own.
Why can I still retweet but nothing else?
This is one of the most common -- and most confusing -- patterns. X's enforcement logic applies different detection thresholds per action type. Retweets appear to have the most lenient threshold, possibly because bots typically focus on likes, replies, and follows rather than retweets. So even when you're locked out of likes, replies, follows, and DMs, retweets often still work.
Does changing my password fix Error 226?
No. The error is tied to behavioral patterns, session fingerprints, and IP reputation -- not to your credentials. Changing your password, revoking app access, and re-authorizing third-party tools have no effect on Error 226. The only credential-related action that sometimes helps is logging out and back in (which resets your session token).
Is Error 226 the same as a shadowban?
No. They're completely different mechanisms. Error 226 actively blocks your actions and shows you a visible error message. A shadowban silently reduces the visibility of your content without notifying you -- you can still post, like, and follow normally, but fewer people see your content. If you're unsure whether you're shadowbanned, use a shadowban checker.
Will a VPN help bypass Error 226?
Usually the opposite. Most VPN IP addresses are flagged in X's system because they've been used by bots and spam accounts. Switching to a VPN when you're already locked out can extend the lockout. If you're currently on a VPN and getting Error 226, turning it off and using your regular ISP connection is more likely to help.
I'm a developer -- should I switch from Twikit to another library?
It depends on your use case. If you need read-only access to X data (search, profiles, tweets, followers), switching to a managed API like Sorsa API eliminates Error 226 entirely because you never interact with X's frontend. If you need write access (posting, liking), no unofficial library is reliable in 2026 -- Error 226 affects Twikit, Tweepy, custom Selenium scripts, and every other approach that reverse-engineers X's internal endpoints.
How is Error 226 different from HTTP 429?
HTTP 429 means you've exhausted a hard request quota -- X's API has a fixed number of allowed requests per time window, and you've used them all. Error 226 is a behavioral detection -- X's system analyzed the pattern of your requests and decided they look automated. You can get Error 226 while being well within your rate limits, simply by acting too fast. The fixes are different: for 429, wait for the rate limit window to reset. For 226, slow down your action velocity and wait for the behavioral flag to clear.
Getting Started with Read-Only X Data (No Error 226)
If you're building an application that needs X data -- monitoring mentions, tracking keywords, analyzing engagement, collecting research data -- you don't need to fight Error 226 at all.
Sorsa API provides read-only REST access to public X data: user profiles, tweets, search, follower graphs, communities, and lists. Authentication is a single API key in the header. Pricing is flat per request with no per-endpoint multipliers. You can test any endpoint in the browser-based playground before committing to a plan, and the full API reference is at docs.sorsa.io.
Disclosure: Sorsa API is our product. We've aimed to keep this guide useful regardless of which tools you use, and the troubleshooting advice for regular users applies whether you know Sorsa API exists or not.