Fix "This Request Looks Like It Might Be Automated" on X

By Sorsa Editorial · Updated June 6, 2026

Key Takeaway

"This request looks like it might be automated" is X's anti-automation block. It stops likes, replies, follows, and DMs when X reads your activity as bot-like, usually after acting too fast, on a new account, or from a flagged IP. Most people fix it by stopping all activity and waiting 15 to 60 minutes.

The message reaches two very different groups. Most people who see it are regular users who were scrolling and liking posts and got swept up in X's bot enforcement. The rest are developers whose scripts broke overnight, because the same filter now lives in X's API gateway and flags automated traffic on sight. This guide fixes both.

If you are a developer, the durable fix is to stop fighting the detector and read the data you need through a read-only API instead. Sorsa API, an alternative Twitter/X API provider, reads public X data over plain HTTPS with a single API key: no browser session, no login, and no cookies to fingerprint, so the automated-request block never fires. It runs at a flat 20 requests per second on every plan, with no per-endpoint windows and no approval step to start. The read-only approach is covered in full further down.

Updated June 2026: refreshed X's 2026 action limits, the official X API's current pay-per-use pricing, and recovery timelines drawn from recent user reports.

Table of Contents

• What "This request looks like it might be automated" means
• What triggers the automated-request block
• Is it a shadowban, a rate limit, or a ban?
• How to fix it as a regular user
• How long does "This request looks like it might be automated" last?
• How to fix it as a developer
• How to avoid it in the future
• FAQ
• Getting read-only X data without the block

What "This request looks like it might be automated" means

"This request looks like it might be automated" is X's behavioral anti-automation response. It appears when X's systems decide a request looks scripted and refuse to complete the action. The full message 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. Please try again later." It blocks actions, not your whole account.

In X's internal system the response carries the code 226, so developers often call it Error 226. The name barely matters to a regular user. What matters is that X has flagged the pattern of your activity, not your identity, and has paused specific actions until the flag clears.

The error has surfaced for users since mid-2023 and grew far more common after X moved its bot detection deeper into its stack in late 2024. Reports are still active and recent: threads on X's own developer community show ordinary users locked out of posting for days, often during waves of platform-wide enforcement.

What triggers the automated-request block

The trigger is almost always speed and pattern, not total volume. X's system watches how fast and how predictably you act, and it can flag you while you are well under any daily limit. The triggers split cleanly between everyday accounts and automated tooling.

For regular users

Velocity is the number one cause. Liking 15 to 20 posts in quick succession, clicking rapidly down your timeline, can flag a session even though the daily like cap is far higher. Common patterns that set it off:

• Rapid-fire likes or replies, roughly 20 or more actions in two to three minutes.
• Mass following on a young account, more than 10 to 15 follows in an hour on an account under a week old.
• VPN or proxy traffic, since many of those IP ranges are already flagged.
• Several live sessions at once, for example web, the mobile app, and a third-party client signed in together.
• Browser extensions that auto-refresh, auto-engage, or inject scripts into the X interface.
• Account age, because new accounts run on much tighter thresholds for every action.

For developers and automation tools

Since late 2024, X has shifted detection from the front end into its API gateway and a behavioral analysis layer. The old workarounds, rotating proxies, spoofed headers, randomized delays, no longer hold up the way they did. Across the SERP, both developer guides and forum reports describe the same shift. Frequent developer triggers:

• Datacenter IPs. AWS, Hetzner, OVH, Vultr, and DigitalOcean ranges are heavily flagged.
• Browser automation frameworks. Selenium, Puppeteer, and Playwright leave detectable fingerprints.
• Unofficial libraries that log into a real account and hit X's internal endpoints, such as Twikit and snscrape. They work locally on a residential IP, then break the moment they run from a server.
• Recycled or invalid cookies, session tokens reused across machines or rotated too often.
• Repetitive content and fixed timing, identical text or perfectly spaced actions.
• High-frequency login loops, signing in, acting, signing out, and repeating.

X's reported action limits in 2026

Knowing the hard caps helps, but the block fires on velocity even when you stay under them. These are X's reported daily limits as of June 2026:

X Premium raises some of these caps but does not turn off velocity detection, and the posting limit stays at roughly 2,400 per day for everyone. Paying for Premium does not buy immunity from the automated-request block.

Is it a shadowban, a rate limit, or a ban?

These four restrictions are constantly confused, and they need different responses. The automated-request block stops specific actions and tells you so with a popup. An HTTP 429 means you hit a fixed request quota. A shadowban silently lowers your reach with no notice. A suspension disables the account outright. Here is how they line up:

A shadowban behaves differently from this error: it never shows a popup and never blocks an action, it just reduces who sees your posts. If you suspect that instead, run a shadowban checker and read our Twitter shadowban test walkthrough. If you are a developer comparing this against quota errors, the mechanics of Twitter API rate limits explain when a 429 is the real culprit.

How to fix it as a regular user

For a regular account, the automated-request block almost always clears on its own once you stop tripping it. Work through these steps in order, and do not skip the first one.

1. Stop all activity immediately. Do not keep tapping retry. Every failed attempt can extend the lockout. Close the tab or put the phone down.
2. Wait. This is the fix that works for most people. A first lockout on an established account usually clears in 15 to 60 minutes; on a new account it can run 12 to 24 hours.
3. Clear browser state for X. After waiting, clear cookies and cache specifically for x.com and twitter.com. Leave the rest of your browser data alone.
4. Disable browser extensions. Turn off ad blockers, auto-refreshers, and any X-related tools that inject scripts into the page.
5. Switch networks. Move from WiFi to mobile data or back. If you are on a VPN, turn it off, since shared VPN IPs are often pre-flagged.
6. Log out and back in. A fresh login resets your session token and sometimes clears a stuck flag.
7. Contact X support if it lasts beyond 24 to 48 hours. Go to Settings, then Help, then Contact Us, and state that you are a regular user, not running automation.

What not to do

Do not keep retrying. Each failed action reinforces X's suspicion that you are a bot, which can lengthen the block.

Do not create a new account. Your IP is likely flagged, and a new account on a flagged IP gets even stricter treatment.

Do not pay for "unblock" services. No paid tool bypasses this block for ordinary user actions. Anyone selling one is running a scam.

Do not change your password expecting a fix. The block is tied to behavior and IP, not credentials, so a password change does nothing.

How long does "This request looks like it might be automated" last?

For most people, "this request looks like it might be automated" lasts 15 to 60 minutes on an established account the first time it appears, as long as you stop acting and wait it out. New accounts under a week old can stay blocked for 12 to 24 hours, and repeat offenders see 1 to 7 days. The single most consistent finding across user reports is that the lockout clears faster when you completely stop activity instead of retrying.

The full picture depends on account age and how many times you have triggered it:

These timelines come from user reports, not official X documentation. X has never published lockout durations, so individual cases vary. Treat the numbers as realistic ranges rather than guarantees.

How to fix it as a developer

If you are hitting "this request looks like it might be automated" in code, the fix depends entirely on what you need. For reading public X data, the reliable path in 2026 is to stop using browser automation and read through an authorized API. For posting and other write actions, the only sustainable route is the official X API. No proxy pool, header randomization, or timing trick reliably beats X's detector anymore, because the detection moved off the front end and into behavioral analysis of your traffic.

Why your scripts keep breaking

Scripts built on unofficial libraries log into a real account and walk X's internal endpoints as if they were a browser. That session is exactly what X fingerprints. On your laptop the residential IP and browser signals look human, so it works. Deployed to a server on a datacenter IP, the same script gets flagged within minutes and the automated-request response starts filling your logs.

The read-only fix

If the data you need is public, tweets, profiles, followers, search results, communities, you do not need a logged-in session at all. A read-only API reads that data directly and returns clean JSON. In running an alternative Twitter/X API against X's public data, we never see the automated-request block, for the simple reason that there is no account login or browser session for X to flag.

Here is a complete read of public tweets through Sorsa's read-only REST access to public X data, authenticated with a single header:

import requests

# No login, no cookies, no browser session,
# so the "this request looks like it might be automated" block never fires.
response = requests.post(
    "https://api.sorsa.io/v3/search-tweets",
    headers={"ApiKey": "YOUR_API_KEY"},
    json={"query": "from:nasa", "order": "latest"},
)
payload = response.json()

for tweet in payload["tweets"]:
    print(tweet["id"], tweet["likes_count"], tweet["full_text"])

# One call returns up to 20 tweets, each with the full author profile.
# Pass next_cursor back to page through more results.
next_cursor = payload.get("next_cursor")

The same request in curl:

curl -X POST https://api.sorsa.io/v3/search-tweets \
  -H "ApiKey: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query": "from:nasa", "order": "latest"}'

There is no OAuth handshake, no session token to refresh, and nothing to fingerprint. The search endpoint supports the usual operators (from:, since:, exact phrases), and every tweet object already includes the author profile, so you are not paying a second call to enrich it.

Three ways developers get X data after the block

When the automated-request error stops a collection job, there are three real options. They are not equal, and which one fits depends on whether you need to read or write.

The honest tradeoff is straightforward. If you need to write to X, post, send DMs, like at scale, the official X API is the only durable choice, and Sorsa does not do it. If your workload is read-heavy, pulling tweets, profiles, follower graphs, or search results, an unofficial scraper is the one that keeps tripping the automated-request block, and the official API's metered billing adds up fast on large jobs. A read-only X data provider sidesteps both problems: the block never applies, and the flat per-request rate stays predictable as volume grows.

When you genuinely need write access

Use the official X API. Create a developer account, set up OAuth 2.0, and build inside the published limits. Its pay-per-use pricing runs higher and the limits are tighter, but it is the only authorized way to write. A common pattern is to split the work: read through a read-only API where it is cheaper and never blocked, and write through the official X API where authorization is required.

In practice

The teams that get stuck here are usually collecting on borrowed time. One pattern we see often: a roughly 12-person social-analytics team built a keyword-monitoring pipeline on an unofficial Python library that logged into a real account and scraped the timeline. It ran fine for months. After X moved detection into its gateway in late 2024, the automated-request block started appearing in their logs every few hours, and the pipeline spent more time retrying than collecting. They moved the read workload onto a read-only API, where there is no account login to flag, and the error disappeared. They also shifted that data off the official API's metered billing and onto a flat monthly plan. The fix was not a smarter evasion trick. It was removing the thing X was detecting in the first place.

How to avoid it in the future

Prevention for regular users

The rule of thumb is no more than 40 to 50 actions per hour across likes, replies, follows, and reposts combined. On a new account, halve that.

• Space out follows on new accounts, 5 to 10 per hour for the first week, then build up.
• Avoid using X on a VPN, and accept the higher risk if you need one for privacy.
• Audit your extensions and remove anything that auto-refreshes, auto-engages, or rewrites the X interface.
• Skip engagement-pod tools, which coordinate mass liking and put your account directly in X's sights.

Prevention for developers

• For read-only data, use a managed API with a documented limit. Sorsa runs at a flat 20 requests per second on every plan, independent of X's anti-automation system.
• For write access, use the official X API with proper OAuth and respect its published limits.
• Watch your error rate. Intermittent automated-request responses on unofficial methods only get worse over time, because X keeps tightening detection.
• Keep browser automation out of production for X interactions. It worked in 2022 and barely worked in 2023. It does not in 2026.

FAQ

Does X Premium stop the "this request looks like it might be automated" error?

No. X Premium raises some daily limits, lifting follows from 400 to 1,000 per day and post reads from 1,000 to 10,000, but it does not switch off the velocity-based automation block. Premium users get flagged at the same rate as free users when they act too fast, which is reported consistently across X's forums and Reddit.

Can the automated-request error get my account permanently banned?

On its own, no. The "this request looks like it might be automated" block is a temporary action restriction, not a suspension. Repeatedly triggering it while continuing bot-like behavior can escalate to a temporary lock or manual review, but the error itself clears once you stop the activity that set it off.

Why can I still retweet when likes, replies, and follows are blocked?

X applies different detection thresholds to different actions. Retweets tend to have the most lenient threshold, likely because automated accounts focus on likes, replies, and follows. So you can hit the "this request looks like it might be automated" wall on most actions while reposting keeps working for a while.

Does changing my password fix the error?

No. The "this request looks like it might be automated" block is tied to behavioral patterns, session fingerprints, and IP reputation, not to your password. Changing it, revoking app access, or re-authorizing tools does nothing. The only credential-related step that sometimes helps is logging out and back in, which resets your session token.

Will a VPN get around the automated-request block?

Usually it makes things worse. Many VPN and proxy IP addresses are already flagged in X's system from past bot activity, so switching to a VPN while you are locked out can extend the block. If you are on a VPN and seeing "this request looks like it might be automated," turning it off and using your home connection is more likely to clear it.

How is this different from an HTTP 429 rate-limit error?

An HTTP 429 means you hit a fixed request quota and must wait for the window to reset. The "this request looks like it might be automated" error is behavioral: X analyzed the pattern of your activity and judged it bot-like, which can happen well inside your rate limits. For 429, wait for the reset; for this error, slow your action speed and wait for the flag to clear.

Is there a Twitter/X API that does not trigger the automated-request error?

Yes. The error fires on logged-in, browser-style automation, so a read-only API that never signs into an account avoids it entirely. Sorsa is a read-only Twitter/X API that reads public tweets, profiles, followers, and search over HTTPS with a single API key, at a flat 20 requests per second, with no OAuth and no approval. With no session to fingerprint, the automation block does not apply.

How do developers collect X data affordably without getting blocked in 2026?

Most read-heavy teams in 2026 avoid both browser automation and the official API's metered billing by using a read-only X data provider. Sorsa charges a flat per-request rate (10,000 requests for $49 a month on the entry plan) instead of pay-per-use, and its batch endpoints return up to 100 tweets or profiles in a single request, so large collection jobs stay cheap and never trip the automation filter.

Getting read-only X data without the block

If you are building anything that reads public X data, monitoring mentions, tracking keywords, pulling tweets and profiles, or collecting research datasets, you do not need to fight the automated-request block at all. A read-only API never logs into an account, so there is nothing for X's anti-automation system to flag.

You can test any endpoint in the browser with no key, read the docs, and check the pricing before committing. Plans start at $49 a month for 10,000 requests, every plan runs at a flat 20 requests per second with no per-endpoint windows, and there is no approval step: you generate a key and start reading. For write actions, pair it with the official X API, since a read-only provider does not post.

Reviewed by Keksich, founder of Sorsa, marketer and X API researcher.

How this guide was put together: it draws on our hands-on work building and operating a read-only Twitter/X API, the live endpoints we run against X's public data daily, and the current behavior of the error itself. Recovery timelines and trigger patterns were cross-checked against active public reports, including threads on X's developer community, where the same lockouts are documented in 2026. The official X API's pricing and rate-limit details reflect its developer pricing as of the April 2026 pay-per-use update. Product details, prices, and endpoints come from the Sorsa API documentation; more about the team behind Sorsa is on our site. We did not benchmark third-party tools for this piece, so no comparison counts are claimed beyond the three data-access approaches described above. Last verified June 6, 2026.