TikTok API Rate Limit: 600 Per Minute and 6 Per Minute Are Both Official
- Display API endpoints are documented at 600 requests per minute on a one-minute sliding window.
- Content Posting API is documented at 6 requests per minute per user access token — a 100× difference.
- The rule that resolves it: when a platform shows two rate numbers an order of magnitude apart, ask whether each governs reading or writing.
- Exceeding either returns HTTP 429 with rate_limit_exceeded, so limit problems are visible rather than silent.
Search for TikTok's API rate limit and you will find two numbers that cannot both be right: 6 requests per minute and 600 requests per minute.
What makes it genuinely confusing is that both camps link to developers.tiktok.com. Neither is misremembering.
They are quoting two different APIs.
The two documented numbers
| API | Purpose | Documented wording | Rate |
|---|---|---|---|
| Display API | Reading — user info, video query, video list | "/v2/user/info/ — 600", "/v2/video/query/ — 600", "/v2/video/list/ — 600"; "Request rate calculation is based on a one minute sliding window." | 600/min |
| Content Posting API | Writing — publishing content | "Each user access_token is limited to 6 requests per minute." | 6/min |
Both were confirmed on developers.tiktok.com. Two adjacent figures from the posting side are worth having alongside them: "There may be at most 5 pending shares within any 24-hour period", and an upload URL that is "valid for one hour after issuance."
Note that the 600 figure is documented per endpoint, not as a shared pool, and calculated on a sliding one-minute window rather than a fixed clock minute.
The rule this teaches
The specific numbers matter less than the pattern, because you will meet this pattern on every platform:
When one platform publishes two rate limits an order of magnitude apart, ask whether each one governs reading or writing. Read quotas are generous. Write quotas are stingy — because writing is what produces spam.
The asymmetry has a clear cause. Limiting reads protects the platform's servers, which is a cost problem. Limiting writes protects the platform's content ecosystem, which is an existential problem. The second motivation is far stronger, so the second number is far smaller.
This also explains a common observation: analytics tools never seem rate-limited, while publishing tools always feel like they are queueing. They are drawing from pipes of very different diameters.
What this means if you do not write code
These numbers reach you anyway, wearing different clothes:
- Slow batch publishing is often not the tool's fault. A single publish typically costs several requests (initialise, upload, poll status). At 6 per minute per user token, a batch of ten is arithmetic, not sloth.
- "At most 5 pending shares per 24 hours" is a queue depth, not a daily post limit. These get conflated constantly. It caps how many uploads can be sitting unresolved, not how many you may publish in a day.
- The quota is attached to your account, not to your tool. This is the one that saves money: switching schedulers does not raise it. If you are hitting a platform ceiling, no vendor can sell you past it.
We went through the account-versus-tool distinction in more detail in this piece.
Where the same confusion shows up elsewhere
This is the third distinct shape of "two official numbers" we have catalogued, and the shapes are worth telling apart because the fix differs.
| Shape | Example | What to do |
|---|---|---|
| Two product surfaces, two pages | A platform documents one minimum scheduling lead time for member posts and a different one for page posts | Work out which surface you are on; plan against the more conservative number |
| Two numbers on one page | Instagram's content-publishing docs state a 24-hour cap of 100 in one section and 50 in a carousel section | Assume documentation drift; plan against the conservative one |
| Two APIs, two products | TikTok Display at 600/min, Content Posting at 6/min | Identify which API your tool uses; the numbers are both correct |
The common thread: the numbers are usually not wrong, the mapping is. Before concluding a platform contradicts itself, check whether the two figures govern two different things.
And the strongest move in all three cases is the same one: if the platform offers an endpoint that reports your account's current usage, that beats any static figure in any document. Your own number is always current and always applies to you.
Failures are loud, which is useful
The documentation is explicit about what exceeding a limit looks like: HTTP 429 with error code rate_limit_exceeded.
That is genuinely helpful for diagnosis. If your publish is failing and the error is not 429, stop suspecting rate limits and look elsewhere — content review, expired credentials, malformed fields. A surprising amount of debugging time gets spent tuning delays for a problem that was never about timing.
For higher limits, the documentation directs developers to submit a request through the official support page for review. Realistically that path is built for applications with scale and compliance standing behind them, not for individual operators.
One limit we are deliberately not quoting
There is a widely repeated claim that unaudited TikTok clients may only serve 5 users in 24 hours. We have not been able to retrieve that sentence first-hand from the current documentation. What the get-started page does say is: "All content posted by unaudited clients will be restricted to private viewing mode."
That is a different restriction from the 5-pending-shares rule, and conflating them produces a claim that sounds authoritative and may not be accurate. Until we can quote the original sentence, we will not put a number on it — which is the same standard we would ask of anyone quoting a platform at us.
Planning around a small write quota
Given a hard ceiling on writes, there are two coherent strategies:
- Accept it and plan the cadence. Six requests per minute is plenty for any realistic organic posting schedule. If it is not, ask honestly whether the volume you want is a volume the platform wants.
- Do not use the write API at all. Operating through the normal interface, at human pace, has a different ceiling — what one operator can plausibly do — and it does not share a token pool across accounts.
The second route is what NoobClaw does: it runs on your own machine, each account in its own fingerprint browser with its own IP, acting at a randomised human-like cadence. It will never hit "a hundred posts a minute" throughput — but that throughput is precisely what the 6-per-minute figure exists to prevent, so treating it as a goal was always going to end in a rate limit.
FAQ
Is the 600/min limit shared across all endpoints?
The documentation lists it per endpoint — /v2/user/info/, /v2/video/query/ and /v2/video/list/ each at 600 — and specifies a one-minute sliding window. So it reads as a per-endpoint allowance rather than a shared pool. That applies to the Display API only; the posting side is governed separately.
My tool never mentions rate limits. Is it exempt?
No. These limits apply platform-side to anything using the official APIs. A tool that does not mention them is usually hiding queueing and retries behind the interface, which you experience as "a bit slow" rather than as an error. A quick test: queue twenty posts and see whether total time grows linearly.
Can I raise the limit?
The documented route is a request through TikTok's support page for review. In practice this is aimed at applications with meaningful scale. For most operators the more useful move is to stop treating the API ceiling as the constraint — for the overwhelming majority, content production is the actual bottleneck, and it is nowhere near 6 pieces per minute.