TikTok rate_limit_exceeded: 6 requests a minute per access_token

TikTok's Direct Post reference limits each user access_token to 6 requests per minute, and a request over the limit is blocked with HTTP 429 rate_limit_exceeded. If you publish a batch of Sume-generated videos for one account, space the calls so no more than 6 go out in any minute. Sume's own concurrency setting controls generation, not your TikTok publishing.

TikTok's limit is from its Direct Post reference; Sume's batch and error behavior from Bulk runs and Errors, read 2026-10-01.

What counts toward the 6 per minute?

The note says each user access_token is limited to 6 requests per minute. It is stated per token, so a second user's token has its own allowance. It says requests, not posts, so your status checks and init calls need to fit the same budget until you know otherwise.

How is this different from Sume limits?

How should I pace publishing?

Treat generation and publishing as separate stages. Run the Sume queue, poll its status URL (the queue has no webhook), collect the durable URLs of finished items, then feed a publisher that sends at most one TikTok request every 10 seconds per token. A fixed 10 second gap keeps you at 6 a minute with no bursts.

For Sume 429s, read the retry-after header as in retry-after: how long to wait. For TikTok's 429, back off and send the call again later; do not loop at once.

Does a failed batch item need re-publishing?

A bulk queue's completed status means every item is terminal, not that every item succeeded, so branch on the failed count before you publish. Publish only items that finished, and see retry failed items in a bulk batch for the rest.