Twitter (X) Reply API — A Programmatic Tutorial
Replying via API to Twitter (X) posts is one of the most common write-side workflows — customer support bots, AI reply agents, automated engagement, threaded conversation flows. This tutorial walks the exact call + auth requirements + rate-limit pacing.
Pricing references URL-cited to X's docs.
The reply mechanic — one field difference from a regular tweet
A reply on X is technically a tweet with in_reply_to_tweet_id populated. That single field tells X's system to thread the new tweet under the target, apply reply-specific rendering, and route notification to the target's author.
Everything else about the tweet is the same as a regular POST — text (280 char limit), optional media attachments, mentions, hashtags, reply_settings for who can reply back.
The X official POST call
Endpoint: POST /2/tweets. Auth: OAuth 1.0a user-context (an X account you have the 4-key credential set for). Body: JSON with text + reply.in_reply_to_tweet_id.
Pricing per docs.x.com/x-api/getting-started/pricing: $0.010 per post.
# pip install tweepy
import tweepy
client = tweepy.Client(
consumer_key="...", consumer_secret="...",
access_token="...", access_token_secret="...",
)
def reply_to(target_tweet_id: str, text: str):
resp = client.create_tweet(
text=text,
in_reply_to_tweet_id=target_tweet_id,
)
return resp.data
# Reply to a specific tweet
result = reply_to("1234567890", "Thanks for the question — full answer on our blog: https://...")
print(f"reply posted, id: {result['id']}")reply_settings — who can reply to your reply
X's tweet-object supports reply_settings controlling who can reply. Values: everyone (default), mentionedUsers (only accounts you mention), following (only accounts you follow).
For a customer-support bot, everyone is right — you want customers to reply. For a curated thread, mentionedUsers limits noise. For AI reply agents, everyone again — you want the conversation open.
# Restricting replies to mentioned users only
resp = client.create_tweet(
text="Curated thread → @user1 @user2 join the conversation",
in_reply_to_tweet_id="1234567890",
reply_settings="mentionedUsers",
)Rate-limit pacing for bulk replies
X publishes per-user rate limits at docs.x.com/x-api/fundamentals/rate-limits. For reply-bot workloads, pace 1-2 seconds between calls. Bursting risks 429 rate-limit responses + triggers X's spam detection.
Beyond rate-limit: content variation. Replying with near-identical text across many targets gets flagged as spam even at safe pacing. Vary your replies meaningfully (per-target context, template variation).
import time, random
def bulk_reply_paced(pairs):
"""pairs = list of (target_tweet_id, reply_text)"""
for target_id, text in pairs:
try:
client.create_tweet(text=text, in_reply_to_tweet_id=target_id)
except tweepy.TooManyRequests:
print(" rate-limited, sleeping 60s...")
time.sleep(60)
continue
# 1.5s pace + random jitter
time.sleep(1.5 + random.uniform(0.1, 0.5))
bulk_reply_paced([
("1234567890", "Great point — added to our roadmap"),
("1234567891", "Different angle worth exploring: ..."),
])Common reply workloads
Customer-support auto-reply: monitor mentions of your handle + reply with FAQ answers or route to a human. Rate-limited to ~30-100/day per account.
AI reply agent: LLM reads the target tweet + generates a contextual reply. Cost: LLM API + $0.010 per posted reply.
Community-engagement bot: reply to topic-matching tweets with helpful resources. Careful — this is where spam-detection risk lives.
Threaded content series: post the first tweet, then chain replies to build a thread. Same call, in_reply_to_tweet_id points to your own previous tweet.
Cross-reference reply: reply to a viral tweet with a related resource or contribution. Manual triggering + programmatic posting is cleaner than fully-automated content routing.
Side-by-side — 3 reply-related endpoints
All three use the same endpoint; the in_reply_to_tweet_id field determines which behavior.
What NOT to do
Mass identical replies: X's spam detection catches identical or near-identical replies posted across many targets. Vary meaningfully.
Reply-bombing: replying to every tweet from a target account gets you rate-limited + potentially suspended.
Political manipulation: automated replies pushing political / commercial agendas are explicitly against X's civic-integrity + platform-manipulation policies. Suspension likely + you lose the account entirely.
Fake-persona reply farms: coordinated inauthentic behavior (multiple accounts posting coordinated replies) violates X's authenticity policy. Multi-account suspension likely.
# Practical example: AI reply agent — monitor mentions + LLM-generate reply + post.
import os, time, random
import tweepy
# from your llm client import client as llm_client
x_client = tweepy.Client(
consumer_key=os.environ["X_CONSUMER_KEY"],
consumer_secret=os.environ["X_CONSUMER_SECRET"],
access_token=os.environ["X_USER_TOKEN"],
access_token_secret=os.environ["X_USER_SECRET"],
)
def generate_reply(target_text: str) -> str:
"""Illustrative — call your LLM of choice with a reply-generation prompt."""
return f"Interesting take — worth considering that {target_text[:60]}..."
def process_mention(mention):
target_id = mention["id"]
target_text = mention["text"]
reply_text = generate_reply(target_text)
if len(reply_text) > 280:
reply_text = reply_text[:277] + "..."
try:
resp = x_client.create_tweet(text=reply_text, in_reply_to_tweet_id=target_id)
print(f"replied to {target_id}: {resp.data['id']}")
except tweepy.TooManyRequests:
time.sleep(60)
# Poll mentions loop (illustrative)
mentions = [] # populated from twitterapi.io mentions endpoint or X official
for m in mentions:
process_mention(m)
time.sleep(1.5 + random.uniform(0.1, 0.5))
# Cost per docs.x.com pricing:
# ~50 replies/day × $0.010 = $0.50/day = ~$15/month for the reply-write cost
# LLM cost + mention-read cost separate. On the read side (mention monitoring via twitterapi.io) cost stays ~33× below X official self-serve read pricing per docs.x.com — that's where the cost delta lives for reply workloadsQuestions readers ask
Can I reply from twitterapi.io?
No — twitterapi.io is read-only. Reply, like all write actions, requires X official's user-context OAuth. Read side (mentions monitoring, target-tweet lookup) can use twitterapi.io at lower cost; write side must go through X.
How do I get the tweet ID I want to reply to?
The tweet URL contains it: https://x.com/user/status/. The ID is the numeric string. Programmatically: from /twitter/user/mentions or /twitter/tweet/advanced_search responses, use the id field.
Can I attach media to a reply?
Yes — same media_ids parameter as a regular tweet. Upload media first via the media upload endpoint, then include the returned IDs in the reply POST.
What if my reply is over 280 chars?
The POST fails. Truncate client-side before sending. Some AI reply agents run the generated text through a length-check + retry with a shorter prompt if over.
Can I edit a reply after posting?
No native edit for replies via API. If you need to correct, delete the reply and post a fresh one. Delete: client.delete_tweet(id=.
How do I detect if my reply was flagged / hidden by the target author?
Authors can hide specific replies. Detection via API: check the reply status endpoint. Hidden replies remain in the API response but with a flag. Poll periodically if the flag matters for your workflow.
Continue
- Twitter (X) API — cluster hub
- How to make a Twitter (X) thread via API
- Twitter (X) templates — API bulk post
- Twitter (X) scheduling tool API integration
- Rate limit exceeded on Twitter (X) — fixes
- twitterapi.io pricing
Stop reading. Start building.
Starter credits cover real testing on real data. Google sign-in, no card, no application queue.
Get an API key