Twitter Post API: Publish Tweets for $0.0016 a Call

The endpoint behind the Twitter post API

Everything below is one route. A plain tweet, a reply and a quote tweet are the same call with different fields set, so there is no second endpoint to learn and no separate reply path to bill. The table is generated from our published OpenAPI document, which is the same file the API reference is built from.

Sample response from POST /twitter/tweet/create

A successful call returns three fields and nothing else. There is no tweet object to parse, because you wrote the text yourself. Store tweet_id if you plan to read the post back, delete it or reply to it later, and treat the URL as a convenience for logs and notifications.

{
  "ok": true,
  "tweet_id": "1759123456789012345",
  "url": "https://x.com/i/status/1759123456789012345"
}

Quickstart: publish your first tweet

Reads work on a Bearer key alone. A post has to come from somebody, so a write needs one extra step that you do once per X account, and that step is free.

1. Create a key at signup. No card is needed and the key works immediately.
2. Register the X account you want to post from with POST /twitter/customer/session, sending its auth_token and ct0 cookies. This call is free and the session stays stored against your key.
3. Send the request below with your key in the Authorization header. The response carries the new tweet_id.

curl -X POST "https://api.twitterapis.com/twitter/tweet/create" \
  -H "Authorization: Bearer $TWITTERAPIS_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text": "Shipping cursor-paginated bookmarks today."}'

import os
import requests

resp = requests.post(
    "https://api.twitterapis.com/twitter/tweet/create",
    headers={"Authorization": f"Bearer {os.environ['TWITTERAPIS_KEY']}"},
    json={"text": "Shipping cursor-paginated bookmarks today."},
)
resp.raise_for_status()
data = resp.json()
print(data)

const resp = await fetch("https://api.twitterapis.com/twitter/tweet/create", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.TWITTERAPIS_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ text: "Shipping cursor-paginated bookmarks today." }),
});
const data = await resp.json();
console.log(data);

What the Twitter post API costs per 1,000 tweets

A write yields exactly one post per call, so the fill is always 1 and the per-1,000 figure is simply the call price times 1,000. There is no empty-page effect to average in, and no tier to climb. The image row adds one upload call, which is priced on its own page.

Prices come from the biller's own rows, and the signup credit of $0.50 covers 312 posts. See all endpoint prices.

Twitter post API options compared

Three things decide this choice for most teams: what a post with a link costs, what you must set up before the first call, and whether you pay for a plan you may not fill. The rates below are each vendor's published figures, read on the date this page was last updated.

Why a link changes the bill on the official API

X split posting into two price bands on April 20, 2026. A plain post stayed at the standard write rate and any post containing a URL moved to its own band, close to 13 times higher. The classifier is binary, so one link anywhere in the body flips the whole post, whether it is a blog announcement or a tracking URL.

That single line is what makes an automated news feed, a release bot or a newsletter cross-post expensive to run on the first-party route. We bill the call and do not read the body for pricing, so a feed that always carries a link costs the same as one that never does. The X API pricing breakdown walks through the full rate card if you are modelling a larger workload.

Replies and quote tweets use the same call

Set reply_to to a tweet ID and the post lands as a reply in that conversation. Set quote to a tweet ID and it lands as a quote tweet. Leave both out and you get a normal top-level post. Each of these bills the same rate, which makes support bots and auto-responders simple to budget.

• Replies. Send the parent ID as a string. It usually arrives from a mentions feed, a webhook or a search result.
• Quote tweets. X withdrew quote-posting through API writes from its self-serve tiers in April 2026, so this field is a real difference on budgets that cannot reach an enterprise contract.
• Images. Pass up to four IDs in media_ids. They come from the media upload endpoint, which is a separate call made first.

Handling errors and retries safely

A post is not an idempotent call, so a blind retry can publish twice. When a request times out, read the account's latest tweets before you send it again. X also refuses an exact duplicate of a recent post, so a retry that fails with a 403 may mean the first attempt landed.

The other statuses are plain to act on. A 401 is a bad or missing key, a 402 means your balance ran out, a 403 means X refused the action for this account or session, and a 429 means slow down and try again. Each one comes back as JSON, and the REST API guide documents the error contract shared by every route.

Scheduling and drafts sit next to this endpoint

If you want a post to go out later, POST /twitter/scheduled/create hands the timing to X so your server does not have to stay awake. POST /twitter/draft/create saves the text without publishing it. Both are documented in the API reference, and our guide to scheduler tools against an API helps you decide which one a workflow needs.

Publish a thread by chaining replies

A thread is not a separate object on X. It is a series of posts where each one replies to the post before it, so you build one by reading tweet_id from each response and passing it as reply_to on the next call. The example below publishes three posts in order and stops at the first failure, which leaves a clean partial thread rather than a gap in the middle.

Each post in the chain bills as one create call, so a five-post thread costs five times the single-post rate. Keep a short pause between calls if you publish long threads, and save each tweet_id as you go so a crash can resume from the last post that landed. The same loop drives a reply bot, where the first reply_to is someone else's tweet.

import os
import time
import requests

API = "https://api.twitterapis.com/twitter/tweet/create"
HEADERS = {"Authorization": f"Bearer {os.environ['TWITTERAPIS_KEY']}"}

parts = ["First post in the thread.", "Second post.", "Third and last."]
previous = None

for text in parts:
    body = {"text": text}
    if previous:
        body["reply_to"] = previous
    resp = requests.post(API, headers=HEADERS, json=body, timeout=30)
    resp.raise_for_status()
    previous = resp.json()["tweet_id"]
    time.sleep(2)

Worked budgets for common posting jobs

Posting volumes are usually small, which is why the link band matters more than the base rate. A release bot that posts ten times a day sends about 300 posts a month, which bills $0.48 here. The same feed on the official API costs $4.50 if none of the posts carry a link and $60 if all of them do, at the published $0.015 and $0.20 rates.

Multiple accounts do not change the arithmetic, because the price is per call and not per seat. One key can drive many X accounts, because a session can be registered ahead of time or passed on the request, so an agency can run many brands from a single balance. Our answer on using multiple X accounts with one API key shows how to pick the acting account on each request.

• Getting a key. The API key page covers how keys are issued and rotated, and it takes under a minute.
• Reading what you posted. A tweet by ID lookup returns the counters on your post, so you can measure each one.
• Watching for replies. A webhook tells you when an account you watch posts, and it is free to call.
• Other write actions. Likes, reposts and bookmarks live on the Twitter engagement API, and follows on the follow API.

Keeping the posting session healthy

Every write depends on the session you registered, so a posting job needs a small health check of its own. Logging out of X on the browser that issued the cookies can end the session, and so can a password change or a security challenge. When that happens, writes start failing while reads carry on working, which is easy to miss if your alerts only watch the read side.

Call GET /twitter/customer/session/status before a scheduled batch and alert a person when it reports a problem. Register fresh cookies with the same call you used the first time, and remove a session you no longer need with POST /twitter/customer/session/delete. Treat auth_token and ct0 like passwords: keep them in a secret store, never in source control, and limit who can read them. The authentication guide covers how the key and the session fit together.

• Log every post. Store the tweet_id, the text and the time, so you can audit what a bot published and delete a mistake quickly.
• Separate test and live accounts. Point development at a throwaway account, since a post from a test run is public the moment it lands.
• Add a kill switch. Keep one config flag that stops all automated posting without a deploy, for the day a feed goes wrong.

Post from an AI agent through the MCP server

The same action is available to Claude, Cursor and other MCP clients as a tool, so an agent can draft a post and publish it on the account you registered. Keep a human approval step in front of it if the account matters, because the tool publishes immediately. The MCP page lists every tool and client config.

• twitter_create_tweet calls POST /twitter/tweet/create

npx -y @twitterapis/mcp@latest