Developers
Rate limits
One token bucket per API key. Limits exist to protect everyone's social-channel quotas, not just our backend.
v1 limits
| Limit | Free | Solo | Agency |
|---|---|---|---|
| Steady state | 5 requests / minute | 30 requests / minute | 30 requests / minute |
| Burst | 5 requests | 30 requests | 30 requests |
| Scope | Per API key | ||
| Bucket refill | Your per-minute allowance, spread evenly across the minute | ||
The bucket starts full, so a quiet key can spend a whole minute's allowance at once; sustained throughput then settles at the steady-state rate for your plan.
When you hit the limit
The response is 429 rate_limited with a Retry-After header giving the number of seconds before the next attempt is allowed.
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 3
RateLimit-Policy: "default";q=50;w=60
RateLimit: "default";r=0;t=3
{ "error": { "code": "rate_limited", "message": "too many requests" } }Response headers
Throttled responses carry the standardized IETF RateLimit headers, so a generic agent client can self-throttle without parsing a vendor format, alongside the existing Retry-After and the API's locked X-PostMe-* headers.
| Header | Example | Meaning |
|---|---|---|
Retry-After | 3 | Seconds to wait before retrying. Present on 429. |
RateLimit-Policy | "default";q=50;w=60 | The policy: quota q requests per window w seconds (your plan's per-minute allowance). |
RateLimit | "default";r=12;t=29 | Live state: r requests remaining, and t seconds until the bucket fully replenishes. |
Prefer Retry-After on a 429; read RateLimit r= to pace yourself before you hit the wall.
Best practice
- Honor
Retry-Afterverbatim. Don't retry sooner, or you'll just stay banned longer. - Cap parallelism on your side; the limit is server-wide per key, not per worker.
- Burst is for short spikes like backfilling a batch of posts, not for sustained throughput.