X API reply: the one condition POST /2/tweets checks

#Quick answer

An X API reply is the same POST /2/tweets call as any other post, with reply.in_reply_to_tweet_id set. On self-serve tiers it only publishes if the author of that post summoned you first: their post @mentions your account, or it quotes one of your posts. Otherwise you get a 403 not-authorized-for-resource with the detail "You can only reply to or quote posts where you are mentioned or are the author." Replies to your own posts are exempt. Enterprise access is not subject to the rule at all.

Last updated: October 2026

That one condition is the whole story of this endpoint since February 2026, and almost nothing on the search results page for it says so. If you want the consumer side of automated replies instead, X comment bots covers what gets accounts flagged.

#The rule, in X's words

X shipped the change on 23 February 2026 and framed it as an anti-spam measure against LLM-written replies. The current docs wording is short:

Replies via the API are only permitted if the replying account has been explicitly summoned by the original post's author.

Summoned means one of exactly two things:

• the original author @mentions your account in their post, or
• the original author quotes one of your account's posts.

If neither is true, the request is rejected. The restriction applies to self-serve customers only: legacy Free, Basic and Pro subscriptions, and pay-per-use. Enterprise access behaves the way the endpoint always did.

Two consequences follow immediately, and both are easy to miss. You are the author of your own posts, so self-replies satisfy the rule trivially. And because the test runs against the post you are replying to, a bot that answers its own mentions is fine while a bot that watches a keyword search and replies to strangers is dead on arrival, no matter how good the text is.

#The 403, and the three errors it is not

Here is the failing response:

{
  "title": "Forbidden",
  "detail": "You can only reply to or quote posts where you are mentioned or are the author.",
  "type": "https://api.x.com/2/problems/not-authorized-for-resource",
  "status": 403
}

Nothing in that body names the summon rule, so the usual reflex is to go looking for a credential problem. A developer did exactly that on 14 October 2026: original posts returned 201, replies to their own posts returned 201, every reply to a third party returned the 403 above, the token had read and write, the target posts allowed replies from everyone, and the account had a confirmed phone number. X staff initially read it as an account-level reply restriction and asked for a review, then corrected themselves in the same thread:

this 403 is expected behavior on self-serve tiers, not a restriction on your account or app, so there's nothing to lift on our side.

Three different 403s on this endpoint get confused with each other, and the detail string is how you tell them apart. not-authorized-for-resource with the "mentioned or are the author" detail is the summon rule. "This user is not allowed to post a video longer than N minutes" is the media duration cap, which follows the posting user's Premium status rather than your API plan. And "Your account is not permitted to access this feature" is an account-level automation restriction, which is a different problem entirely, covered further down.

#Where this is documented, and where it is not

It is in the docs. Just not where anyone looks. It sits under a heading called "Post creation restrictions (self-serve)" inside the manage Posts integration guide, roughly two thirds of the way down a page that opens with advice about Postman and third-party libraries. X's x-api machine index lists that page as a bare "Integration guide" whose description is about tools and key concepts. The root llms.txt does not list the manage Posts tree at all.

Meanwhile the Create Post reference page, the one an SDK links to and a docs search surfaces, documents reply.in_reply_to_tweet_id, auto_populate_reply_metadata and exclude_reply_user_ids without a word about when a reply is allowed. We checked both reference pages on 18 October 2026: neither contains the string "summon".

That gap is why the problem keeps resurfacing in the forum eight months after the change, and why generated tutorials still open with a code sample that posts a reply to an arbitrary tweet ID. The code is correct. The assumption underneath it is not.

While you are on that page, note a second restriction that appears in no announcement and no changelog entry: posts created through the API are capped at one cashtag each, and requests with more than one are rejected. If you publish ticker content, cashtags on X explains what each one renders as.

#The mention rule that was walked back

Five days after the reply change, on 28 February 2026, developers started getting a different 403 on ordinary non-reply posts:

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.

That contradicted the February announcement, which had said regular post creation remained supported, so most people filed it as a bug. X staff confirmed on 1 March that it was a deliberate extension. Then the pressure arrived: scheduling tools, art accounts and event promoters all pointing out that crediting a collaborator by handle is not spam. On 2 March a developer reported the block gone, and staff wrote that the team had chosen to temporarily relax the @mention change while reviewing the use cases it broke.

No announcement has closed that loop since. Mentions in new posts work today; the word "temporarily" is still the last official word on them. If your product depends on mentioning accounts programmatically, build it so a 403 on that string degrades gracefully rather than losing the post.

#Quotes, likes and follows are gone from self-serve

X's 20 April 2026 pricing update removed following, likes and quote posts from every self-serve tier. The Create Post reference now carries a warning that quote_tweet_id requires an Enterprise plan.

An obvious workaround is to drop the post URL into the text field. Do not: that reclassifies the request as Post: Create (with URL), which bills at $0.200 against $0.010 for a summoned reply. A developer raised exactly that on 26 April 2026 and was told to use quote_tweet_id instead, which of course 403s for non-summoned conversations. When a client-app builder pressed the point again on 30 September 2026, arguing that letting a user quote a news post is healthy platform behaviour, staff logged the feedback and confirmed no policy change. So the practical state of play is: quote through the API on Enterprise, quote by hand on x.com, or do not quote.

#What a compliant reply bot actually looks like

One pattern survives the rule. It is narrow, and it is the one X keeps blessing in the forum. Subscribe to mention events rather than polling a search query: the X Activity API delivers post.mention.create when another account explicitly @mentions yours, which is the same event that makes the reply legal in the first place. Reply once per summoning post. Do not @mention anyone who is not already in the thread. Do not like, follow, repost or quote through the API, because those are gone anyway.

Then label the account. Adding the automated account label names a managing human and is the first thing staff ask about when a bot gets restricted. X's automation rules are the governing policy, and nothing here is a statement that a given build complies with them; read them against your own use case.

Asked for written approval of that pattern on 13 October 2026, staff answered that a bot which replies only when mentioned, once per summoning post, through the official API, labelled as automated and honouring opt-out "generally fits within the automation guidelines", and that no separate written approvals are issued on the forum. A formal determination means the Enterprise interest form.

Being compliant is not the same as being immune. On 12 October 2026 a mention-only bot with a clean record had every reply start failing with 403 "Your account is not permitted to access this feature", while reads kept working and manual replies from the same account in the app showed the "this request looks like it might be automated" notice. That is an account-level restriction rather than the summon rule, and staff had it reviewed. Their two pieces of advice are worth copying: add the automated label, and do not move to a backup account to keep replying, because using another account to route around a restriction can get both actioned. Separately, staff noted on 15 June 2026 that the automated label combined with API-driven replies can trigger visibility limiting under the new anti-spam rules, so replies may publish and still not surface in the public thread.

#What it costs and how fast you can go

Summoned replies are the cheapest write on the rate card, which tells you something about what X wants built:

A live rate card sits behind the Developer Console at console.x.com/api/credits/pricing, and it exposes the same three as ContentCreateSummoned, PostCreate and ContentCreateWithUrl. It is public and unauthenticated, so it is the fastest way to check current prices without parsing a docs page. Full context on the model is in X API pricing.

Rate limits are where the docs contradict themselves. The current rate limits page gives POST /2/tweets 10,000 requests per 24 hours per app and 100 per 15 minutes per authenticated user. The manage Posts integration guide, on the same site, still says 200 per 15 minutes per user plus a limit of 300 per 3 hours, citing a 2018 blog post. Build against the lower pair.

One last schema detail, because it wastes an afternoon otherwise. auto_populate_reply_metadata is accepted by POST /2/tweets purely for v1.1 compatibility: X's own OpenAPI description says it "carries no backend argument and is dropped before the mutation is issued". Setting it does nothing. The same note appears on reply_settings inside the poll object, though not on the top-level reply_settings.

If you are weighing the API route against driving your own browser session, that tradeoff is the real decision and it is not mainly a cost one. The API is the sanctioned path and it will not let you cold-reply; a browser automating your own logged-in session can, and that is a gray area X has never endorsed. X-Autopilot runs the browser route locally on your Mac rather than from a shared cloud IP pool, which lowers the detection surface compared with cloud tools without removing it. Pick deliberately, and know which rulebook you are standing on.