dm-send
Send a direct message on X.com. Requires the recipient's user ID (not username). Text-only messages; media attachments are not supported.
Social media management has always been a pain point for software. The APIs shift, rate limits change, authentication flows get rewritten every couple of years. Building reliable Twitter integrations used to mean maintaining a fragile stack of OAuth tokens, API version migrations, and media upload edge cases that nobody documented properly. Most teams eventually gave up and used a SaaS dashboard instead.
The X toolkit on inference.sh takes a different approach. Nine standalone apps - post creation, thread posting, post retrieval, likes, retweets, deletes, direct messages, user follows, and profile lookups - each handling one specific interaction with X.com. No SDK to install, no OAuth dance to manage yourself, no media upload quirks to debug at 2am. You call an app, it does the thing, it tells you what happened. The interesting part isn't any single app in isolation. It's what happens when an AI agent gets access to all nine at once.
I think of this as the difference between giving someone a Twitter account and giving them a social media department. An agent with these tools can monitor conversations, craft responses, build threaded narratives, engage with relevant content, research user profiles, and manage direct outreach - all within the same workflow that handles its other tasks. That's a qualitatively different capability than "can post a tweet."
posting: the foundation
The x/post-create app handles single posts with text and optional media attachments. Standard posts support up to 280 characters, though X Premium subscribers can post up to 25,000 characters (with content beyond 280 characters displayed behind a "Show more" prompt). You can attach up to four images or one video or GIF. Images over 5MB get automatically resized, which is a small detail that eliminates an annoying class of failures. The app also supports quoting other posts and replying to specific tweets by ID, which means an agent can participate in existing conversations rather than just broadcasting into the void.
The per-call pricing makes sense for automated workflows but naturally discourages spam. That's probably a feature, not a bug. An agent that posts thoughtfully and selectively will outperform one that floods a timeline, and the pricing nudges behavior in the right direction.
The reply and quote capabilities deserve special attention. A research agent that finds a relevant thread can jump in with a reply. A brand management agent can quote a customer's post with a response. These aren't just "posting" - they're participating. The distinction matters because social media engagement that only broadcasts is barely social media at all.
threads for long-form thinking
Single posts work for quick updates, but serious content on X happens in threads. The x/post-thread app creates sequences of 2 to 25 connected tweets, each with its own text and optional media, posted as a reply chain. The platform handles the sequencing automatically, so your agent doesn't need to manage reply IDs between posts or worry about race conditions in the posting order.
This is where agent-driven content creation gets genuinely interesting. Consider a research agent that monitors a topic, synthesizes its findings, and publishes a weekly thread summarizing what it learned. Or a product agent that breaks down a complex announcement into a digestible narrative. Threads are X's native long-form format, and giving agents the ability to compose them opens up content strategies that would be tedious to execute manually.
Each tweet in the thread still respects the 280-character limit individually, and each can carry its own media. So a thread can mix text-only analysis posts with image-heavy visual posts. I find that the best threads alternate between the two, and an agent with access to image generation tools alongside the thread poster can produce remarkably polished content.
The media support mirrors post-create: up to four images or one video per tweet in the thread, with automatic resizing for oversized images. Pricing is per API call for the entire thread, not per tweet, which makes it economical for longer sequences.
reading and research
Posting is only half the picture. The x/post-get app retrieves a post by its ID and returns the full picture: text content, author ID, creation timestamp, and engagement metrics including likes, retweets, replies, and quote counts. You can optionally pull in author profile information and media attachment URLs.
This turns X into a data source, not just a publishing channel. An agent monitoring brand mentions can fetch each post to assess sentiment and reach. A competitive intelligence agent can track engagement patterns on competitor content over time. A customer support agent can pull up the exact post a customer is referencing.
The engagement metrics are particularly useful for decision-making. An agent can prioritize responses based on a post's reach - a complaint with 500 retweets probably deserves faster attention than one with 2. It can track whether its own posts are gaining traction and adjust its content strategy accordingly. This kind of feedback loop is exactly what makes agent-driven social media management more than a scheduling tool.
The x/user-get app complements post retrieval by providing profile-level context. Look up any user by ID or username and get back their display name, bio, follower and following counts, tweet count, verified status, profile image, and account creation date. For an agent that needs to decide whether to engage with someone, this context is essential. Is this a real account or a bot? Do they have an audience? What's their bio say about their interests?
Together, these two read operations give an agent situational awareness. It can understand not just what was said but who said it and how much attention it's getting.
engagement actions
Three apps handle the lightweight engagement that keeps a social presence feeling alive: x/post-like, x/post-retweet, and x/user-follow. Each takes a single ID and performs the action. All three succeed silently if the action was already taken, so your agent doesn't need to track state about what it's already liked or who it's already following.
That idempotency is a subtle but important design choice. An agent running on a schedule might encounter the same notable post across multiple cycles. Without idempotent operations, you'd need deduplication logic. With them, the agent can just like every post that meets its criteria and let the platform handle the rest.
The strategic value of these tools shows up in combination. An agent monitoring a specific topic can like and retweet posts from thought leaders it wants to build relationships with, follow accounts that consistently produce relevant content, and maintain a pattern of genuine engagement that makes its own posts more visible. This is what good community managers do manually. Agents can do it consistently, at scale, without getting bored or forgetting.
I'll be honest about the risk here too. Automated engagement can cross from helpful to annoying very quickly. An agent that likes every single post mentioning a keyword will look robotic. The tools themselves are neutral, but the orchestration logic around them needs taste. Rate limiting your agent's engagement to a reasonable cadence matters more than the technical capability to engage with everything.
direct messages and outreach
The x/dm-send app sends text-based direct messages to a specific user by their ID. It's text-only - no media attachments - and requires the recipient's numeric user ID rather than their username. That second constraint means you'll typically pair this with x/user-get to resolve a username to an ID before sending.
Direct messaging is the most sensitive tool in the kit, and I think the text-only limitation is appropriate. Automated DMs carry reputational risk. A well-timed, relevant DM to a customer who just posted a complaint can turn a detractor into an advocate. A spray of generic DMs to everyone who mentions your brand will get you muted or reported.
The best use case I see for agent-driven DMs is responsive outreach. An agent spots a public post expressing frustration with your product, verifies the user's profile to confirm they're a real customer, and sends a brief DM offering to help. That's a workflow that connects monitoring, research, and private communication in a sequence that would take a human support rep minutes per case. The agent handles it in seconds.
cleanup and moderation
The x/post-delete app removes posts by ID, restricted to posts authored by the authenticated account. This is the cleanup tool - essential for any agent that posts content, because mistakes happen. A post with a typo, a reply sent to the wrong thread, a scheduled post that's no longer relevant. Without delete capability, an agent can create but can't correct, which is a recipe for accumulating errors.
Delete also enables a pattern I find underappreciated: ephemeral content. An agent could post time-sensitive updates - "our API is currently experiencing elevated latency" - and automatically delete them when the situation resolves. The post serves its purpose while it's relevant and doesn't linger as stale information afterward.
the agent-native social media play
Step back from the individual tools and the bigger picture becomes clear. These nine apps together give an agent everything it needs to operate as a competent social media presence. Not a scheduling tool that fires off pre-written posts on a calendar. An actual participant that reads the room, engages with relevant content, creates original posts and threads, manages direct conversations, and cleans up after itself.
The workflow possibilities are broad. A developer relations agent monitors mentions of your open-source project, responds to questions with helpful thread replies, likes and retweets community contributions, follows active contributors, and DMs people who report bugs to gather details. A brand agent tracks competitor launches, crafts response threads with the team's positioning, engages with industry commentary, and sends the engagement metrics back to a dashboard for the marketing team to review.
What makes this different from existing social media management tools is the decision-making layer. Traditional tools automate the posting. These tools automate the judgment. An agent decides what to post, when to engage, who to follow, what to delete. The quality of that judgment depends entirely on how you orchestrate the agent, but the mechanical capability is all here.
practical constraints worth knowing
X's own rate limits still apply underneath these tools. The apps handle authentication and API complexity, but they can't bypass platform-level throttling. If your agent tries to post 100 times in an hour, X will push back regardless of the tooling layer. Plan your agent's activity within the platform's tolerance.
The per-call pricing is uniform across all nine apps. That simplicity is nice for budgeting, but it also means a like costs the same as creating a post with four images. For high-volume engagement workflows (lots of likes and retweets), the cost can add up. For posting and research workflows, it's reasonable.
Media handling covers images, videos, and GIFs, but only on the posting side. You can attach media when creating posts and threads. DMs are text-only. Post retrieval can include media URLs from existing posts, but downloading and processing that media is outside the scope of these tools.
Authentication is handled at the platform level - you connect your X account once and all nine apps use the same credentials. No per-app setup, no token juggling. This is one of those things that sounds minor until you've spent a day debugging OAuth callback URLs across multiple integrations.
frequently asked questions
can an agent run a full social media strategy with just these nine tools?
For X specifically, yes. The toolkit covers the complete lifecycle: researching users and posts, creating content as single posts or threads, engaging through likes and retweets, building network connections through follows, handling private conversations via DMs, and cleaning up with deletes. The missing piece is search and timeline browsing - an agent can fetch specific posts by ID but can't discover new posts through keyword or timeline queries. You'd need to pair these tools with a separate discovery mechanism, whether that's a webhook feed, a monitoring service, or manual curation of post IDs to act on.
what happens if my agent hits X's rate limits?
The tools will return errors when the underlying X API rejects requests due to rate limiting. They don't silently queue or retry - your agent gets the failure and can decide how to respond. In practice, this means your orchestration layer should include backoff logic for high-volume workflows. A reasonable posting cadence of a few posts per hour with moderate engagement activity won't run into limits. Aggressive patterns like following hundreds of users in rapid succession will. The platform's limits are documented by X and change periodically, so building some resilience into your agent's scheduling is worthwhile regardless.
is there a risk of getting an X account suspended for using automated tools?
X's automation policy permits automated posting and engagement within their guidelines, but enforcement is based on behavior patterns, not tooling. An agent that posts useful content, engages authentically, and operates at human-plausible speeds is unlikely to trigger issues. An agent that blasts thousands of likes per day or sends unsolicited DMs to strangers will look like spam regardless of how sophisticated the tooling is. The tools themselves are compliant with X's API terms. The responsibility for staying within behavioral guidelines falls on how you design your agent's decision-making and activity cadence.
api reference
about
send a direct message on x.com. requires the recipient's user id (not username). text-only messages; media attachments are not supported.
1. calling the api
install the client
the client provides a convenient way to interact with the api.
1pip install inferenceshsetup your api key
set INFERENCE_API_KEY as an environment variable. get your key from settings → api keys.
1export INFERENCE_API_KEY="inf_your_key"run and get result
submit a request and wait for the final result. best for batch processing or when you don't need progress updates.
1from inferencesh import inference23client = inference()456result = client.run({7 "app": "x/dm-send",8 "input": {}9 })1011print(result["output"])stream live updates
get real-time progress updates as the task runs. ideal for showing progress bars, partial results, or long-running tasks.
1from inferencesh import inference23client = inference()456# stream=True yields updates as they arrive7for update in client.run({8 "app": "x/dm-send",9 "input": {}10 }, stream=True):11 if update.get("progress"):12 print(f"progress: {update['progress']}%")13 if update.get("output"):14 print(f"output: {update['output']}")2. authentication
the api uses api keys for authentication. see the authentication docs for detailed setup instructions.
3. files
file inputs are automatically handled by the sdk. you can pass local paths, urls, or base64 data.
automatic upload
the python sdk automatically detects local file paths and uploads them. urls are passed through as-is.
1# local file paths are automatically uploaded2result = client.run({3 "app": "x/dm-send",4 "input": {5 "image": "/path/to/local/image.png", # detected & uploaded6 "audio": "https://example.com/audio.mp3", # url passed through7 }8})4. webhooks
get notified when a task completes by providing a webhook url. when the task reaches a terminal state (completed, failed, or cancelled), a POST request is sent to your url with the task result.
1result = client.run({2 "app": "x/dm-send",3 "input": {},4 "webhook": "https://your-server.com/webhook"5}, wait=False)webhook payload
your endpoint receives a JSON POST with the task result:
1{2 "id": "task_abc123",3 "status": 9,4 "output": { ... },5 "error": "",6 "session_id": null,7 "created_at": "2024-01-15T10:30:00Z",8 "updated_at": "2024-01-15T10:30:05Z"9}5. schema
ready to run dm-send?
we use cookies
we use cookies to ensure you get the best experience on our website. for more information on how we use cookies, please see our cookie policy.
by clicking "accept", you agree to our use of cookies.
learn more.