X API 429: Too Many Requests
How to read a 429 response from the X API, including the rate-limit headers that tell you when it's safe to retry.
By André LugA 429 from the X API comes from one of two independent throttles: a rate limit — a per-window request ceiling that resets automatically (POST /2/tweets: 100 per 15 minutes per user, 10,000 per 24 hours per app) — or a billing cap under the 2026 pay-per-use pricing, which needs a plan change, not a wait. The x-rate-limit-reset header tells them apart.
A 429 from the X API is not one uniform thing — X runs two independent throttles on the same platform, and a 429 can come from either. One is a classic rate limit: a request-count ceiling per rolling time window, reset automatically. The other is a billing cap tied to the 2026 pay-per-use pricing model, which needs a plan or payment change to lift, not a wait. Per docs.x.com/x-api/fundamentals/rate-limits, checked August 25, 2026, every response carries the headers you need to tell them apart before you decide how to react.
PostGate handles OAuth, publishing and delivery evidence for every network through one API. Start free or read the docs.
Which rate-limit headers should you read before retrying?
Every X API response includes:
x-rate-limit-limit— the ceiling for the current window.x-rate-limit-remaining— how many requests are left before the next 429.x-rate-limit-reset— a Unix timestamp for exactly when the window resets.
A well-behaved client checks x-rate-limit-remaining proactively and slows down before it hits zero, rather than waiting for the 429 to happen and reacting after the fact.
Two window lengths, and two independent counters per window
Most endpoints reset every 15 minutes; a handful of write endpoints, including POST /2/tweets, also carry a separate 24-hour ceiling stacked on top of the 15-minute one — hitting either returns 429. Within each window, limits authenticated with an app-only bearer token and limits authenticated with a specific user's OAuth token are tracked as separate counters. One user hitting their personal posting cap doesn't throttle any other user of the same app; the app-level counter is a shared ceiling that sits above all of them individually, not a sum of them.
Which numbers matter for posting?
For POST /2/tweets: 100 requests per 15 minutes per user, 10,000 per 24 hours per app. For GET /2/tweets: 5,000 per 15 minutes per user, 3,500 per 15 minutes per app. A five-post thread consumes five units of the 100-per-15-minute posting cap in one go — see X Thread API for why threads burn through it faster than a single post would suggest.
When is a 429 actually the billing cap, not the rate limit?
Independent of the header-reported rate limit, pay-per-use accounts are capped at 3 million post reads per monthly billing cycle before X requires an Enterprise arrangement for more volume. Grandfathered Basic and Pro subscribers instead have fixed monthly write/read allowances baked into their plan. A billing-cap rejection will not carry a near-future x-rate-limit-reset the way a window throttle does — if the reset timestamp is far out or the response otherwise doesn't look like a normal window reset, check X API Pricing Tiers before assuming a short wait will fix it.
How do you back off correctly?
Treat a 429 as an expected, normal response for a high-volume publisher, not an error state to escalate. Back off using the timestamp in x-rate-limit-reset, not a fixed delay — waiting a hardcoded 60 seconds either wastes time inside a window that already reset, or retries early into one that hasn't. PostGate's Posts API already reads these headers, retries with backoff, and reports per-target delivery state independently of X's own limits, so a throttled X target doesn't block delivery to your other connected platforms in the same request.
curl https://postgate.studio/api/posts/post_01JXYZ \
-H "Authorization: Bearer $POSTGATE_API_KEY"Frequently asked questions
How long should I wait after an X API 429?
Wait until the Unix timestamp in the x-rate-limit-reset header, not a fixed delay — a hardcoded 60 seconds either wastes time inside a window that already reset, or retries early into one that hasn’t. Most endpoints reset every 15 minutes, but some write endpoints, including POST /2/tweets, also carry a separate 24-hour ceiling stacked on top.
What are the X API rate limits for posting?
For POST /2/tweets: 100 requests per 15 minutes per user, and 10,000 per 24 hours per app. For GET /2/tweets: 5,000 per 15 minutes per user and 3,500 per 15 minutes per app. Note that a five-post thread consumes five units of the 100-per-15-minute posting cap in one go, so threads burn through it faster than single posts suggest.
Does one user hitting their X rate limit throttle my other users?
No. Within each window, limits authenticated with an app-only bearer token and limits authenticated with a specific user’s OAuth token are tracked as separate counters. One user hitting their personal posting cap doesn’t throttle any other user of the same app; the app-level counter is a shared ceiling that sits above all of them individually, not a sum of them.
How do I tell a rate-limit 429 from a billing-cap 429 on the X API?
A window throttle carries a near-future x-rate-limit-reset timestamp; a billing-cap rejection does not. Pay-per-use accounts are capped at 3 million post reads per monthly billing cycle before X requires an Enterprise arrangement, while grandfathered Basic and Pro subscribers have fixed monthly allowances. If the reset timestamp is far out, check your pricing tier before assuming a short wait will fix it.
Should I treat an X API 429 as an error?
No — for a high-volume publisher it is an expected, normal response, not an error state to escalate. Check x-rate-limit-remaining proactively and slow down before it hits zero rather than reacting after the fact. PostGate’s Posts API already reads these headers, retries with backoff, and reports per-target delivery state, so a throttled X target doesn’t block delivery to your other platforms.
