X (Twitter) API Posting Limits 2026: Tweets Per Day

By Sorsa Editorial

Updated July 2026: reflects X's pay-per-use write pricing after the April 20, 2026 repricing (standard post $0.015, URL post $0.20), the move of following, likes, and quote-posts to Enterprise-only self-serve access, and current account-level posting caps re-checked against X's own limits documentation.

Posting through the X API in 2026 runs into three separate ceilings, not one, and they are enforced independently. The API endpoint has its own per-app and per-user rate limits. The X account you post from has platform-wide daily caps that apply whether the post came from a script or the mobile app. And on pay-per-use, every post created is billed, with a hard 2 million post-read cap sitting on the read side of the same account. Any one of the three can return an error, which is why "my code is nowhere near the rate limit" is one of the most common and confusing complaints from developers automating X.

This guide covers all three layers with current numbers, verified against X's own documentation. We build and run Sorsa API, an alternative Twitter/X API for reading public X data, so posting itself is not our lane: writes belong on the official API, and these are the limits you live with there. Where we can help is the other half of most posting workflows, the reading part, confirming a post went live, pulling its engagement, or monitoring mentions after publishing, which the sections below flag where relevant. The posting numbers here are what the official X API gives you right now.

Last verified: July 6, 2026, against X's official rate-limit and account-limit documentation.

Table of Contents

• How X API posting limits work
• How many tweets can you post per day via the X API?
• Rate limits for replies, deletes, and direct messages
• What about likes, follows, and reposts?
• Does the X API free tier let you post in 2026?
• The 30-minute window that stops most automations
• What happens when you hit a posting limit
• How to post at scale without tripping limits
• FAQ

How X API posting limits work

X enforces posting on three independent layers in 2026: the API rate limit on the write endpoint, the account-level daily cap on the X account itself, and the pay-per-use billing that meters every post created. A request can fail against any of them, and each returns a different signal.

The first layer is the API rate limit. The write endpoint (POST /2/tweets) allows 100 posts per 15 minutes per user and 10,000 per 24 hours per app. These are rolling windows that start from your first request, not from a fixed clock time, and breaching one returns HTTP 429.

The second layer is the account cap. Every X account is bound by platform-wide posting limits that apply across web, mobile, and API together. X's own limits documentation is explicit that these daily caps count actions "from all devices, including web, mobile, phone, API," so an automated post and a manually typed post draw from the same daily budget. This is the layer most guides miss, and it is usually the one that actually stops a bot.

The third layer is billing. Since X moved to pay-per-use in February 2026, each post created costs money ($0.015 for a plain post, $0.20 for a post containing a URL as of the April 20, 2026 repricing), and the account carries a separate hard cap of 2 million post reads per month on the read side. You can sit comfortably inside your posting rate limit and still get blocked on reads, or watch a link-heavy publishing workflow become expensive fast. The full per-action cost picture, including the URL premium and the deduplication window, sits in the 2026 X API pricing breakdown.

The practical takeaway: the API rate limit is rarely the binding constraint for posting. The account cap almost always is.

How many tweets can you post per day via the X API?

Through the API alone, a single authenticated user can post up to 100 tweets per 15 minutes, and one app can post up to 10,000 per 24 hours across all its users. But the X account those posts come from is capped separately at the platform level, and that account cap is lower than the API ceiling and usually what stops the automation.

Here is how the two layers stack for a single account:

The rolling 30-minute window of roughly 50 posts is the one that catches people, especially during rapid reply sessions or thread runs. The daily account cap for unverified accounts has historically sat at 2,400 posts per day (with replies, reposts, and quote-posts widely reported to count toward it), and reporting through 2026 continues to cite that figure, though several sources indicate X tightened the unverified daily ceiling sharply in mid-2026. X's published numbers shift without notice and its own help pages have lagged behind the changes, so treat the exact daily figure as volatile and confirm it against X's limits page before architecting around it. What is stable is the shape: verified (Premium) accounts get a much higher daily ceiling, around 10,000 posts, while the ~50-per-30-minutes window applies regardless of verification.

The trap is designing around the API limit. A developer reads "100 posts per 15 minutes" (nearly 9,600 a day per user) and builds for that, then the bot stalls far earlier because the account-level cap and the 30-minute window bind first. For an unverified account running automation, the account cap is the real ceiling, not the API window.

This layered behavior also shows up on the read side, where the 15-minute windows and per-app versus per-user pools cause most collection-pipeline 429s. Those read limits are covered endpoint by endpoint in the companion X API rate limits reference.

Rate limits for replies, deletes, and direct messages

Posting a top-level tweet, posting a reply, deleting a tweet, and sending a direct message each run under separate write limits on the X API. A reply uses the same POST /2/tweets endpoint and limit as an original post, but deletion and DM sending are stricter and are governed by their own windows.

Deletion is the one that surprises people running cleanup jobs. At 50 deletions per 15 minutes per user, clearing 1,000 old tweets takes roughly five hours of wall-clock time, paced across twenty windows, and there is no batch delete endpoint to speed it up. Tools that wipe large timelines succeed by designing the wait states in, not by retrying faster.

Replies carry their own account-level cap on top of the API limit. For unverified accounts that reply cap has been reported at 200 per day, separate from the original-post budget, so a bot that answers mentions can exhaust its reply allowance while the original-post budget is untouched.

Direct messages are deliberately slow. At 15 sends per 15 minutes per user plus a 1,440-per-24-hours ceiling, and a platform-level cap widely cited at around 500 DMs per day per account, automated messaging hits a wall quickly by design. None of these write actions has a read-only equivalent: reading DM history, for instance, is also gated at 15 requests per 15 minutes, so DM-heavy workflows are constrained on both ends.

What about likes, follows, and reposts?

Following accounts, liking posts, and quote-posting changed access tier in 2026. Effective April 20, 2026, X moved these engagement write actions off self-serve pay-per-use and made them Enterprise-only, so an automation that likes, follows, or quote-posts programmatically now needs an Enterprise contract rather than a standard developer app. Posting and direct messages stayed on pay-per-use.

Before that change, the published API limits for these actions were tight: likes and follows ran at roughly 50 per 15 minutes per user, with additional 24-hour ceilings, and reposts at a similar cadence. Those numbers are now moot for self-serve users, because the endpoints are gated behind Enterprise access entirely.

At the account level, follows remain capped separately from posts. Unverified accounts are widely reported at around 400 follows per day and Premium accounts at roughly 1,000, with X watching for follow-unfollow cycling patterns that trip restrictions even when the daily number is not breached. Likes have no publicly documented account limit, but aggressive automated liking reliably triggers behavioral throttling.

If your workflow depends on programmatic engagement writes, the official API's Enterprise tier is the compliant path, and there is no read-only substitute for a write action. What a read API does cover is the measurement side: instead of liking or following, you read who engaged. Pulling the accounts that reposted or replied to a campaign tweet is a read operation, handled by endpoints like the retweeters and repliers lookup, which keeps that data collection off any user account entirely.

Does the X API free tier let you post in 2026?

There is no general free X API tier for new developers in 2026. X discontinued the standalone free tier when pay-per-use launched in February 2026, so a new account must buy credits before posting a single tweet. Whether the X API is free at all in 2026 has one answer for new signups: it is not.

For anyone still holding a legacy free-tier app, the posting allowance was always minimal by design. The legacy free tier was write-only and metered in 24-hour windows, and the documented POST /2/tweets allowance was 17 requests per 24 hours shared across the whole app (some sources cite a higher monthly figure that applied to the older v1.1 path, which is the root of the 17-versus-50 confusion you will see across guides). Either way, it was a stub meant for testing a posting integration, never for running one at volume, and it granted zero post-read access.

So the free tier never supported posting at scale, and for new developers it no longer exists. If what you actually need to test is reading X data rather than posting it, third-party access is the practical free path. Every new Sorsa account starts with 100 free requests, one-time, with no card required, and they never expire. They cover all 40 read endpoints at the same flat rate as paid plans, which through the batch endpoints is enough for up to 10,000 tweets or 20,000 profiles before anything is paid. That is a real workload for validating a read integration, well beyond the small trial credits most providers hand out.

The 30-minute window that stops most automations

The single limit that catches the most posting automations is not a daily total. It is the rolling window of roughly 50 posts per 30 minutes that X enforces at the account level, on top of the daily cap and independent of the API rate limit. Live-tweeters, thread runners, and reply bots hit this constantly, well before any daily ceiling comes into view.

The reason it is so easy to trip is that it counts everything: original posts, replies, reposts, and quote-posts all draw from the same 30-minute budget. A bot answering a burst of mentions, or a thread being posted tweet by tweet in a tight loop, can exhaust 50 actions in under a minute and then stall for the rest of the window.

There is a second, quieter blocker layered on top: duplicate detection. X rejects posts with identical or near-identical text published within roughly a 24-to-48-hour span, returning error code 187. Automations that recycle the same message, common in evergreen posting or multi-account setups, trip this even when they are nowhere near any rate limit. The fix is trivial, changing even a character or a piece of punctuation clears the duplicate check, but it has to be built into the workflow.

The practical rule for pacing writes: stay under the 30-minute window, not just the daily cap. Queue replies and thread segments in batches of 10 to 15 with deliberate gaps between them, and vary any recycled text. Designing to the daily number alone is exactly how automations stall mid-run.

What happens when you hit a posting limit

When you exceed an API rate limit, X returns HTTP 429 with error code 88:

{
  "errors": [{
    "code": 88,
    "message": "Rate limit exceeded"
  }]
}

The response still carries the rate-limit headers, which is the part that matters. x-rate-limit-reset is a Unix timestamp for when the window reopens, so a write worker never has to blindly sleep for a fixed interval. Account-level cap breaches and duplicate rejections surface differently: an account cap tends to return a 403 or a posting-restriction notice rather than a 429, and a duplicate returns error 187, so a well-built poster distinguishes the three rather than treating every failure as a rate limit.

A reset-aware retry for the write path looks like this:

import time
import requests

def post_tweet_with_retry(text, headers, max_retries=3):
    url = "https://api.x.com/2/tweets"
    for attempt in range(max_retries):
        response = requests.post(url, headers=headers, json={"text": text})

        if response.status_code != 429:
            return response

        reset = int(response.headers.get("x-rate-limit-reset", 0))
        wait_seconds = max(reset - int(time.time()), 1)
        print(f"Rate limited. Waiting {wait_seconds}s until the window resets.")
        time.sleep(wait_seconds + 1)  # +1s buffer

    raise Exception("Rate limit retries exhausted")

Two things to watch. First, do not retry instantly on a 429, because a tight retry loop burns the remaining budget across other endpoints on app-only auth. Second, check x-rate-limit-remaining before each write and slow down when it drops into single digits, rather than waiting for the hard stop. In a bulk posting or deletion loop, one unhandled 429 can cascade into a run of failures before the code notices.

How to post at scale without tripping limits

Getting real posting volume through the X API is less about the daily ceiling and more about pacing under the 30-minute window and the account cap. These are the moves that actually change the outcome.

1. Pace to the 30-minute window, not the daily cap. Keep writes under roughly 50 per 30 minutes per account, batching replies and thread segments in groups of 10 to 15 with gaps. This is the limit that binds first for almost every automation.

2. Use a verified (Premium) account for high-volume publishing. The daily account cap for Premium sits far higher (around 10,000 posts) than the reported unverified ceiling, so the account layer stops constraining you and the API write limit becomes the real bound.

3. Vary any recycled text to clear duplicate detection. Error 187 rejects near-identical posts within a 24-to-48-hour span. Rotate wording, or append a unique element, on evergreen or multi-account posting.

4. Watch the URL premium in your cost model. A post containing any link is billed at $0.20 versus $0.015 for a plain post, more than 13 times the cost, so a link-heavy publishing workflow can run into real money fast. The math behind that jump is in our look at why the X API gets so expensive.

5. Separate write queues from read queues. Posting and reading draw from different limits and, on pay-per-use, different caps (the 2 million monthly post-read cap is separate from any write budget). Keeping the queues independent means a read backlog cannot block a scheduled post, and vice versa.

That last point is where most production posting setups end up split across two providers, and it leads straight into the practical pattern below.

Posting versus reading: which API for which job

Most real X workflows do both, and the two halves belong on different infrastructure in 2026. Writing to X (posting, replying, sending DMs) is a first-party action that has to run on the official API, under the limits above and on user-authenticated tokens. Reading X at volume (verifying a post published, pulling its engagement, monitoring mentions, collecting timelines) is where the official per-resource pricing and per-endpoint windows get expensive and awkward, and where a flat-rate read API is a cleaner fit.

• Automated posting, replying, DMs: the official X API, on pay-per-use or Enterprise. There is no compliant read-only substitute for a write.
• Programmatic likes, follows, quote-posts: the official X API's Enterprise tier, since these left self-serve on April 20, 2026.
• Confirming posts went live, pulling engagement, monitoring mentions, bulk reads: a read-focused alternative such as Sorsa, at a flat 20 requests per second with no per-endpoint windows and reads from $0.02 per 1,000 tweets on the batch base.

The honest split is worth stating plainly: if you need to write to X, that is the official API's territory, and nothing here changes that. For the read-heavy half of the same workflow, a flat, predictable read API removes the 15-minute windows and the per-resource billing. Moving just the reads across is a common first step, and the migration path from the official API covers doing it without touching the write side.

In practice: an agency that kept getting posting-restricted

A social agency (around a dozen people) running scheduled posts for clients kept hitting posting restrictions they could not explain. Their scheduler was architected around the API's "100 per 15 minutes" figure, but client accounts kept getting locked mid-campaign. The cause was the account layer: unverified client accounts were hitting the platform daily cap and the 30-minute window long before the API limit mattered, and reposts were quietly counting toward the same budget.

The write fix was operational, not a migration: they moved high-volume accounts to Premium, paced posting under the 30-minute window, and varied recycled copy to stop tripping error 187. The write path stayed on the official API, where it belongs. What did move was the read-heavy reporting layer, confirming posts went live and pulling per-post engagement for client dashboards, which had been quietly burning toward the 2 million monthly read cap. On flat per-request pricing that read work runs up to 50x cheaper per read than the official per-resource model, and the reporting bill dropped into the low hundreds a month while the posting restrictions cleared once the pacing was fixed.

FAQ

How many tweets can you post per day with the X API in 2026?

The X API write endpoint allows 100 posts per 15 minutes per user and 10,000 per 24 hours per app. The lower binding limit is the account cap: Premium accounts get around 10,000 posts per day, while unverified accounts sit far lower, and a rolling window of roughly 50 posts per 30 minutes applies to any account regardless of verification, catching most automations first.

What is the X API rate limit for deleting tweets?

Tweet deletion via DELETE /2/tweets/:id is capped at 50 requests per 15 minutes per user, and there is no batch delete endpoint. At that pace, clearing 1,000 tweets takes roughly five hours of wall-clock time, spread across twenty windows. Large cleanup jobs succeed by building wait states between batches rather than retrying faster, since the pauses are the API working as designed.

Can you post tweets with links through the X API, and what does it cost?

Yes, but posts containing a URL are billed at $0.20 each on pay-per-use as of the April 20, 2026 repricing, versus $0.015 for a plain-text post, more than 13 times the cost. A workflow auto-publishing newsletter links, blog posts, or affiliate URLs at volume gets expensive fast, so the URL premium belongs in any cost model before shipping a link-heavy posting automation.

Does the X API free tier allow posting in 2026?

No general free tier exists for new developers. X discontinued it when pay-per-use launched in February 2026, so new accounts must buy credits before posting. The legacy free tier was write-only and allowed only about 17 posts per 24 hours across the whole app, with zero read access. For testing reads instead, Sorsa API includes 100 free requests on signup, no card required, covering all 40 endpoints.

Why do I get a 429 error when I am under my posting rate limit?

A 429 means an API window was exceeded, but posting failures often come from a different layer. The account-level daily cap and the ~50-per-30-minutes rolling window count API and manual posts together and usually bind before the API limit, typically returning a 403 or restriction notice. Duplicate near-identical text returns error 187. Distinguish the three rather than treating every failure as a rate limit.

How do developers get high read throughput without hitting these limits?

Posting stays on the official API, but read-heavy work moves to a flat-rate alternative to avoid the per-endpoint windows. Sorsa API, for example, serves all 40 read endpoints at 20 requests per second on every plan, from $0.02 per 1,000 tweets on the batch base, with plans starting at $49 a month. At read scale that lands up to 50x cheaper per read than the official per-resource pricing.

Getting started

If your posting workflow also has to read X data, confirming posts went live, pulling engagement for reporting, or monitoring mentions after publishing, that read side is where the official per-endpoint windows and per-resource billing hurt most, and where a flat-rate read API is the cleaner fit. The quickest way to feel the difference is to run a few calls yourself: the interactive API playground executes live endpoints in the browser with no key and no signup, so you can check the response shape first. When you are ready to build, the Sorsa API quickstart gets you authenticated with a single API key in a few minutes, every new account includes 100 free requests (one-time, no card, never expiring, all 40 endpoints, enough for up to 10,000 tweets or 20,000 profiles), and flat pricing plans run from $0.02 per 1,000 tweets on the batch base, from $49 a month, at 20 requests per second with no per-endpoint windows to manage. Writing to X stays on the official API; the reading half does not have to.

Reviewed by Keksich, founder of Sorsa, marketer and X API researcher.

How this guide was put together: the API write and delete limits, the 429 body, and the endpoint paths were read straight from X's official rate-limit tables, and the account-level posting caps from X's limits documentation, both re-checked on July 6, 2026, because these numbers change without much notice and X's own help pages have lagged the changes (which is the source of the conflicting daily-cap figures across the web; where sources disagreed, the volatile figure is flagged rather than stated as settled). The posting-pace and duplicate-detection tactics, the 429-recovery code, and the three-layer framing come from our own work operating a read-focused Twitter/X API and from the read-pipeline migrations our team handles, including the anonymized agency case above (details merged and stripped of anything identifying). Pricing figures are summarized from our separate X API pricing coverage. For who we are and how to reach us, see About Sorsa. No statistics, sources, or client outcomes here are invented.