Rate limits
Published per-tier limits for reads and writes, the response headers that report them, and how to back off.
Limits are enforced per credential, per acting user, and per app — and they are published here, from the same constants the enforcement reads, so the documented number is the enforced number.
Not yet live
These are the launch limits. Until the API is callable they are a specification, and the changelog will note any change before launch.
Tiers
Every OAuth app has a rate tier: restricted (new anonymous/DCR apps),
standard (default for portal apps), elevated, or partner (granted on
request). Personal access tokens have their own per-token limits.
Per credential, per acting user (requests per minute unless noted):
| Dimension | restricted | standard | elevated | partner | PAT (per token) |
|---|---|---|---|---|---|
| Reads / min | 30 | 60 | 300 | 900 | 300 |
| Writes / min | 5 | 10 | 30 | 60 | 30 |
| Writes / 24 h | 50 | 200 | 1,000 | custom | 1,000 |
Per app, across all its users (aggregate):
| Dimension | restricted | standard | elevated | partner |
|---|---|---|---|---|
| Reads / min | 300 | 600 | 6,000 | 30,000 |
| Writes / min | 30 | 60 | 600 | 6,000 |
Two global backstops, independent of tier:
- Per user, across all credentials: 60 writes/min and 500 writes/day. Many connected apps do not multiply one account's posting throughput.
- Unauthenticated requests (discovery documents, the OpenAPI spec, health): 60/min per IP.
Denied requests still count against the window — a tight retry loop digs the hole deeper. Back off instead.
Headers
Every /public/v1 response reports the per-credential state:
RateLimit-Limit: 60
RateLimit-Remaining: 41
RateLimit-Reset: 23
RateLimit-Policy: 60;w=60On 429 you additionally get Retry-After (seconds) and a
problem document whose code tells you which limit you hit:
RATE_LIMITED— a per-minute window; waitRetry-Afterseconds.USAGE_LIMIT_EXCEEDED— a daily write cap; stop until the day rolls over.MEDIA_QUOTA_EXCEEDED— the rolling media quota (500 assets / 250 MB per user per 24 h).
Client guidance
- Honor
Retry-Afterexactly; add jitter to any retry loop. - Spread scheduled work (e.g. queued posts) rather than bursting at the top of the hour.
- If your app legitimately needs more than
standard, requestelevatedfrom the developer portal — with your use case and observed usage.