X Free Tier: What You Can Post Per Day

Most guides on X limits describe one enforcement system. There are two, and they run independently. The API free tier capped writes at 17 posts per 24-hour rolling window. A separate account-level system caps free unverified accounts at 50 original posts per day, whether the request comes from an OAuth token, a browser, or a real-browser agent.

What Were the X API Free Tier Posting Limits?

The X API free tier gave you 17 posts per 24-hour rolling window, counted per user and per app, with a hard ceiling of 500 posts per calendar month. That monthly number used to be 1,500. X cut it in late 2024, and the cut is what turned the monthly cap from a formality into the limit most projects hit first.

Do the arithmetic and the design of the plan becomes clear. Seventeen posts a day across thirty days lands at roughly 510, which sits just above the 500 monthly ceiling. A developer posting at a steady daily pace ran out of month before running out of day. A developer posting in bursts, heavy on some days and silent on others, never saw the monthly cap at all. Same plan, two entirely different experiences of where the wall sits, and which wall you hit depended on your posting rhythm rather than your total volume.

The 24-hour window rolls. It does not reset at midnight, and this is the single most common misreading of the free tier we encountered in support conversations. The window starts from the first POST /2/tweets request inside it. A client that publishes late in the evening can publish again at the same hour the next evening, not at the stroke of midnight. Scheduling logic written against a calendar day will drift into the previous window and start eating quota that the developer believes has already been refreshed.

When you exceeded the limit, the API answered with HTTP 429 and an x-rate-limit-reset header. That header carries a Unix timestamp of when the window expires, not a countdown in seconds. The distinction is small on paper and expensive in production. Client code that treats the value as a duration will sleep for something close to the epoch and either retry immediately or park itself for decades, depending on how the arithmetic goes wrong. Code that reads it as an absolute time knows precisely when the next write will succeed and can schedule against it without guessing.

The free tier covered POST /2/tweets and a narrow set of read endpoints. It did not include the Like or Follow endpoints even before those were formally pulled in August 2025, which is a detail worth holding onto: the free tier was already a write-only sliver of the API long before X started shrinking it publicly. Developers who built engagement features on the free plan were building on endpoints they never had permission to use in the first place.

The larger point is that 17 was never the X posting limit in any general sense. It was the limit for one authentication path, applied to one credential type, in one plan tier. Plenty of tools shipped with 17 hardcoded as a safety ceiling and told their users that this was what X allows. It was not. It was what the free OAuth token allowed, and the account behind that token was operating under a completely different set of rules at the same time.

The X API Free Tier Is Gone for New Developers

As of February 2026, there is no standalone free tier for new developer signups. New applications go straight onto a mandatory pay-per-use model that requires pre-loaded credits before the app can make a single write call. There is no free allowance of any kind, no trial quota, and no grandfathering for accounts created after the cutoff. If you are reading a tutorial that opens with sign up for the free tier, that tutorial is describing a plan that no longer exists.

The erosion started earlier and it started without warning. On August 22, 2025, X removed the Like and Follow endpoints from the free tier. Apps calling POST /2/users/:id/likes and POST /2/users/:id/follows stopped working that day. No deprecation window, no migration path, no advance notice in the developer changelog. Anyone whose product depended on programmatic engagement discovered it from user complaints rather than from X. That announcement is the clearest signal in the whole timeline: the free tier was not a supported product being maintained, it was surface area being reduced.

Pay-per-use pricing is where the current model gets interesting, because it is not flat. A plain text or media post costs $0.015. A post containing a URL costs $0.20, which is 13 times more expensive. X has priced link distribution as a premium action, and every marketing automation tool built around driving traffic to an external site is now paying the expensive rate on essentially every post it makes. The read side runs at $0.005 per post read with a ceiling of 2,000,000 post reads per month.

That URL surcharge changes what a sensible automation strategy looks like. If your posting workflow is link-heavy by default, the cost of the same content volume moves by more than an order of magnitude depending on whether you put the link in the post body. Tools that batch link posts through the API are now the most expensive way to do the least algorithmically favored thing on the platform, which is a rough combination.

Legacy customers did not escape the change. Basic plan subscribers paying $200 per month on a flat rate were automatically migrated to pay-per-use billing after June 1, 2026. Developers whose real usage sat well under $200 of metered value saw their bills fall. High-volume users, particularly anyone posting links, saw them rise. The flat-rate era ended quietly and the migration was automatic rather than opt-in.

The practical conclusion for anyone planning a build in 2026: the API is a paid dependency with variable cost tied to post content, and the free tier is not a foundation you can plan around. That is a real constraint, and it is the reason the rest of this guide spends most of its time on the other enforcement system, the one that applies to your account no matter how you authenticate.

X API Rate Limits vs Account-Level Caps: Not the Same System

X enforces posting limits at two layers that do not talk to each other. API tier rate limits are enforced at the OAuth token layer: roughly 17 posts per day on the old free tier, approximately 100 per day on Basic, approximately 300 per day on Pro. Those quotas are attached to developer credentials and they apply only when a request arrives carrying those credentials. They have no effect on a browser session.

Account-level posting limits apply to the account itself, no matter how the post was created. Browser, mobile app, real-browser automation driving a session cookie, direct API call: all of it counts against the same ceiling. Free unverified accounts sit at approximately 50 original posts per day and 200 replies per day, a cap introduced in mid-May 2026. Premium and verified accounts are described as having no practical limits for normal use, though the burst sub-window covered in the next section still applies to every tier.

The independence of the two systems produces results that look like bugs if you are only watching one of them. An account that has used none of its API quota for the day can still be refused a post, because it burned the account-level ceiling through browser activity that morning. The reverse also holds: an account with plenty of account-level headroom will still receive HTTP 429 the moment the token quota is exhausted. Both meters can run down at once, and the tighter of the two is the one you feel.

A real-browser automation agent that authenticates with session cookies rather than OAuth tokens does not consume API quota at all. This is the observation that changes the arithmetic for most practitioners, and it is missing from every competitor page we have read on this topic. A browser agent posting from a home IP is not making API calls. It is a session. Its ceiling is the account-level 50 posts per day, not the API tier's 17.

Watch how the two mental models diverge. An API-only operator sees 17 as the number, treats it as the platform constraint, and designs a content schedule around a hard daily maximum of 17. A browser-automation operator on the same free account has roughly three times that headroom and never touches a developer credential. Neither is misreading the documentation. They are reading two different pieces of documentation that describe two different enforcement systems, and X has never published a page that puts them side by side.

This is also why so much advice about X automation contradicts itself. One writer reports a hard ceiling in the teens, another reports posting dozens of times a day without trouble, and both are telling the truth about their own setup. Before you can evaluate any claim about X posting limits, you need to know which authentication path the person making it was using. If they do not say, the number is close to useless.

Watch the 30-Minute Burst Window: It Catches Most Automation Tools

Underneath the daily caps sits a sub-daily one that almost nobody writes about: approximately 50 posts per 30-minute rolling window, applied through the web interface across all account tiers. It runs independently of the 24-hour ceiling. You can be nowhere near your daily allowance and still be blocked, because the constraint being enforced at that moment is rate, not volume.

In operational terms, this is the limit that catches automation tools first, and the daily cap is the one everybody codes against. Posting 10 tweets in 8 minutes from a browser session will trip the sub-window before the daily cap is anywhere in sight. The session then receives a temporary posting block, typically 15 to 30 minutes, and the browser interface displays no explicit error explaining what happened. From the tool's perspective, posting simply stopped working for a while and then started working again.

The fix is unglamorous and it works: space posts a minimum of 3 to 5 minutes apart, with occasional longer gaps so the cadence does not read as metronomic. That pacing keeps an account inside the sub-window even when it is running at near-maximum daily volume. It also costs you nothing, because the daily ceiling is the real capacity constraint and a well-spaced schedule reaches it comfortably within a normal working day.

Tools that judge success by HTTP response codes will not see any of this. A browser session blocked during the burst window frequently returns nothing that looks like a failure to the calling code. The request completes, the automation logs a success, and the post does not exist. We have watched teams debug this for days, checking API status pages and rewriting retry logic, when the answer was that their posting loop had no delay in it.

There is a second-order effect worth naming. Once a session has tripped the burst block, a tool with aggressive retry behavior will hammer the same endpoint through the block period, and that pattern is far more visible to X than the original burst was. The recovery behavior draws more attention than the mistake. If your automation detects a posting failure, the correct response is a long backoff, not a tight retry loop.

Burst pacing is one of the few areas where the human-imitation framing is genuinely useful rather than hand-waving. A person composing original posts does not publish ten of them in eight minutes. An account that does is producing a signature no human session produces, and the enforcement it meets is proportionate to how obvious that signature is.

If You Post Through a Browser, Your IP Address Matters More Than Your API Plan

There is a third enforcement layer that appears in no documentation at all, and it is tied to the reputation of the IP address your session comes from. A home residential IP with no prior flag history will carry 30 posts per day through a browser session without friction. The identical account, at the identical volume, routed through a flagged datacenter IP or a shared VPN exit node, starts producing CAPTCHA challenges and account-level rate warnings as early as post 8 to 10 per day.

Same account. Same content. Same pacing. Different IP, and the effective ceiling drops by most of its value. The enforcement is happening at the IP-trust layer, not the quota layer, and it produces no consistent HTTP error code you can branch on. What you see instead are CAPTCHA prompts in the browser, post confirmation screens that hang longer than they should, and rate-warning banners in the UI. None of those symptoms map to a published limit, and none of them tell you which of the three systems just stopped you.

The result is an undocumented ceiling that sits well below the documented 50-post daily cap for any account posting from non-residential or previously flagged address space. You will not find that ceiling in X's developer docs or in the help center, because from X's perspective it is not a limit, it is a risk score. The number you can reach is whatever your IP's history allows on that particular day, and it can move without anything on your side changing.

Shared infrastructure is the specific trap. A residential proxy pool sounds like the safe option until you consider that the exit node you drew was used by somebody else an hour ago, for something less careful than what you are doing. Your account inherits their history. This is the same dynamic that makes shared IPs risky for other social platform automation, and X is no gentler about it than anyone else.

The clean way to think about it: residential IP quality matters for browser-session posting the way OAuth token tier matters for API posting. Different layer, same consequence. If your API plan is the thing you optimized and your traffic egresses through shared infrastructure, you have paid to raise a ceiling you are not the one hitting.

One practical note for anyone diagnosing this. Because the IP layer produces no error code, the only reliable way to confirm it is a controlled comparison: run the identical account and identical schedule from a clean residential connection, and see whether the friction disappears. If it does, no amount of pacing work on the automation side will fix what the network path is causing.

New Accounts Need a Warmup Period Before the Published Cap Applies

The published 50 posts per day figure assumes a level of account trust that a new account has not built yet. A freshly created account that attempts 50 posts on day one will be soft-suspended or shadow-limited, and it will be limited even though every individual post returns HTTP 200 OK. Nothing in the response tells you the account has been throttled. The posts exist. They just go nowhere.

What works in practice is a gradual ramp. Start at 3 to 5 posts per day during the first week, scale to 15 to 20 by week three, and expect full throughput only after 4 to 6 weeks of consistent, human-paced activity. That schedule is slower than most people want and it is the difference between an account that reaches its documented ceiling and one that quietly never does. The warm-up window appears nowhere in X's published documentation, and API-focused rate limit guides do not mention it because from the API's point of view it does not exist.

The same constraint applies to revived accounts, which surprises people. An account that has been dormant for several months and resumes at full volume gets treated much like a new one. Trust decays with inactivity. If you are bringing an old account back into a posting rotation, ramp it as if it were new rather than assuming its history carries forward intact.

Shadow-limiting during warmup is invisible at the protocol layer, and that is what makes it operationally nasty. Every post clears. Every log line says success. The account timeline shows the content sitting there exactly as expected. Meanwhile impressions sit near zero and the posts do not appear in follower feeds. The only signal available is engagement data tracked over time, which means detection requires you to be measuring reach rather than delivery.

This inverts the usual debugging instinct. When automation breaks, the first thing most engineers check is the error log, and the error log is empty. The account looks healthy in every dimension the tool can see. We have watched teams conclude their content was simply underperforming when the account was throttled the entire time, which is a much more expensive mistake than a visible failure would have been.

The counterintuitive takeaway: the fastest route to high daily posting volume on X is to post very little at the start. Rushing the ramp does not get you to 50 posts a day sooner. It gets you an account that is limited below the documented cap for weeks, with no error message explaining why, and with a trust history that now includes a burst pattern you have to grow out of.

Three Ways X Signals You Have Hit a Posting Limit

X has three distinct ways of telling you to stop, and only one of them is a real error. Knowing which signal you are looking at determines whether you should wait, change your content, or change your infrastructure. Treating all three as rate limiting is the single most common cause of automation that never gets fixed.

The first signal is clean. For API consumers, exceeding the token quota returns HTTP 429 with an x-rate-limit-reset header carrying the Unix timestamp of when the current window expires. The wait is not a fixed duration and cannot be assumed to be one, because the window began whenever the first request inside it was made. Read the timestamp, schedule against it, and your retries land exactly when capacity returns. This is the only limit signal in the entire system that gives you a precise answer.

The second signal is a rejection that has nothing to do with quota. Posting duplicate or near-identical content within approximately 24 to 48 hours returns error code 187 at the account level, no matter how much API headroom you have left. This is a content check, not a rate check. Automation that recycles evergreen posts or rotates through a small template pool will hit 187 with a completely empty rate meter, and no amount of backoff will help, because time is not the variable that needs to change.

The third signal is not a signal. Posts made in the final 10 to 15 attempts of a session near the account-level daily ceiling routinely return HTTP 200 OK and receive zero algorithmic distribution. Impressions are near-zero. The post does not appear in follower feeds. Nothing in the response, the status code, or the account timeline indicates anything went wrong. The only way to detect it is to monitor post-level reach over time and notice that the tail end of every day produces content nobody sees.

Silent delivery failure is the most operationally damaging of the three by a wide margin, and it is the one API-first tooling is structurally blind to. A tool that defines success as a 2xx response will report a perfect day while a meaningful share of that day's output went into a void. The account looks fine. The dashboard looks fine. The audience saw a fraction of what was published.

The design implication is straightforward and most tools ignore it: response codes confirm acceptance, not delivery. If your workflow needs to know whether a post reached anyone, it has to check impressions after the fact rather than trusting the write path. That is a harder thing to build than a status code check, and it is the difference between knowing your automation works and assuming it does.

Put the three systems together and the picture is coherent. The API quota is documented, precise, and increasingly a paid product. The account-level cap is documented as a number but not as a mechanism, and it governs everything including browser automation. The IP-trust and warmup layers are undocumented, produce no error codes, and quietly set the ceiling you will experience in practice. Build for all three, because X only ever tells you about the first.

Frequently asked questions

How many posts per day can you make on X without a paid API plan in 2026?

For new developers in 2026, there is no free API tier. X discontinued it in February 2026; new signups require pay-per-use billing. For account-level posting through a browser with no API involvement, free unverified accounts are capped at approximately 50 original posts per day and 200 replies per day, subject to a separate 30-minute burst sub-window of roughly 50 posts per half-hour.

Is the X API free tier still available for new developers in 2026?

No. X discontinued the standalone free tier for new developer signups in February 2026. New applications now require pre-loaded credits under a pay-per-use model with no free allowance. Developers who had active free tier access before the cutoff retained it, but the Like and Follow endpoints on that plan were removed without warning on August 22, 2025.

What is the difference between the X API daily post limit and the account-level posting limit?

They are separate systems enforced at different layers. The API daily post limit applied only to requests made with OAuth developer credentials. The account-level posting limit, approximately 50 original posts per day for free unverified accounts, applies to all posting activity on an account regardless of whether it comes from an API call, a browser session, or automation using session cookies. The two systems run independently and can both apply simultaneously.

Does posting through a browser or browser automation tool count against the X API free tier quota?

No. Browser-based posting, including real-browser automation that authenticates via session cookies rather than OAuth tokens, is subject to account-level caps rather than API tier quotas. A browser automation agent can post up to 50 times per day on a free unverified account without consuming any API quota. The relevant constraints are the account-level daily cap, the 30-minute burst sub-window, and the IP reputation layer.

What happens when you hit the X daily posting limit? Do you get an error or does it silently fail?

It depends on which limit you hit. The API returns HTTP 429 with a reset timestamp when the API quota is exceeded. At the account level, posts made near the daily ceiling often return HTTP 200 OK but receive zero algorithmic distribution; they appear to succeed but are not shown to followers. Duplicate content returns error code 187. Silent failure is the most common outcome for browser-session posting near the cap.

How does X enforce posting limits differently for API tokens versus browser sessions?

API limits are enforced at the OAuth token layer: the server tracks writes per token and returns HTTP 429 with a reset header when the quota is exceeded. Account-level limits are enforced at the session layer and apply to all posting methods. Browser sessions and automation tools using session cookies face account-level caps, burst sub-window enforcement, and IP-reputation throttling. None of those three mechanisms produces a reliable HTTP error code.

What replaced the X API free tier after it was discontinued in February 2026?

X replaced the free tier with a mandatory pay-per-use model for new developers, with no free allowance. Plain text and media posts cost $0.015 per post; posts containing a URL cost $0.20 per post. Developers must pre-load credits before their app can make write calls. Legacy Basic plan subscribers on a $200 per month flat rate were migrated to pay-per-use billing after June 1, 2026.

Does your home IP address affect how many posts X allows per day?

Yes, in practice. A home residential IP with no prior flag history supports higher effective posting volume through browser sessions than a datacenter IP, shared proxy, or VPN exit node. Accounts posting through non-residential or previously flagged IPs encounter CAPTCHA challenges and informal rate warnings well below the documented 50-post daily cap, sometimes as early as post 8 to 10 per day. This enforcement is undocumented and produces no consistent HTTP error code.

How does the X 30-minute burst posting limit interact with the daily post cap?

They are independent enforcement layers. The daily cap limits total posts per 24-hour period; the 30-minute burst sub-window limits how quickly those posts can be made. An account that posts 10 tweets in 8 minutes can trigger the burst window block before approaching the daily cap at all. The block typically lasts 15 to 30 minutes and surfaces silently in browser sessions. Spacing posts 3 to 5 minutes apart avoids triggering it.

Do X Premium or verified accounts get higher daily posting limits than free accounts?

For account-level posting through the web interface, Premium accounts are described as having no practical limits for normal use, while free unverified accounts are capped at approximately 50 original posts per day. Both tiers are subject to the same 30-minute burst sub-window. For API access, the developer plan tier sets the write quota; account verification status does not directly change API rate limits.

Sources and further reading

• X API rate limits documentation
• X account limits policy
• X developer community: free tier endpoint removal announcement