X’s developer platform now prices the API per request rather than through a subscription tier. Post creation is charged per call, and POST /2/tweets is limited to 100 requests per user per 15 minutes and 10,000 per app per 24 hours. If you are deciding whether to build directly against it, those two facts set most of your architecture.
What does the X API actually cost?
The official pricing page describes a credit model, not named plans. You buy credits, set a spending limit, and each call deducts from the balance.
| Operation | Price stated |
|---|---|
| Post creation | $0.015 per request |
| Post containing a URL | $0.200 per request |
| Post (summoned) | $0.010 per request |
| DM and user interactions | $0.015 per request |
| Delete interactions | $0.010 per request |
| Read: posts | $0.005 per resource |
| Read: users, DMs, following/followers | $0.010 per resource |
| Read: likes, mutes, blocks | $0.001 per resource |
| Owned reads (your own data) | $0.001 per resource |
Two details matter more than the unit prices. A post containing a URL costs more than 13x a plain post, which is a meaningful line item if you publish links for a living. And pay-per-usage plans are capped at 3 million post reads per monthly billing cycle, so read-heavy products hit a ceiling that no amount of credit purchasing removes.
Resources are deduplicated within a 24-hour UTC window, so requesting the same resource twice in a day is charged once.
Note: Figures here were verified against docs.x.com/x-api/getting-started/pricing as of September 2026. Platforms change these without notice.
What we could not verify. Older Free, Basic and Pro tiers with monthly post caps are widely quoted around the web. We could not load an official page listing them: the current pricing and introduction pages describe pay-per-usage with no named tiers, and the tier URL returns 404. We are not restating third-party numbers. Check the Developer Console for the rates that apply to your account.
What can the X API publish, and what can it not?
POST /2/tweets takes text, optional media.media_ids, reply, poll, geo, reply_settings and a few flags such as made_with_ai and paid_partnership.
Media is not part of that call. You upload separately through the chunked upload endpoints and pass the resulting media_id. One post accepts up to 4 photos, 1 animated GIF, or 1 video.
The gaps worth naming before you commit:
quote_tweet_idis Enterprise only. Quote posting is not available on the general endpoint.- Video ceilings depend on the posting account, not your app. Standard accounts are capped at 20 minutes and 8 GB; X Premium and verified accounts at 125 minutes and 16 GB. Your uploader has to handle both because the limit belongs to the user you are posting on behalf of.
- Polls are constrained. 2 to 4 options, duration between 5 and 10,080 minutes.
- The creation reference does not state a character limit. We could not verify one from that page. See the X character limit post for what the product enforces.
Note: Figures here were verified against docs.x.com/x-api/posts/creation-of-a-post as of September 2026. Platforms change these without notice.
What is the auth model in plain terms?
Two modes, and posting only works in one of them.
App-only bearer token. A single credential representing your application. It reads public data. It cannot post, because there is no user to post as.
OAuth 2.0 Authorization Code with PKCE, user context. The user is sent to X’s authorization dialog, comes back with a code, and you exchange it for an access token. Posting requires the tweet.write scope, alongside tweet.read and users.read. If you want to keep posting after the access token expires, you must request offline.access at authorization time, which is what causes a refresh token to be issued.
That last point is the one that bites people. offline.access is opt-in per authorization. Omit it and every user has to reauthorize interactively, which is fatal for a scheduler that publishes at 3am. The docs do not state the access token lifetime, so treat it as short and refresh proactively.
What are the rate limits on posting?
| Endpoint | Per user | Per app |
|---|---|---|
POST /2/tweets | 100 per 15 minutes | 10,000 per 24 hours |
Every response carries x-rate-limit-limit, x-rate-limit-remaining and x-rate-limit-reset (a Unix timestamp). Read them rather than counting your own calls, because your counter and X’s will drift the moment a retry happens.
The documentation is explicit that rate limits and billing are separate concerns. Staying under the rate limit does not cap your spend, and setting a spending limit does not stop you getting 429s. You need both controls.
Note: Figures here were verified against docs.x.com/x-api/fundamentals/rate-limits as of September 2026. Platforms change these without notice.
What will actually cost you three weeks?
Not the publish call. The publish call is an afternoon.
Token refresh. Getting offline.access requested, refresh tokens stored encrypted, rotation handled, and a reconnect path for users whose refresh fails. This is a background job with its own failure modes, not a function.
Chunked media upload. INIT, APPEND, FINALIZE, then poll for processing status before the media id is usable in a post. Videos fail transcoding, and they fail after your upload returned 200.
Per-account video ceilings. 20 minutes versus 125 minutes is a runtime branch based on whose account you are posting to, and you cannot know it from your app credentials alone.
Cost accounting. A per-request price means someone has to attribute spend to customers, or you will discover the URL surcharge from an invoice.
429 handling that is not a sleep. The per-user window is 15 minutes. A naive retry loop turns one rate-limited post into a stalled worker.
The short version
- Pricing is pay-per-usage credits. Post creation is $0.015 per request; a post with a URL is $0.200.
- Reads on pay-per-usage are capped at 3 million posts per monthly billing cycle.
POST /2/tweetsallows 100 per user per 15 minutes, 10,000 per app per 24 hours.- Posting requires OAuth 2.0 PKCE user context with
tweet.write, plusoffline.accessif you want refresh tokens. - Media uploads separately: 4 photos, 1 GIF, or 1 video. Quote posting is Enterprise only.
- Named Free/Basic/Pro tiers could not be verified against an official page in September 2026.
Doing this once instead of once per platform
The work above is real, and it is X-shaped. LinkedIn needs two separate apps with different scopes. TikTok requires passing a Content Posting API audit. Threads uses a container-then-publish sequence with a 60-day token refresh cycle. None of it transfers.
BulkPublish exposes one REST API across 15 platforms: Facebook, Instagram, TikTok, YouTube, X, Bluesky, Threads, Pinterest, LinkedIn, Google Business Profile, Mastodon, Discord, Telegram, Tumblr and Snapchat. One auth model, one media pipeline, one post object, and the per-platform token refresh and async status polling handled behind it. The developer docs and the REST API reference cover the endpoints.