Automated replies on X: the API now enforces who you may answer

The common design for a reply bot is to watch a topic, find people discussing it, and answer them. That pattern is prohibited by X's automation rules and, more decisively, it no longer works: programmatic replies through the API are now restricted to conversations where the original author has mentioned or quoted you.

What remains is narrower and genuinely useful. Answering the people who have addressed you directly is both permitted and the only version anybody actually wanted to receive. This covers what you can build inside that boundary and how to make it worth having.

What we'll cover

• What the rules and the API now allow
• The pattern that stopped working
• What else is prohibited
• The shape of a compliant reply bot
• Building it with CodeWords
• Classifying before generating
• What should never get an automated reply
• The approval gate, and when to drop it
• Duplicates, and replying twice
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

What the rules and the API now allow

Two layers, and they now agree.

X's automation rules prohibit automating replies and mentions to reach users on an unsolicited basis, and prohibit bulk or automated unsolicited mentions in response to generic or broad discussion of a topic. The stated principle is to contact only users who have clearly indicated a desire to hear from you, with a direct mention of your account given as the example (X's automation rules).

The API now enforces that boundary rather than leaving it to policy. Programmatic replies are restricted so that you can only reply where the original author has mentioned your account or quoted your post, across the free and paid tiers alike.

So the permitted case is clear and worth stating positively: somebody addressed you, and you answer them. Build for that and you are inside both the rules and the API's behaviour.

The pattern that stopped working

Worth describing because most published guidance still assumes it.

The old design searched for a keyword, found people talking about a topic, and replied into those conversations with something relevant. It was the basis of a lot of growth advice, and it was always against the rules even while it worked.

It now fails at the API rather than at enforcement, which is a kinder failure mode. A system built on it does not quietly accumulate violations; it simply cannot post.

If you inherit a design like this, the useful question is what it was actually for. Usually the goal was discovery, and the honest alternatives are the ones that were always better anyway: publishing things worth finding, and answering the people who then come to you.

What else is prohibited

The rules cover more than replies and the adjacent behaviours catch people out.

Automated liking is not permitted.

Bulk, aggressive or indiscriminate following and unfollowing is a violation.

Bulk or aggressive reposting is a violation.

Unsolicited direct messages sent in bulk or automated form are prohibited.

Enforcement can reach both the application and the associated accounts, so a bot doing one of these can cost you the account it posts from. These are worth reading properly before building anything, because several of them are things automation tools still offer.

The shape of a compliant reply bot

Four stages, and the constraint shapes all of them usefully.

Watch your own mentions, rather than a topic search. This is now the only input that leads anywhere.

Classify what each one is. A question you can answer, a complaint, praise, spam, or something needing a person. This step decides everything downstream and is where most implementations are thin.

Generate only for the classes you have decided to answer, grounded in your own information rather than the model's general knowledge.

Post, or route to a person. With the boundary being what the classifier was confident about rather than what it could produce text for.

Notice that this is a support workflow rather than a growth one. That is the honest framing, and it is a genuinely valuable thing to automate.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: watch mentions, classify them, and answer only the categories you name.
3. Authorize the connections to your X developer account and wherever your own answers and product information live.
4. Describe the exceptions explicitly, including anything expressing frustration, anything about pricing or availability, and anything the classifier is unsure about.
5. Keep a record of every mention already handled, so a restart or a retry cannot produce a second reply.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Classifying before generating

The instinct is to pass every mention to a model and let it decide what to say. Classifying first is better on every axis.

It is cheaper, since most mentions do not need generation at all. It is safer, because a classifier that is unsure can hand over while a generator that is unsure produces something confident. And it gives you a number worth watching: the mix of categories over time tells you what people actually come to you for.

Keep the categories few and concrete. Something like: answerable question, complaint, praise, spam, other. Five is plenty and more makes the boundaries fuzzy.

Then decide which classes get an automated reply. For most accounts that is answerable questions and nothing else, with praise getting a human acknowledgement when somebody has time.

What should never get an automated reply

Anything expressing frustration or anger. A generated reply to somebody upset reads as dismissal and is the category most likely to be screenshotted.

Anything about a price, a date or availability that has not been confirmed. Public and wrong is worse here than in a private channel.

Anything critical of the product where a canned answer will read as deflection.

Anything involving another person or company. Automated systems have no judgement about who they are dragging into a thread.

Anything the classifier was unsure about. Uncertainty is the signal to hand over, not to try.

The asymmetry is the point. A good automated reply is mildly useful; a bad one is public, permanent and quotable.

The approval gate, and when to drop it

Start with every reply queued for a person to approve. It is slower and it is how you find out what the thing actually does.

Watch the approval queue for a fortnight. If you are approving nearly everything unchanged within one category, that category is a candidate for going direct. If you are editing most of them, the drafting needs work before the gate comes off.

Keep the gate permanently for anything in the never-automate list above. The goal is not to remove humans from the loop but to stop them from being in the loop for the trivial cases.

Duplicates, and replying twice

A specific and embarrassing failure worth designing against.

Polling for mentions means the same mention can be seen twice, after a restart, a retry, or a timing overlap. Reply twice to one person and the account looks broken.

Keep a durable record of every mention id already handled, check it before posting, and write to it after. Make that record survive a restart, since holding it in memory is exactly what fails at the moment things go wrong. And make the reply itself idempotent where you can, so a retried request cannot produce a second post.

Making it survive

Watch mentions only, never a topic search.

Keep a durable record of handled mentions.

Route anything uncertain or negative to a person.

Read a sample of replies weekly, looking for confident wrong answers.

Re-read the automation rules periodically, since both the policy and the API behaviour have changed recently.

Limits worth knowing about

Programmatic replies are restricted to authors who mention or quote you, and no tier lifts that.

Automated liking, bulk following and bulk reposting are prohibited and can cost the account.

This is support tooling, not growth tooling, whatever the older guidance suggests.

Public replies are permanent and quotable, which raises the cost of being wrong.

Rate limits and access tiers change, so a design built on current allowances needs revisiting.

What to build first

The classifier, with no generation at all. Watch your mentions, sort them into a few categories, and send yourself a daily summary. You will learn within a week what proportion is actually answerable, which is the number that tells you whether the rest is worth building.

Two habits make the difference. Keep a durable record of every mention you have handled, because replying twice to the same person is the failure that makes an account look abandoned to a bot. And route everything the classifier is unsure about to a person, since the cost of a wrong public reply is much higher than the cost of a slow one.

Frequently asked questions

Can I build a bot that replies to people discussing my topic?

No. X's automation rules prohibit unsolicited automated replies and mentions in response to broad discussion of a topic, and the API now restricts programmatic replies to authors who have mentioned or quoted you.

What replies are permitted?

Replying to people who have addressed you: those who mention your account or quote your post. That is both the rule and what the API now enforces.

What other automated behaviours are prohibited?

Automated liking, bulk or indiscriminate following and unfollowing, bulk or aggressive reposting, and unsolicited direct messages sent in bulk.

What happens if I break these rules?

Enforcement can reach the application and the associated accounts, up to suspension, so a bot can cost you the account it posts from.

Why classify mentions before generating a reply?

It is cheaper, since most mentions need no generation; it is safer, because an unsure classifier can hand over while an unsure generator sounds confident; and the category mix tells you what people come to you for.

What should never get an automated reply?

Anything expressing frustration, anything about unconfirmed prices or dates, anything critical of the product, anything involving a third party, and anything the classifier was unsure about.

Should replies be approved by a person?

Start that way. After a fortnight, categories you approve unchanged are candidates for going direct. Keep the gate permanently for the never-automate list.

How do I avoid replying twice?

Keep a durable record of handled mention ids, checked before posting and written after, and make sure it survives a restart. In-memory tracking fails exactly when things go wrong.

Is this a growth tool?

It is support tooling. The growth pattern it is often sold as was always against the rules and no longer functions, and the honest alternative is publishing things worth finding.

What should I measure?

The mix of mention categories, the proportion answered without a person, and how often approvals are edited rather than accepted. That last number tells you whether the drafting is ready.

Related reading

• Telling people they are talking to a bot
• Every question costs you people and buys you quality
• Testing it before customers do