Who can reply to my posts on X?

What the developer docs list

X's create-post reference describes a reply_settings field that controls who can reply. Its allowed values are following, mentionedUsers, subscribers and verified. The field is an optional restriction rather than a required choice.

Read the four values in plain terms. following limits replies to accounts you follow. mentionedUsers limits replies to accounts you mention in the post. subscribers limits replies to your subscribers. verified limits replies to verified accounts. The reference describes the field as Who can reply to this tweet.

The reference also notes that a poll accepts reply_settings for compatibility but drops it before processing, so do not count on a reply restriction for a poll post made through the API.

Names matter when you talk to a team. Use the API names in technical notes and the in-app wording in anything customers read, and keep a one-line glossary so nobody mixes them up.

A short example for a post that mentions two customers: mentionedUsers lets those two reply and keeps the thread small, following lets the accounts you follow reply, and leaving the field out leaves replies open to everyone.

Checking the setting in the X app

The compose box in the X app shows the reply options your account currently has. Open the composer, find the reply setting before you post, and read the choices. That check takes thirty seconds and shows you the wording your followers will see.

If you need the in-app wording for a team note or a customer guide, take a screenshot of the choices on the day you write it, and date the screenshot.

Replying through the API

The reply object has an in_reply_to_tweet_id, which is required, and an exclude_reply_user_ids list of up to the users you want left out of the reply thread. An auto_populate_reply_metadata flag is accepted for compatibility, but the reference says it is dropped before processing and has no effect.

If you build a tool, set reply_settings on the original post at creation. On the billing side, creating a post costs $0.015 per request as of October 2026 whatever the reply setting is; see X API posting limits for the full list.

If you are building a tool, model reply_settings as an optional enum with the four documented values and an unset state, and keep the polls exception in mind. Show the user the setting before publish, and log which value was sent, because a missing reply setting is hard to notice later. Store the post ID that comes back so you can read edits and metrics; the edit posts guide covers the edit data and the metrics reference lists what you can read.

For a person using a scheduler, the practical step is to open the scheduler's composer for X and look for a reply or conversation setting. If you see one, set it there and the post goes out with that audience.

When to restrict replies on X

Open replies are the default for a reason: replies are how a small account gets noticed. A restriction costs you reach for that post, so use one on purpose.

Reasons that hold up: a post that names someone and invites a pile-on, a post announcing a sale that you want to answer from your own account, a post you expect to be quoted out of context. Reasons that do not: boredom with replies, or fear of one critical comment.

For an account that promotes a product, a gentler habit often beats a restriction: keep replies open, answer the first handful quickly, and mute accounts that add nothing. The same logic is in how to grow on Threads and applies on X.

A worked example. You are a founder posting a price change on X. If you leave replies open, existing customers can answer, and so can strangers with opinions. If you choose a restriction to accounts you mention and name two customers in the post, the conversation stays small. If your plan is to collect feedback, that is the wrong choice. Decide what you want from the replies before you pick, and write that goal in the post itself, such as asking one specific question.

A restriction tied to a status, such as subscribers or verified, only helps if the people you want to hear from have that status. Many of your best repliers will not have that status, and they will be shut out of the conversation. For a growing account that is a real cost.

For an announcement with one call to action, write the action in the post, such as asking for one use case, and keep replies open if you will read every answer. Restrict only if you will not be around to read them.

Threads and X handle this differently

Threads documents three audiences in its app help (anyone, profiles you follow, mentioned only) plus per-post approvals and a hide control. X's developer reference documents four restriction values. Details of each platform's in-app wording belong to each platform's help pages.

If you post the same idea on both platforms, plan for the difference. A restriction that exists on one may not exist on the other. See Threads reply controls for the Threads side and cross-posting Threads and X for the workflow.

A short pre-publish routine works on both platforms. First, decide whether the post is meant to start a conversation or to make an announcement. Second, pick the audience for that goal. Third, check what your scheduler lets you set. Fourth, after publishing, open the post on the platform and confirm the setting took effect, because a restriction that silently did not apply is worse than not trying.

Keep a note of the setting you used on posts that did unusually well or badly. Over a month, that note tells you whether restrictions cost you replies or protected your time, which no general guide can answer for your account.

Where Threadgehog fits

Threadgehog writes the Threads post and, when you approve it, writes the X version in the same voice. It then sends approved posts to Buffer, Typefully, Publer, Metricool or Postiz. Whether a given scheduler exposes X reply settings is something to look up on that scheduler's pages. You can join the waitlist on the pricing page for the day the Mac app opens.

Questions

Sources

1. X Developer Platform: create post (checked 2026-10-17)
2. X Developer Platform: pay-per-usage pricing (checked 2026-10-17)
3. Threadgehog pricing and FAQ (checked 2026-10-17)

Related

• How do reply controls work on Threads?
• What are the X API limits and costs for creating posts?
• How do you cross-post between Threads and X?
• Can you edit a post on Threads and on X?
• What analytics does X give you for your posts?