X API tiers in 2026: what automation survives

X closed flat-rate API tiers to new signups on February 6, 2026, removed follow and like endpoints from all self-serve plans on April 16, 2026, and began auto-migrating remaining Basic subscribers to pay-per-use billing on June 1, 2026. The automation that a $200-per-month plan covered in 2025 either costs dramatically more today or requires a $42,000-per-month Enterprise contract. What most tools and guides miss is that the billing change and the endpoint removal are separate problems. Paying more credits does not restore access to removed endpoints, and staying within API rate limits does not protect an account from X's behavioral enforcement layer, which operates independently of the API itself.

What X API automation is still allowed without an Enterprise plan?

Self-serve access now covers four operations: creating posts, reading posts and timelines, replying inside a narrow permitted window, and sending direct messages to people who have consented to receive them. That is the entire list. If you are auditing an existing integration, the fastest useful exercise is to pull your endpoint call log and sort by volume. Every follow, like, and quote-post write in that log is either an Enterprise line item or dead code, and it has been since April 16, 2026.

Post creation through POST /2/tweets is billed by what the post contains rather than by the call itself. A text or media post costs $0.015. A post containing a URL costs $0.20. That distinction sounds like an accounting detail until you try to quote a customer a monthly price. We had to add a link-detection pass to our own publishing queue before we could forecast a bill at all, because the same scheduled post costs two very different amounts depending on whether someone pasted a link into it.

Reads are priced at $0.005 per post read, with a hard ceiling of 2,000,000 post reads per month before an Enterprise contract becomes mandatory. A 24-hour deduplication window applies, so reading the same resource twice inside 24 hours is charged once. The practical consequence runs against intuition: polling frequency is not what drives read spend, breadth is. A loop that re-checks the same 500-post working set every few minutes bills far less than a job that sweeps a wide set of new authors once a day.

Automated replies are permitted only in what X calls a summoned context. The author of the original post must have @mentioned or quoted your account in that specific post. This has been the rule since February 23, 2026. A reply bot wired to the mentions endpoint is compliant by construction. A reply bot wired to a keyword search or a topic stream is a policy violation on every self-serve tier, no matter how relevant the reply is or how carefully it is written.

DM automation exists at paid tiers and is capped at 15 sends per 15 minutes per user context and approximately 1,440 per 24 hours per account. Treat those as ceilings, not targets. Bulk cold-outreach DMs are prohibited at all tiers regardless of volume, so a tool that stays under 1,440 sends a day while messaging strangers is violating policy the whole time. The cap constrains a permitted use case; it does not authorize an impermissible one.

Two access paths that developers still ask us about are gone. There is no free tier for new developers as of February 2026; existing free-tier users received a one-time $10 credit and were migrated to pay-per-use. The Academic Research tier, which previously gave approved researchers free Pro-equivalent access, was eliminated, and as of 2026 limited free access is handled manually on a case-by-case basis. Both changes have the same downstream effect on engineering practice: prototyping bills, and so does your CI suite if it hits the live API.

X API pay-per-use pricing costs more than the numbers suggest for link-heavy workflows

Every pricing summary leads with $0.015 per post. The number that decides your bill is $0.20, applied to any post containing a URL and added in April 2026. That is 13 times more expensive per post. Most social automation tools are link distribution tools wearing a content calendar as a costume, which means the headline rate applies to a minority of what they publish and the expensive rate applies to the rest.

Here is the arithmetic on a workload we see constantly. A tool posting 100 curated articles per day accumulates $20 per day in write credits, which is $600 per month before a single read operation is counted. That is roughly 3x the old Basic tier price for a fraction of the volume Basic covered at a flat rate. Nothing about that workflow is aggressive. One hundred posts a day is a modest content operation, and it now costs more than the plan that used to cover far heavier usage.

The break-even points against the old $200-per-month Basic tier are worth writing on a whiteboard: roughly 13,000 text-only posts per month, or under 1,000 posts per month if those posts contain URLs. A single blended average cost per post is the most common modeling error we see, and it is not a small one. Teams take a mixed workflow, divide total spend by total posts, get a comfortable-looking number, and then watch the bill diverge the moment their link share drifts up by ten points. Model text posts and link posts as two separate cost lines, always.

Volume discounts arrive as cashback rather than as a lower rate: 10% back at $200 or more in monthly spend, 15% at $500 or more, and 20% at $1,000 or more. Separately, $1,000 or more in cumulative API credit spend earns up to 20% back in xAI API credits. Both are rebates, and xAI credits in particular only reduce cost if you already had a reason to spend on xAI. When you forecast a customer's monthly invoice, forecast the gross number. The cashback is a recovery, not a discount you can quote.

Throughput does not move with spend. POST /2/tweets stays capped at 10,000 posts per 24 hours per app and 100 posts per 15 minutes per user at every price level. Buying more credits buys the right to be billed for more events, not the right to fire them faster. The failure mode has a shape: a team hits a publishing backlog after an outage, assumes topping up credits will let them drain the queue, and instead spends the afternoon collecting 429s at exactly the same rate they would have on an empty balance.

If you sell a product on top of this API, the pricing model that survives contact with reality prices per post type and alerts on link-share drift. We monitor the link ratio in our own queue the way you would monitor error rate, because it is the single input that moves the bill. Everything else about pay-per-use is predictable. That one variable is not, because it is set by whatever your users decide to publish this week.

Follow, like, and quote-post endpoints are gone from all self-serve API tiers

On April 16, 2026, X removed the follow, like, and quote-post write endpoints from every self-serve API tier. Those actions are now reachable through the official API only under an Enterprise contract, which starts at approximately $42,000 per month and is quoted in the $42,000 to $50,000-plus range on an annual commitment. There is no partial path. No amount of pay-per-use spend, no legacy grandfathering, and no combination of scopes produces a working like call on a self-serve app.

Enterprise is also where the research capabilities live. It is the only tier that includes full-archive search back to March 2006, full firehose streaming, and filtered streams. That bundling matters for how you plan: the same contract gates a growth tool's like button and an analyst's historical corpus, which means two organizations with nothing in common are now negotiating for the same SKU at the same price floor.

The debugging trap here has cost engineering teams real weeks. OAuth user-context tokens, both OAuth 1.0a and OAuth 2.0 PKCE, remain valid. They authenticate fine. They work for posting. Then a POST to the follow or like endpoint returns 401 or 403, and the natural conclusion is that something is wrong with the token exchange. Teams regenerate credentials, rebuild the PKCE flow, migrate between OAuth versions, and add scopes that the consent screen no longer offers. The auth is not broken; the endpoint permission was revoked.

The distinction to internalize is that this is an endpoint access change, not a billing change. Retrying does not help, because the response is not transient. Adding credits does not help, because the restriction sits at the permission layer and billing sits somewhere else entirely. If your error handling treats 403 on a write endpoint as a backoff-and-retry case, you will generate a burst of failed calls at machine speed, which is exactly the velocity pattern discussed later in this guide.

The correct engineering response is unglamorous. Delete the call sites, remove the feature from your product surface, and tell your users plainly that the capability was withdrawn by the platform rather than deprecated by you. We took that path with automated engagement on X, and the conversation with customers was easier than expected once we could point at a dated changelog entry. What does not work is leaving the button in the UI and letting it fail quietly, which converts a platform decision into a reliability complaint about your product.

When Basic tier auto-migration hits, link-post automation costs reset completely

X began auto-migrating remaining legacy Basic subscribers, at $200 per month flat, onto pay-per-use billing on June 1, 2026. If you have been running a stable integration on Basic since 2025 and your finance team has a fixed line item for it, that line item is now a variable one. Basic and Pro both closed to new signups on February 6, 2026. The legacy Pro tier at $5,000 per month is still active for grandfathered accounts, but it cannot be purchased, so it is not an escape hatch for anyone who does not already hold it.

For text-heavy workloads the migration is survivable. The break-even against $200 per month sits at roughly 13,000 text-only posts per month, which is more volume than most tools publish. For link-heavy workloads the same migration is a step function. That break-even collapses to under 1,000 posts per month once those posts contain URLs, and the earlier example holds: 100 curated articles a day lands at $600 per month in write credits, roughly 3x what the flat plan cost for a workload the flat plan handled without comment.

The mitigation people reach for first does not work. Publishing a text post and putting the link in a follow-up reply does not dodge the $0.20 charge, because a reply is a post and a post containing a URL is billed as a post containing a URL. It also drags you toward the reply rules, since a self-published thread is fine but any automated reply to someone else's post outside a summoned context is a violation. Restructuring where the link sits changes nothing about the bill.

Cashback softens the landing without changing the shape of it. At $1,000 or more in monthly spend you get 20% back, and cumulative spend past $1,000 earns up to 20% back in xAI API credits. Applied to a link-heavy workflow that has ballooned past the old flat rate, that is a meaningful recovery on a number that is still multiples of what you were paying. Nobody migrating from Basic should model cashback as closing the gap, because it does not.

What we tell teams facing the migration is to measure before they redesign. Log link share and post volume separately for a full billing cycle, then compute two cost lines rather than one. Most teams discover their link ratio is higher than they assumed, because reshares of company blog posts, product announcements, and event registrations all carry URLs and all get scheduled by different people. The number you need before any architecture decision is not total posts per month. It is how many of those posts have a link in them.

What practitioners get wrong about X API rate limits and account suspensions

A 429 and a suspension are two different enforcement systems, and conflating them produces bad engineering decisions in both directions. A 429 means you hit a throughput cap. The window resets, commonly after 15 minutes, and the account carries no penalty. It is a queueing problem. A suspension comes from X's trust-and-safety layer, which runs independently of the API and watches behavioral signals: action velocity, timing regularity, IP reputation, account age, and follower-to-following ratios. It does not consult your rate-limit budget before deciding.

The consequence that surprises people is that an account can sit comfortably inside every published limit and still get flagged. We have watched integrations that never once touched 100 posts per 15 minutes per user or 10,000 posts per 24 hours per app draw enforcement anyway, because the timing pattern read as machine-generated. Posts fired at exact five-minute marks are the classic signature. The volume is unremarkable; the regularity is not. Human publishing has variance in it, and a scheduler that respects the clock more faithfully than any person would is producing a fingerprint, not a schedule.

The fix is jitter, applied properly. Distribute actions across a window rather than pinning them to fixed intervals, and make the distribution wide enough that consecutive gaps do not cluster around a single value. A common half-measure is adding a few seconds of randomness to a fixed cadence, which preserves the underlying periodicity and reads the same way under analysis. If you plot your own send times for a week and the histogram has a spike in it, so does the one on the other side.

A second failure mode lives in error handling. When a connected user's OAuth token expires or is revoked, most often because they changed their X password or removed app access from their account settings, the API returns 401. In a high-throughput log, a burst of 401s and a burst of 429s look nearly identical: same shape, same timing, same alert. Retry logic that cannot tell them apart treats a permanent failure as a transient one, burns credits on calls that can never succeed, and generates precisely the velocity signal the enforcement layer is watching for.

Handle them separately at the code level. A 429 is a backoff. A 401 on a user-context call is a re-authentication event that should immediately surface to the connected user and pause that account's queue, not enter a retry loop. We split those paths after seeing how fast a few hundred revoked tokens can turn a healthy job into a retry storm. The credits wasted are annoying. The behavioral signature the storm creates is the part that actually costs you an account.

Both systems deserve their own dashboards. Rate-limit health is a capacity metric and belongs next to your queue depth. Enforcement risk is a behavioral metric and belongs next to your timing distribution, your per-account action velocity, and the age of the accounts you are acting on behalf of. Teams that maintain only the first dashboard get blindsided, because the number they are watching stays green right up until the account they were watching it for stops existing.

The 'summoned' reply rule: automated replies on self-serve tiers after February 23, 2026

Since February 23, 2026, automated replies through POST /2/tweets are permitted on self-serve tiers only when the original post's author has summoned the replying account, meaning that account was @mentioned or quoted in that post. Unsolicited automated replies are prohibited outright. The rule sounds narrow until you map it onto real reply tooling, at which point it disqualifies most of what the category was built to do.

The edge cases are where teams get it wrong, and they are not obvious from the policy text. Being mentioned somewhere in a thread does not authorize replying to every post in that thread. The mention has to be in the specific post you are replying to. A quote-reply to a post that did not tag your account falls outside the summoned definition. So does a reply to a post that merely matches your brand keyword, no matter how clearly the author was talking about you. Mention-monitoring webhooks are compliant by construction; keyword and topic stream replies are violations.

That single distinction is the cleanest architectural test we know for reply automation on X. If your tool subscribes to the mentions endpoint and its reply set is a strict subset of posts that named your account, it is inside the rule. If any part of the pipeline discovers targets through search, trend monitoring, or a follower's timeline, it is outside the rule, and refining the relevance model does not move it back inside. The constraint is on how the target was discovered, not on how good the reply is.

The reply rule sits inside a broader set of prohibitions in the X Developer Policy that apply at every tier. Bulk following is prohibited. Cross-account content duplication is prohibited, which matters for any tool that syndicates one message across a client's whole roster of accounts. Automated replies or DMs without explicit user consent are prohibited. So is selling or receiving compensation for follows, likes, posts, retweets, or replies, which puts engagement-pod tooling and paid amplification services outside policy independent of how they are technically implemented.

DM automation follows the same consent logic as replies. The approximately 1,440 sends per 24 hours per account cap describes throughput for a permitted use case, and it does not authorize cold outreach. Bulk automated DMs to people who have not messaged your account first are prohibited at all tiers, including Enterprise. We get asked whether the cap can be read as an allowance, and the honest answer is that a policy prohibition and a rate limit are independent constraints. Passing one does not satisfy the other.

For product teams, the useful reframe is that consent is now a data model requirement rather than a compliance checkbox. You need to store, per target, why you are permitted to contact them: the mention that summoned the reply, or the inbound DM that opened the conversation. If your schema cannot answer that question for a given outbound action, the action should not fire. Building that record after the fact is possible; building it before is considerably cheaper than an account review.

Treat browser automation and official API violations as the same suspension risk

The obvious reaction to losing follow and like endpoints is to route those actions through a real browser. The X Developer Policy closes that door explicitly: screen scraping, browser automation bots, and unofficial API clients are prohibited regardless of API tier or spend level, and violations can result in permanent account suspension. Driving Playwright, Puppeteer, or Selenium against a logged-in session does not work around the April 2026 endpoint removal. It adds a second, separate policy violation on top of the first.

The deeper reason it fails is architectural. X's enforcement operates at the account behavior layer, not the API auth layer. Session fingerprinting, interaction timing, scroll patterns, and mouse-movement entropy get analyzed whether the action arrived as an API call or as a click in a headless Chromium instance. Changing the transport changes which signals are available for analysis. It does not remove the account from analysis.

In practice, browser automation for high-volume engagement tends to be worse than the API path it replaced. Accounts running real-browser automation for follows and likes show suspension patterns similar to API policy violators, and often reach them faster, because a browser session carries far richer behavioral signal than a bare HTTP request does. An API call exposes a timestamp and an action. A browser session exposes timing between every interaction, how the page was scrolled, where the cursor went, and how that entropy compares to a human doing the same thing.

Residential IPs are the other half of this belief and they do not help either. The reasoning behind them assumes detection is network-topology-based, so a clean consumer IP launders the traffic. Detection is behavioral. A residential address attached to an account performing follows at a cadence no person sustains produces a flagged account with a residential IP, and the IP reputation signal then follows that address into whatever else is running behind it. Proxy budgets spent on this problem are, in our experience, budget spent on the wrong layer.

The honest conclusion, from a company that sells automation, is that certain product features no longer exist on X for anyone below an Enterprise contract. Automated follow and like campaigns are in that category. You can build them, they will work in a demo, and they will produce suspended customer accounts on a timeline measured in weeks. The question worth asking is not which tool evades detection. It is whether the feature is worth the account you are risking, and for engagement actions, it is not.

How user-context OAuth limits and app-level X API limits interact for multi-account tools

POST /2/tweets is governed by two rate limits that live in different scopes. There is a per-user limit of 100 posts per 15 minutes, applied to each connected account through its OAuth user-context token, and a per-app limit of 10,000 posts per 24 hours, applied across every account using your app. Single-account developers only ever meet the first one. Anyone building a multi-tenant tool meets the second one first, and the arithmetic is unforgiving: the app-level ceiling is a shared pool that your entire customer base draws from simultaneously.

That produces a capacity planning problem most API documentation never frames for you. With a few hundred connected accounts, the 10,000-post daily app cap can be exhausted while no individual user is anywhere near 100 posts per 15 minutes. Your largest customer's scheduled campaign becomes everyone else's outage. Read endpoints have their own app-level scope to plan around as well: the recent search endpoint allows 450 requests per 15 minutes per app on a Bearer Token, which is a genuinely tight budget once monitoring, analytics, and mention polling all share it.

The mitigation is a fair-share scheduler rather than a first-come queue. Allocate the daily app budget across tenants, reserve headroom for time-sensitive sends, and make the allocation visible to your own support team so that a throttled customer gets an explanation instead of a mystery. The app-level cap is a product constraint, not an infrastructure detail, and it should show up in your pricing tiers before it shows up in an incident channel.

Token lifecycle is the other thing that breaks at multi-account volume. When a user revokes access or changes their X password, calls on their behalf return 401 rather than 429, and in aggregate logs the two are easy to confuse. Tools that retry 401s as transient rate-limit errors burn credits on calls that cannot succeed and manufacture velocity signals while doing it. The correct pattern is to mark the connection as needing re-authentication, stop its queue, and surface the reconnect prompt to that user immediately. Storage should hold refresh state per connection, not per app, and expiry should be treated as an expected lifecycle event rather than an error condition.

Enforcement also correlates across accounts, which is the part multi-account architectures rarely account for. Activity from many accounts sharing one app ID and originating from the same IP range is analyzed together, so a fleet moving in unison looks like a fleet. Similar timing patterns across tenants compound the effect. High-volume tools should rotate or separate egress IPs and stagger per-tenant schedules so that two customers who happened to pick the same posting window are not publishing at identical timestamps through the same address.

One policy constraint belongs in this section rather than the compliance one, because it is an architecture decision. Cross-account content duplication is prohibited by the X Developer Policy. If your product offers a single composer that fans one message out across a client's roster of accounts, that is the prohibited pattern, whatever the UI calls it. Building the fan-out is easy and the failure arrives all at once, correlated across every account in the roster, which is the worst possible shape for a suspension event to take.

Frequently asked questions

What X API automation is still allowed without an Enterprise plan in 2026?

Pay-per-use access allows posting text and media, reading posts and timelines, sending DMs within the daily 1,440-per-account cap, and automated replies only when your account was @mentioned in the original post. Follow, like, and quote-post endpoints were removed from all self-serve tiers on April 16, 2026 and require an Enterprise contract to access.

Can I automate follows and likes with the X API pay-per-use tier?

No. X removed follow and like endpoints from all self-serve API tiers on April 16, 2026. These actions now require an Enterprise contract starting at approximately $42,000 per month. Increasing pay-per-use credit spend does not restore access to these endpoints; the restriction is at the permission level, not the billing level.

What happened to X API Basic and Pro tiers in 2026?

X closed the flat-rate Basic ($200 per month) and Pro ($5,000 per month) tiers to new signups on February 6, 2026, making pay-per-use the default for all new developers. Existing Basic subscribers are being auto-migrated to pay-per-use since June 1, 2026. Grandfathered Pro accounts remain active but the tier cannot be newly purchased.

How much does it cost to post 500 tweets per day with X API pay-per-use pricing?

It depends on post type. Text-only posts cost $0.015 each: 500 per day is approximately $225 per month. Posts containing URLs cost $0.20 each: 500 per day totals around $3,000 per month in write credits alone, before any post reads are counted. Mixed workflows require separate cost calculations for each post type.

What is the difference between X API pay-per-use rate limits and Enterprise rate limits for automation?

Pay-per-use applies a 10,000-post-per-24-hour app cap, a 100-posts-per-15-minute user cap, and a 2,000,000-post-reads-per-month ceiling. Enterprise removes the reads ceiling, adds full-archive search and firehose streaming, and restores follow, like, and quote-post endpoints. Neither tier permits bulk unsolicited DMs or automated replies outside summoned contexts.

Is browser automation like Playwright or Puppeteer allowed as an X API alternative for follow and like actions?

No. X's Developer Policy explicitly prohibits browser automation, screen scraping, and unofficial API clients at all tiers. Using Playwright or Puppeteer to automate engagement actions is a separate policy violation, not a workaround for removed endpoints. X's enforcement detects behavioral patterns at the account layer, so browser-automated accounts show similar suspension rates to API policy violators.

How do X API user-context OAuth rate limits differ from app-only Bearer Token limits?

User-context (OAuth 1.0a or OAuth 2.0 PKCE) limits apply per connected account: 100 posts per 15 minutes per user. App-only Bearer Token limits apply across all accounts using a single app: 10,000 posts per 24 hours total. For multi-account tools, the app-level ceiling is usually the binding constraint before any individual user approaches their per-user limit.

What triggers an X account suspension for API automation versus a 429 rate limit error?

A 429 is a throughput cap response; it resets after the rate window with no account penalty. Suspensions come from X's behavioral enforcement layer, which analyzes action velocity, timing regularity, IP reputation, and session patterns independently of the API. An account can post well within published limits and still be suspended if its timing pattern looks machine-generated or its associated IP is flagged.

Is there any way to automate replies on X without an Enterprise API plan?

Yes, within a strict constraint. Automated replies are permitted only when your account was @mentioned or quoted in the specific post you are replying to. This 'summoned' rule has been in effect since February 23, 2026. Tools that monitor the mentions endpoint and reply to incoming @mentions are compliant. Tools that reply to keyword searches or topic streams are violations on self-serve tiers.

Sources and further reading

• X Developer Policy: automation rules and prohibited actions
• X API pricing and access tiers (official documentation)
• X API changelog: April 2026 endpoint restrictions