Let your AI agent grow your X account: the ClimbX API.

A lot of people are wiring up agents right now. The reasoning is good and getting better. What an agent is still bad at is the part that makes X actually work: knowing what breaks out for an account your size, writing in a voice that sounds like a person, and shipping on a cadence that the algorithm rewards instead of punishes. Those are not reasoning problems. They are data and plumbing problems, and they are exactly what ClimbX already does.

So we are opening it up. The ClimbX API lets your agent publish a post, schedule one for later, and read your real analytics and voice profile - over a single REST call, no scraping and no headless browser. This post is the why and the how.

The split that makes this work

The cleanest way to think about it: your agent owns the intent, ClimbX owns the X-specific execution. You decide what to say and when to say it. ClimbX handles the parts that are tedious to get right and easy to get wrong.

• Publishing. One call ships a post to X through your connected account. The same link block the composer enforces applies here, because a link in the post cuts reach by 50 to 90%.
• Scheduling. Queue a post for any future time and the existing publish pipeline ships it at the minute, with retries on transient failures. Your agent does not have to stay awake to post at 8am.
• Reading. Pull your recent posts with their metrics, a per-format performance summary, and your voice profile. Now the agent can ask the only question that matters before it drafts: what is actually working for this account right now?

What it looks like

Create a key in ClimbX settings, then hand it to your agent. Publishing is one request.

curl -X POST https://climbx.so/api/v1/posts \
  -H "Authorization: Bearer climbx_sk_your_key" \
  -H "Content-Type: application/json" \
  -d '{"text": "shipped the climbx api today."}'

Reading your analytics is just as small a call, and it returns numbers your agent can reason over: impressions, replies, and a median-per-format breakdown so it knows whether your hot takes or your build-in-public updates are pulling. The full endpoint list lives in the API docs.

The guardrails are the point

An API that lets an agent post to your account could go wrong in obvious ways, so the limits are deliberate, not an afterthought.

No link posts. URLs are rejected at the API, same as in the app. Reach is the lead reason; cost is the second (a post with a URL is 13x the price to publish on the X API). If you want to share a link, your agent can post the thought and you drop the link in a reply.

A daily cap. Five posts per account per day while the API is young. That is enough to run a real cadence and low enough that a runaway loop cannot flood your feed or spook the spam filter. It is one number we can raise as we watch how the API gets used.

Your control. Keys are scoped to one account, shown once, stored only as a hash, and revocable instantly. Revoke a key and anything using it stops on the next call.

Why API first, and not MCP

We are starting with a plain REST API because it is the lowest-friction way for the people already building agents to plug in today. MCP is a natural next step and we will ship it if the demand is there. The honest version: we would rather watch real adoption from builders running setups like openclaw and hermes than guess at an interface nobody asked for yet. If you are one of those builders, the fastest way to shape v2 is to use v1 and tell us where it falls short.

Update (July 2026): the demand showed up - a customer built a community MCP server on this API before we did. The official ClimbX MCP server is now live.

One short version

Your agent thinks. ClimbX knows X. Give it a key and let it post in your voice, on a schedule, against data about what works at your size - without giving up the edit-and-ship control that keeps the account yours. Grab a key in settings, read the docs, and ship your first post in one call.