Skip to main content
There are two independent limits. Request limits govern how often you may call the API. Posting caps govern how often a single connected account may publish. A request can pass the first and still be refused by the second.

​
Request limits

Your allowance belongs to your workspace and scales with the number of social accounts its owner has connected, because that is what determines how much work your integration legitimately has to do. The limit moves as soon as you connect or disconnect an account. There is no separate request limit per platform. All API keys in a workspace share this one allowance, including the keys that MCP connections create, so adding keys does not add requests. Test keys (sqk_test_) have a separate allowance of the same size, so sandbox traffic never uses up your live one.

​
The analytics burst limit

The analytics endpoints carry an additional per-second ceiling: your per-minute allowance divided by 60, never below 6. It applies to every endpoint requiring the analytics:read scope. This exists so a dashboard refresh cannot spend a whole minute’s budget in one burst and then stall. If you hit it, you receive a 429 with Retry-After: 1. The rejected request does not count against your per-minute allowance. Every other endpoint is governed by the per-minute window alone.
If your key has a custom rate limit configured, that value is used instead of the table above, and that key has an allowance of its own.

​
Posting caps

Each connected account has its own daily publishing cap. The caps are per account, so connecting more accounts raises your total throughput; they are not a shared pool. TikTok video and photo posts count against separate allowances, so 15 of each per day. On top of the daily cap, every account is limited to 25 posts per hour across all platforms, so a day’s allowance cannot be published in a single burst. When an account is capped, publishing to it is refused before the platform is called, and the response tells you which limit was reached and when to retry. If you publish to several accounts at once, the accounts still under their caps go through; only the capped ones are held back.

​
Response headers

Every rate-limited response includes these headers. Polling GET /jobs/{job_id} is not rate limited and does not carry them.

​
Exceeding a limit

Both request limits return 429 Too Many Requests with a Retry-After header:

​
Two different 429s

A 429 can mean one of two things, and they are handled differently:

​
Handling 429 errors

1

Read the Retry-After header

The header value tells you how many seconds to wait. For an analytics burst it is 1 second.
2

Back off and retry

Use exponential backoff: wait the Retry-After value, then double on each subsequent retry.
3

Spread analytics calls

If you are hitting the burst limit, space your analytics calls across the minute rather than firing them together.
4

Optimize your calls

Batch operations where possible and cache responses to reduce call volume.