If you are building anything that acts on X, the automation rules are not a side document — they are the specification. They distinguish three mechanisms sharply, and the difference between them is the difference between a compliant product and a suspended account.
Automate through the official X API within its conditions (opt-in, opt-out, one reply per interaction, no duplicates), assist humans who keep the posting click, and never script the X website — the rules name that mechanism directly and cite permanent suspension as the consequence.
The three mechanisms, and where each stands
The rules draw their hardest line not between “automated” and “manual,” but between mechanisms. Where your product sits decides almost everything else.
| Mechanism | How it acts | Rule status | Fits |
|---|---|---|---|
| Official X API | Server-to-server actions through documented endpoints, with rate limits and access tiers | Allowed within the rules and the Developer Agreement | Products, campaigns, and integrations built on consent |
| Writing assistance (extension) | Drafts text in the composer; a human reviews and posts | Not automation — the person posts their own words | Anyone who wants speed without giving up judgment |
| Website scripting | Drives x.com directly like a user, without the API | Explicitly prohibited; permanent suspension risk | Nothing. This is the line. |
Path 1: the official X API
The API is the sanctioned automation surface. It provides endpoints for creating posts and replies, reading public content, and managing account actions, under rate limits and access tiers published on the developer portal (the product tier page lists current access levels). Two things follow: the controls exist so X can see and regulate automation, and building on the API is a statement of intent — you are operating inside the system the rules govern, not around it.
The conditions attached to automated replies
The rules do not ban automated replies and mentions outright; they attach conditions. Under the April 2026 automation rules, you may send automated replies or mentions only when:
- the recipient has opted in — they requested, or clearly indicated intent on X, to be contacted by you (following your account is not sufficient on its own);
- you provide a clear and easy way to opt out of automated replies and mentions, and honor opt-outs promptly;
- you send only one automated reply or mention per user interaction; and
- the reply answers the user’s original post (when the campaign is based on replies to your post).
The rules also state the inverse plainly: automating replies and mentions to reach many users on an unsolicited basis “is an abuse of the feature, and is not permitted” — with replies driven by keyword searches alone called out as the example. If a growth idea starts with “find posts containing X and reply,” the rules already answered it.
The AI-bot clause most builders miss
If your product generates replies with AI, one more gate applies. The rules say AI reply bots that produce “dynamic, context-aware responses” are allowed in principle — but that “the deployment or operation of any AI reply bot requires prior written and explicit approval from X.” That approval is separate from ordinary API access, and it applies to the product, not just the account behind it. Plan for it before launch: submit through the developer portal and treat approval as a product requirement, not paperwork.
Path 2: writing assistance — draft, then a human posts
An extension that drafts a reply for a person to review, edit, and post is not automation: nothing is sent on the user’s behalf, so none of the automated-reply conditions above are triggered. The platform sees a person posting their own words — which is also why this design is the safest position for reply tooling, and why tools like TweetReplier deliberately end at the draft.
The trade-off is throughput: assistance scales at human speed. For accounts where every reply carries the owner’s name, that constraint is a feature. The review-first vs auto-post breakdown covers where each design belongs, and the comparison table shows which products take which approach.
Path 3: website scripting — the one to rule out
The rules’ “Don’t” list is explicit: “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.” Notice what the rule targets: the mechanism, not the volume. A carefully paced script that mimics human timing is still scripted automation, and tools that drive x.com through a hidden browser to post, like, follow, or reply sit in this category regardless of how they are marketed.
There is a logic to the severity. API automation is visible, consented, and rate-limited; scripting circumvents exactly those controls. For builders, the practical asymmetry matters too: the suspension lands on the user’s account, not the tool vendor’s.
Common use cases, mapped
| Use case | Mechanism | Verdict |
|---|---|---|
| Scheduled posting of your own content | API | Allowed; content rules still apply — no duplicative or substantially similar posts |
| Auto-reply to users who engage with your content | API | Allowed with conditions: opt-in, easy opt-out, one reply per interaction |
| Keyword-driven replies to strangers | API or scripting | Not permitted — unsolicited automated replies and mentions |
| Automated likes, and bulk follows or list adds | API | Not permitted — automated liking is banned outright; follows and list adds are banned in bulk or indiscriminate form |
| AI reply bot generating dynamic responses | API | Requires prior written approval from X before deployment |
| Broadcasting useful information (feeds, data, weather) | API | Allowed when you are authorized to publish the information |
| Draft suggestions a human reviews and posts | Extension — no automation | Standard writing assistance, outside the automation rules’ scope |
| Reading public data and analytics | API | Allowed within rate limits and privacy rules |
A compliance checklist for builders
- Design for consent. Record the opt-in before any automated reply or mention; “they follow us” does not count on its own.
- Ship the opt-out. Make it visible, make it one step, honor it immediately.
- Cap interactions. One automated reply or mention per user interaction, and only in response to the user’s original post.
- Deduplicate. No duplicative or substantially similar posts on one account — that rule applies to human-paced automation too.
- Get the AI approval in writing before an AI reply bot goes live.
- Stay inside rate limits. Circumventing them is itself listed as a violation, and it is one of the fastest ways to lose API access.
- Do not surprise users. Automated activity should honor expectations; disclosure and non-misleading behavior are ground rules, not courtesies.
- Re-read the rules before every launch. The current page was updated April 2026, and enforcement evolves with the platform.
If you are evaluating a tool instead of building one
Three questions decide most of the risk in a vendor conversation:
- Does it act through the API, or drive the website? API or assistance is workable; scripting belongs in the suspension category.
- Does it post without a human, or stop at a draft? Auto-posting is not automatically wrong, but it needs the conditions above — and a review step is the simplest way to stay clear of them.
- If it posts automatically, who holds the X approval? For AI reply bots, the written-approval requirement is explicit. A vendor that cannot explain how it satisfies that requirement is passing the risk to your account.
The pattern across all three: mechanism first, features second. The head-to-head comparison applies the same lens to specific products, and the human-in-the-loop guide covers the workflow that keeps automation on the right side of the line.
Bottom line
Building for X comes down to three clean choices: use the official API inside its conditions, assist humans who keep the final click, or do not automate. The rules reward products that are visible, consented, and controllable — and they name the alternative, scripting the site, as a suspension risk. Before your first automated action ships, read the automation rules and the sibling explainer on what the rules mean for everyday accounts.