X (Twitter) · Rate Limits
Twitter Rate Limits
X API v2 enforces rate limits on top of its pay-per-call pricing. Limits are scoped per endpoint with per-app (Bearer) and per-user (OAuth) buckets, typically over 15-minute or 24-hour windows. Headers expose the live limit, remaining, and reset timestamp. When a limit is exceeded, the API returns HTTP 429 with error code 88 ("Rate limit exceeded"); recovery is via the reset timestamp and exponential backoff.
13 Limits
Throttle: 429
Social MediaDeveloper APIRate Limiting
Limits
Tweet lookup (app) app (Bearer token)
3500
15-minute window.
Tweet lookup (user) user (OAuth)
5000
15-minute window.
Recent search (app) app (Bearer token)
450
15-minute window.
Recent search (user) user (OAuth)
300
15-minute window.
Post creation (app) app (Bearer token)
10000
24-hour window.
Post creation (user) user (OAuth)
100
15-minute window.
User lookup (app) app (Bearer token)
300
15-minute window.
User lookup (user) user (OAuth)
900
15-minute window.
Follow management (user) user (OAuth)
50
User-only; not available with app tokens.
Direct Messages - retrieval (user) user (OAuth)
15
User-only.
Direct Messages - creation app/user
1440
24-hour window; available on both app and user contexts.
Media upload init (app) app (Bearer token)
180000
24-hour window.
Media upload init (user) user (OAuth)
1875
15-minute window.
Policies
15-Minute / 24-Hour Windows
Most endpoints reset on 15-minute windows; high-volume actions (post creation, DM creation, media upload init) use 24-hour windows. Use x-rate-limit-reset to determine wait time.
App vs User Buckets
Each endpoint has separate per-app (Bearer) and per-user (OAuth) buckets; choose the auth context that fits your traffic shape and treat them as independent budgets.
Error Code 88 Recovery
A 429 response carries error code 88 ("Rate limit exceeded"); recover by waiting until x-rate-limit-reset and applying exponential backoff before retrying.
Streaming for Real-Time
For high-volume real-time use cases, prefer streaming endpoints over polling to stay within the 15-minute / 24-hour windows.
Caching and Distribution
Cache responses, monitor remaining, and distribute requests across the time window to avoid bursting against the limit.