On 23 February 2026, X restricted programmatic replies through its API. This page sets out what the rule actually covers, what it leaves open, and what X's own rules say about the alternatives, with every source linked so you can check it yourself.
On 23 February 2026, X stopped letting apps on its self-serve API tiers reply to arbitrary posts. A reply sent through the X API v2 create-post endpoint is now permitted only where the author of the original post has, in X's phrasing, summoned the replying account, by @mentioning it or by quoting one of its posts.
Here is the rule in X's own words, from the announcement X staff posted on the X developer forum.
"Previously, the POST /2/posts endpoint allowed any authenticated user/app to reply to any post by specifying in_reply_to_tweet_id. Moving forward, replies via the API will only be permitted if the replier has been explicitly summoned by the original post's author." X Developer Platform Team, X API v2 Update: Addressing LLM-Generated Spam, 23 February 2026.
"If neither condition is met, attempts to post a reply via the API will be blocked/rejected." Same announcement.
One correction worth making up front, because most of the posts written about this change get it wrong in the same direction. The reply restriction was not unannounced, and it was not documented only second-hand. X published it on three first-party channels on the day it took effect. Every one of them is public and takes half a minute to check.
The changelog entry is the most compact statement of the whole change.
"Today, we made changes to reduce automated, low-quality replies on X. Programmatic replies via POST /2/tweets are now only permitted when the original Post's author has 'summoned' the replier (by @mentioning that account or quoting one of its Posts). Additional restrictions apply to programmatically @mentioning or quoting users. These changes affect self-serve tiers only - Enterprise access is not impacted." X API changelog, Feb 23, 2026.
The @XDevelopers post adds one detail the forum announcement and the changelog do not carry, an exemption for what X calls Public Utility apps.
"To help address automated reply spam, programmatic replies via POST /2/tweets are now restricted for X API. You can only reply if the original author @ mentions you or quotes your post. Non-replies will remain unchanged. Applies to Free, Basic, Pro, Pay-Per-Use. Note: Enterprise & Public Utility apps are not impacted." @XDevelopers, 24 February 2026.
Some tools broke before the announcement landed. A developer opened a thread titled "Pay-Per-Use App Muzzled" at 14:40 UTC on 23 February, roughly nine hours before X posted the announcement, reporting a 403 and the message "Application cannot perform write actions". X staff replied that the app had been limited "due to violating X Developer rules and policies, specifically around sending unsolicited @mentions". That thread is still readable in full.
This is the part most write-ups blur. The restriction is narrower than "X blocked API replies" and wider than "replies only".
| Action through the X API on a self-serve tier | Status after 23 February 2026 | Where X says so |
|---|---|---|
| Reply to a post by an author who has not mentioned or quoted you | Blocked | Forum announcement and changelog |
| Reply to an author who @mentioned you, or who quoted one of your posts | Still permitted | Forum announcement |
| Reply to your own post, including self-threading | Still permitted | X staff, forum thread 257955 |
| Post an ordinary, non-reply post | Still permitted, but see the two rows below | @XDevelopers |
| @mention someone outside the conversation, including in an ordinary non-reply post | Blocked, and this wave was not announced when it shipped on 28 February | X staff, forum thread 258356 |
| Quote a post from an account other than your own | Blocked, reported by developers as undocumented in March | Forum thread 259927 |
| Reply programmatically on Enterprise access | Not impacted, per X | Forum announcement |
Details above reflect X's published documentation and X staff statements at the time of writing and can change. Confirm current behaviour on X's API changelog and the X developer forum.
The restriction sits on the X API v2 create-post endpoint, and the trigger is the in_reply_to_tweet_id parameter. X refers to that endpoint by two names in its own materials, which is where a lot of confusion comes from. The changelog and the @XDevelopers post call it POST /2/tweets; the forum announcement calls it POST /2/posts. These are the same endpoint under two names, not two different changes.
The tiers affected are the self-serve ones. X's wording is explicit.
"These restrictions apply only to self-serve tiers: legacy Free, Basic, Pro subscriptions, and Pay-per-use packages. Enterprise access levels are not impacted - the endpoint behavior remains the same for Enterprise developers." Forum announcement, 23 February 2026.
Self-replies still work, and that answer comes from X staff rather than from inference. A developer asked the question directly on the X developer forum and got a one-line answer.
"Replying to your own posts is fine and should work. If you run into any issues, please let me know." taycaldwell, X Staff, forum thread 257955, 24 February 2026.
That is why auto-plug style features, where a tool appends a promotional reply under your own post, kept working while reply-to-strangers automation did not. The two things run through the same endpoint but sit on opposite sides of the new rule.
Two later restrictions landed without their own announcement, and this is the narrow sense in which the "X shipped it quietly" framing is fair. The reply change itself was announced the same day. The follow-ons were not, and developers discovered them by breaking.
The first hit on 28 February, when @mentions began failing in ordinary non-reply posts. Several developers reported it independently and assumed it was a bug. On 1 March, X staff confirmed it was deliberate: "This is a new update in addition to the recent announcement." The error developers saw reads:
"Creating posts with @mentions is not allowed for your access package. In replies to conversations you are part of, you may only @mention users who are already participants in the thread." Developer-reported error string, forum thread 258356.
This is why "non-replies are unaffected" is too generous a summary. Plain posting does still work, but you can no longer freely @mention or quote people inside those posts, and that broke legitimate non-spam uses along with the spam. Developers in those threads described a milestone-announcement bot that credited founders and an events account that credited host organisations, both caught by a rule aimed at something else.
The second follow-on hit cross-account quote posts. On 16 March, developers reported that quote_tweet_id had stopped working for quoting other accounts while quoting your own posts still worked, and described the change as undocumented. X staff later pointed back to the February announcement and changelog. The error string reads:
"Quoting this post is not allowed because you have not been mentioned or are not part of the conversation thread of the post you are quoting." Developer-reported error string, forum thread 259927.
For completeness, the 403 a blocked reply returns is worth recognising if you are debugging one:
"Reply to this conversation is not allowed because you have not been mentioned or otherwise engaged by the author of the post you are replying to." Developer-reported, confirmed by X staff as expected behaviour, forum thread 257876.
X framed the reply restriction as an anti-spam measure aimed at automated, low-quality replies, and specifically at replies written by language models. The title X gave its own announcement is the clearest signal of intent: "X API v2 Update: Addressing LLM-Generated Spam". The changelog opens with the same framing, "Today, we made changes to reduce automated, low-quality replies on X."
The enforcement that preceded the announcement points the same way. When X staff explained why one developer's app had been limited, the reason given was "sending unsolicited @mentions", not volume or rate limits.
Five months later, X's then Head of Product, Nikita Bier, gave the sharpest public statement of what X was aiming at.
"We found 42,000 accounts automating replies using chatbots and have removed them from the platform. X's core value is providing an authentic pulse on humanity - and using AI to programmatically engage with users without a human in the loop runs counter to our mission." Nikita Bier, then Head of Product at X, 24 July 2026. Bier stepped down from the role in August 2026 and stayed on as an advisor.
Read that quote precisely, because it is the single most-misquoted line in this whole story. Bier condemned AI engaging with people without a human in the loop. He did not bless the converse, and an executive post is a statement of intent, not a rule. It tells you what X was aiming at. It does not tell you what X permits.
Three categories are left, and they are not equally available or equally safe. Here they are with X's own rules attached to each.
Enterprise access is exempt from the reply restriction, and that exemption is X's own recommendation to developers it broke. The forum announcement tells affected developers where to go:
"If your use case requires replying without being mentioned/quoted, or broader @mention/quote capabilities (e.g., advanced moderation, customerr [sic] service at scale, or other high-volume interactions), consider upgrading to Enterprise access." Forum announcement, 23 February 2026. The spelling of "customerr" is X's.
What Enterprise access costs is not public. X's API pricing page lists per-call pay-per-use rates and then says only that if you need higher volume you should upgrade to an Enterprise plan, linking to a sales interest form. There is no published figure, so any specific monthly price you see quoted for this exemption is not coming from X. We are not going to print one either.
The @XDevelopers post also exempts "Public Utility" apps. X does not define that term in the announcement, the changelog or the post, so treat the exemption as real but undefined.
What about a verification route for small, legitimate, non-spam apps? Developers asked for exactly that in more than one thread, in one case asking whether there was "another path or some sort of verification we can go through to prove we are not responsible for slop content and spam". In the threads we read, no X staff member answered those requests. The only route X points to is the Enterprise sales form.
Browser automation is not a workaround, and X's own documents are unusually direct about it. A tool that drives a real browser session to post replies on your behalf has not escaped X's rules by leaving the API. It has moved from a channel X restricted to a channel X's documentation says gets accounts permanently suspended.
X states this in three separate first-party places. From the Automation Rules, stamped Updated April 2026, in the list of things not to do:
"Use non-API-based forms of automation, such as scripting the X website. The use of these techniques may result in the permanent suspension of your account." X Automation Rules.
From the Developer Guidelines, in a prohibited-activities table prefaced with the line "These activities will get your app suspended or permanently banned. There are no exceptions.":
"Non-API Automation | Browser scripting, scraping, any automation outside official API" X Developer Guidelines, prohibited activities.
And from the same page, in the requirements for automated accounts: "Use only the official X API. No scraping, browser automation, or unofficial methods. Violations result in permanent suspension."
The sequencing is the part that matters most, and almost nobody reports it. X clamped down on non-API automation first. On 14 February 2026, nine days before the API reply change, Bier posted:
"We are rolling out more detection for automation & spam (and a lot more to come). If a human is not tapping on the screen, the account and all associated accounts will likely be suspended - even if you're just experimenting. While we aim to support legitimate use-cases of agents, this will take some time to do properly. For now, we recommend holding off on plugging in your bots. If it's critical, you can use the official API." Nikita Bier, then Head of Product at X, 14 February 2026.
Put the two dates side by side. On 14 February X warned that automation without a human tapping the screen would be suspended, and pointed people at the official API. On 23 February X narrowed the official API. A tool that responded by moving reply automation into a scripted browser session moved into the thing X had explicitly warned about nine days earlier. Some tools in this category are open about running on managed browser infrastructure or connecting through session cookies, and some do not describe their mechanism at all. We are not going to name a company and accuse it of a bannable practice we cannot prove. We will say what the category is, quote X's rule against it, and note that the risk of that approach lands on the account doing the posting.
X's published rules are silent on a human using an AI assistant to draft a reply they then edit and post by hand. Silent is not the same as permitted, and this page will not pretend otherwise. What can be said accurately is that X's restrictions are written about automated activity, and a reply a person composes, reviews and posts is not an automated action taken through an account by an app.
Three things support that reading, all from X's own text.
We also looked for a rule requiring you to disclose that a post was AI-assisted, and found none in X's published rules. State that the way we just did: we found no such requirement, which is not the same as X confirming none exists.
What is emphatically not true is that a human in the loop puts you outside X's spam rules. That is covered at the end of this page, and it is the part worth reading twice.
If your goal is to grow an account by replying usefully to other people's posts, the February 2026 change removed the option of having software do it for you on a self-serve API tier. Enterprise access is the route X points affected developers to, and X publishes no price for it. Browser automation is explicitly prohibited in X's own documents. What is left for most people is the oldest approach there is: read the post, write a reply worth reading, post it yourself.
The only thing worth optimising there is speed and consistency, which is where ReplySurge fits. ReplySurge is a browser extension for Chrome, and it also runs on Edge, Brave, Opera and Vivaldi. It reads the post you are currently looking at on X, Reddit or LinkedIn and drafts an on-brand reply in a side panel or inline in the reply box. You edit it, you decide whether to use it, and you post it. ReplySurge never posts, schedules or queues anything on your behalf.
Be precise about what that does and does not mean. It means the February restriction does not describe what ReplySurge does, because ReplySurge sends nothing through the X API, and that X's automation rules are written about automated activity, while a reply you compose, review and post by hand is not an automated action taken through your account by an app. It does not mean X has approved, whitelisted or certified ReplySurge. No such status exists to be granted, X's rules are silent on assistant-drafted replies, and this page is not going to award ReplySurge a status X never handed out. That distinction is the entire reason this page exists.
ReplySurge is free to install, with a free trial and no credit card required. Paid plans unlock unlimited reply generation.
Volume, irrelevance and copy-paste sameness. None of X's spam rules care who typed the words.
Having a person press post is not an exemption from X's spam rules. X's old platform manipulation and spam policy now redirects to a consolidated Authenticity policy, and the operative sentence makes no reference to automation at all.
"Content Spam: You may not share or post content in a bulk, duplicative, irrelevant or unsolicited manner that disrupts people's experience." X Authenticity policy.
Four words in that sentence should shape how anyone uses a reply tool, an assistant, or nothing at all: bulk, duplicative, irrelevant, unsolicited. A person hand-posting fifty near-identical replies an hour is squarely inside that rule, and the fact that a human clicked the button each time is not a defence. The same page also prohibits engagement spam, defined as "inauthentic use of X engagement features to artificially impact traffic or disrupt people's experience", and lists unauthorized automation separately.
So the practical guidance is unglamorous and it is the opposite of what a tool vendor usually tells you:
More from ReplySurge: what the product does on the home page, and how it compares as a ReplyGuy alternative, a Taplio X alternative and an Engage AI alternative.
ReplySurge drafts on-brand replies for X, Reddit and LinkedIn. You edit them and you post them, because nothing here publishes on your behalf.