TikTok direct post init: 6 requests per minute per token, batch queue

TikTok's direct post reference limits init calls to 6 per minute per access token. Ten rendered videos take two minutes to start; a small queue handles it.

5 min readSume
All posts

Short answer

The TikTok Direct Post reference lists a limit of 6 requests per minute per access token on the init call. If you render 30 videos and want to post them all, starting the uploads takes about five minutes for one token, no matter how fast the renders finish. Queue the init calls and respect the limit rather than retrying on errors.

Rendering is not the bottleneck here. A Sume Timeline render runs asynchronously and bills per output minute, so you can finish renders ahead of time and let the publish queue drain at the allowed rate.

The numbers

The arithmetic is simple; the table shows how long the init phase takes for batches of different sizes at the stated limit.

Init time at 6 requests per minute per token (read 2026-10-03)
VideosInit timeRender cost at 30 s each (Sume public rate)
61 minute$0.60
122 minutes$1.20
305 minutes$3.00
6010 minutes$6.00

A simple queue

A token bucket or a fixed delay both work. The simplest version spaces init calls by 10 seconds, which is 6 per minute exactly; add a margin by spacing them 12 seconds apart. Keep per-token queues separate if you publish for several creators, since the limit is per access token.

On an error that signals rate limiting, back off rather than resending at once. On any other error, record it and move on, so one bad video does not hold the whole queue.

import time

MIN_GAP = 12.0  # seconds; 6 per minute is 10 s, so this keeps a margin

def drain(items, send):
    last = 0.0
    for item in items:
        wait = MIN_GAP - (time.monotonic() - last)
        if wait > 0 and last:
            time.sleep(wait)
        last = time.monotonic()
        send(item)

if __name__ == '__main__':
    drain(range(3), lambda i: print('init', i, round(time.monotonic(), 1)))

Why render order matters

Render first, then publish. A Timeline render with a 30-second video bills as one output minute at $0.10, so 30 videos cost $3.00 and finish well before the queue does. Waiting to render until each slot comes up saves nothing and puts a render failure in the middle of a publishing window.

Once all files are ready, check each against the TikTok guide: MP4 recommended, H.264 recommended, 23 to 60 fps, 360 to 4096 pixels, up to 4 GB. Run the check before init, not after.

  • Use one idempotency key per render so a retry cannot double-bill.
  • Keep finished files until the publish step confirms success.
  • Log the position in the queue so a restart resumes where it stopped.
  • Read the TikTok limit again before a large launch; the number is theirs to change.

Related

For the upload mechanics, see chunk planning for a 30-minute render and the 4 GB file cap.

Handling several creators

The limit is stated per access token, so an agency posting for five creators has five independent buckets, each with its own 6 per minute. Keep one queue per token and run them in parallel if you like; do not share one global delay, which would slow everyone to the rate of one.

Store the token alongside the queue state, and never log it. When a token expires or is revoked, pause only that queue and surface the problem; the others should keep draining.

If you need numbers for a plan, take the limit from the reference page on the day you build and keep it in configuration, not in code. A value read from a document can change.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume