Automate X Posts and Threads: the API, the Cost and the Rules

There is no scheduling in the X API

Look through the request body for POST /2/tweets and you will find text, media, a poll object, a reply object and a quote id. There is no timestamp field. Nothing on that endpoint accepts a future publish time, so you cannot schedule X posts through the API, and the page documenting it never mentions scheduling.

That one absence explains most of what goes wrong. To automate X posts and threads you supply the part X does not: something that remembers your post, wakes at the right minute and makes the call. Facebook hands you that for free: its Pages API takes scheduled_publish_time and holds the post on Meta’s side, covered in what Facebook lets you schedule. YouTube does the same with status.publishAt. On X, the queue is yours.

So every X scheduler, from a one-file cron job to a product with a calendar view, does the same five jobs:

• A durable timer that survives a restart, a deploy and a dead worker. An in-memory timer loses Tuesday’s posts when the process dies on Monday.
• Credential storage. Your user tokens sit in someone’s database until the post fires: weeks of exposure rather than seconds.
• Token refresh. A token valid when you queued the post must still be valid when it fires. Refresh failures are the quiet cause of a post that never appears.
• Retry that handles a rate limit or a 503 at the target minute without looping.
• Per-post status. Someone records what actually published, because X will not tell you later what you meant to send.

Every one of those is a place a post can vanish, and on networks with native scheduling most do not exist. That is the honest reason X scheduling breaks more often than the rest of your stack. Worth reading alongside the multi-platform guide, because the other networks in your queue fail in different ways.

How threads actually chain

A thread is not an object. X has no endpoint that takes an array of posts and returns a thread, so to automate Twitter threads, or X threads, is to automate a chain of replies. The old name lingers in the API itself: the endpoint is still POST /2/tweets, and it accepts a reply object whose in_reply_to_tweet_id is the numeric id of the post being replied to.

So a six-part thread is six separate publications, run in order, each depending on the id the previous call returned. Part one posts with no reply object, part two replies to part one’s id, and so on down the chain. There is no transaction around it, and no per-part result object either: each call answers for itself, and the public API hands you nothing afterwards describing the thread as a whole.

Which means a thread can half-publish, and the state is not obvious. Your tool reports a failure. Your timeline shows a normal three-part thread that ends mid-argument, with the payoff and the call to action missing. You find out from engagement, or from a reply asking what happened to the rest.

Recovery depends on one thing: whether your tool stored the id of every part it published, or only a thread-level success flag. With the ids, you resume. Take the id of the last live part, fire part four as a reply to it, continue down the chain. The thread reads as though nothing happened.

Without them, your options are worse. Re-running from part one publishes a second root post and leaves two chains on the same account within minutes, one truncated and one complete: a duplicate, every call paid for again, and the pattern X’s automation rules single out. Otherwise, write the rest by hand under the live tail. Deleting the published parts and starting over is the last resort: it burns any link already shared and costs a delete call per part.

What it costs to automate X posts and threads

X API posting is priced per request. X’s developer access is pay-per-usage and says so plainly: no subscriptions, pay only for what you use. You buy credits up front in the console and they are deducted per request. No monthly plan to size, which is pleasant, and no bundled allowance to fall back on, which is not.

The prices below were read off X’s own developer pricing documentation on 22 October 2026. These two numbers circulate widely on third-party blogs, and until recently that was the only place to find them; they are published first-party now. The same page says prices are subject to change and that the console carries current rates, so treat the table as correct on the date checked.

Write operation	Cost per request
Post: Create	$0.015
Post: Create (with URL)	$0.200
Post: Create (summoned)	$0.010
Interaction: Delete	$0.010
Content: Manage	$0.005

A post containing a URL costs more than thirteen times a plain one. X publishes the number and not the reasoning, so anything you read about why is inference.

Run the arithmetic on a six-part thread with the link in the last part: five plain posts at $0.015 plus one link post at $0.200 is $0.275. Thirty a month is $8.25, which is nothing. Put the link in every part and the same thread costs $1.20. Fan one link post out across eight accounts and each round costs $1.60, and you run into the duplicate-posts rule below. Economics and policy point the same way: one link, in one place, in one account’s thread.

One published limit gets misread constantly. Pay-per-usage is capped at three million Post reads per monthly billing cycle, with Enterprise above that. That is a cap on reads, not on how much you publish. No monthly write cap appears on the pricing page.

On the free tier: X’s pricing page describes no free allowance, only promotional credits for new payers. The widely repeated claim that the free tier closed in February 2026 is third-party reporting, not something X states there, so take that date as reported rather than confirmed. Either way, budget for paid access.

Credentials and media

Posting happens as a user, never as an app. The create-post endpoint lists two user-context schemes: an OAuth 2.0 user token carrying the scopes tweet.read, users.read and tweet.write, or OAuth 1.0a, listed as UserToken. An app-only bearer token is not among the accepted schemes, which is why a half-built X integration fails on publish while its reads work perfectly. Reads are where app-only tokens belong. Writes need a token a human granted.

So your scheduler holds a live user grant for every account it posts to, and keeps it alive from the moment you queue a post until it fires. Revoke the app in your X settings and the queue silently stops being publishable.

Media is a separate pipeline, and not a small one. You cannot attach bytes to a post. Upload first, get a media_id, then pass it in the post’s media_ids array, which takes one to four ids. A post carries up to four photos, one animated GIF, or one video, so a five-image idea is not a post.

The upload itself is chunked, in three steps plus a wait. Initialize, declaring media type and total byte count, which returns the id. Append, once per segment, numbered from zero, segments at or below the recommended five megabytes and never above the eight-megabyte server maximum. Finalize. If finalize comes back with processing information attached, poll a status endpoint until the state reads succeeded or failed, and only then is the id usable in a post. One detail that trips people porting old code: in the X API v2 flow these are distinct endpoint paths, not command values on one upload endpoint, and the documentation says not to send the old command form.

That polling step is the whole reason some tools happily schedule images to X and quietly refuse video. An image is small, finalizes immediately and needs no state machine. A video is multi-segment, asynchronous and can fail during transcoding minutes after your worker thought it was done. The same split shows up elsewhere: see scheduling TikTok videos for a network where video is all that matters, and scheduling LinkedIn carousels for one where the format everyone sells is not the format the API publishes. Video length on X follows the posting account’s Premium or verified status rather than your developer access.

Using a scheduler instead

For almost everyone, buy this rather than build it. The durable timer, the token refresh, the per-part thread state and the retry logic are the actual product, and none of it is interesting work. Build only if posting to X is part of what you sell.

Three questions separate schedulers that handle X properly from ones treating it as a text box with a clock.

• Real thread support. Not a character counter that splits your text, but a composer that queues parts and publishes them as a reply chain. Ask what happens to parts four to six when part four fails.
• Partial-failure handling. Per-part status in the interface, and a resume rather than a blanket retry. If the only state it keeps is published or not, a broken thread is your manual problem.
• Who pays for the posting. Some tools hold their own X developer app and absorb the per-request cost in the subscription. Others ask you to connect your own credentials, and then the link-post premium lands on your card.

SchedPilot is one of the tools holding the platform OAuth itself, so you connect an X account without registering a developer app or managing a token refresh. The drawback is commercial, not technical: there is no free plan, only a seven-day trial that asks for a card, so you cannot try it for nothing. For a wider comparison, including tools that make you bring your own credentials, there is social media automation software compared.

One rule applies whatever you pick: a tool that drives x.com in a browser session instead of calling the API is not a cheaper scheduler, it is a worse risk.

The rules a template queue breaks by accident

X’s automation rules, updated April 2026, are the Twitter automation rules under the platform’s current name: unusually readable, and written for developers rather than marketers. Most of what they forbid, nobody building a scheduler was going to do. One rule is different, because a well-intentioned content queue walks straight into it.

In X’s words: you may not post duplicative or substantially similar posts on one account or over multiple accounts you operate. The next clause extends it to accounts themselves, barring multiple automated accounts for duplicative or substantially similar use cases.

Read that against how template queues get built. An evergreen queue recycling forty posts on a loop produces substantially similar posts on one account by design. A client roster where every account gets the same three industry tips on Tuesday produces them across multiple accounts you operate. A thread template where only the product name changes is the clearest case. None of that feels like spam from the inside, and all of it is what the rule describes.

X draws the line somewhere useful, in the same section: automating multiple accounts for related but non-duplicative use cases is permitted, and X’s own example is separate accounts posting when the Hubble Space Telescope passes over different cities. The test is not whether the accounts are related. It is whether each post carries something the others do not. Same data, different subject, fine. Same post, different handle, not fine.

Three consequences. Rewrite per account rather than per campaign, so a shared source produces different posts. Keep evergreen recycling long-cycle and edited, not forty posts on repeat. And when a thread half-publishes, resume it instead of re-running it, because a re-run is literally a duplicate.

The rest is quicker. Automated likes are out: you may not like posts or hide replies in an automated manner. Following is out in bulk, aggressive or indiscriminate form, and apps claiming to get users more followers are prohibited. Reposting is allowed for entertainment, informational or novelty purposes so long as it is not bulk or aggressive. Non-API automation, scripting the website, gets the page’s strongest language: it may result in the permanent suspension of your account. Do not buy a tool that works that way, however good the demo.

Automated replies are the one people get wrong in both directions. Not banned, not open either. X permits them inside a narrow consent exception: the recipient opted in beforehand by some clear action, you send one automated reply per interaction, you offer an easy opt-out and honour it promptly, and the reply goes to the user’s own post. Replying based on keyword searches alone is named as not permitted, which rules out most of what gets sold as an engagement tool. AI reply bots are allowed in principle but need prior written approval from X. Assuming yours qualifies is how accounts get restricted.

On enforcement, note what X actually names. Alongside suspension, it says it may filter your posts from search results, and the replies section names the removal of your posts from Search. That is the documented version of what people call a shadowban, and X’s page says nothing about telling you it has happened. What X does not publish on that page, or anywhere else we found, is how long a temporary action block lasts. The familiar range of roughly 12 to 48 hours comes from vendor blogs and community reports, so treat it as rough expectation, not policy.

X also requires the label. Its own help page says the automation rules require automated accounts to display labels and to remain connected to a human-run account, so a bot account has two settings to get right: switch the label on, and connect the human-run account that manages it.

What to do next

If you want threads queued and nothing more, buy a scheduler and pick it on the three questions above, not on the calendar screenshot. Ask about per-part thread status before you pay: that one answer tells you whether anyone there has ever debugged a half-published thread.

If you are building, budget the timer and the state before the posting code. Store every returned post id, make resume a first-class operation, and price a realistic month at $0.015 a post and $0.200 for anything carrying a link before checking the console for today’s rate.

Either way, read X’s automation rules yourself rather than a summary, and read the duplicate-posts clause twice. The platform-by-platform view of what each platform allows sits alongside it, and how to automate social media covers the parts of the stack that are not X.