TikTok API rate limits are per-endpoint, per-product ceilings on how many requests your application can send in a given time window. The Display API: 600 requests per minute per endpoint (sliding window). The Content Posting API limits publishing to 6 requests/minute per user token, with a daily cap of roughly 15 to 25 videos per account that varies by account tier and is shared across all API clients. The Research API: 1,000 requests per day, 100,000 records per day. Exceed any limit and TikTok returns HTTP status 429 with error code rate_limit_exceeded and throttles further requests until the window resets.
What Are TikTok API Rate Limits in 2026?
TikTok API rate limits are the maximum number of requests your application is permitted to make within a defined time window. Limits are set and enforced separately for each API product and each endpoint within that product. There is no single global quota that covers your entire integration.
In practical terms, this means a burst of analytics reads does not eat into your publishing quota - but it also means you can be throttled on one endpoint while having headroom on another. Understanding which limits apply to which surfaces is the first step to building a TikTok integration that holds up under real traffic.
TikTok enforces limits at two layers: the per-user token layer (most relevant for the Content Posting API) and the per-endpoint app layer (most relevant for the Display API and Research API). Some daily aggregate caps sit above these and are not publicly documented, which means production failures can occur at thresholds your team has never seen in testing.
What Changed for TikTok Rate Limits in 2025-2026?
Several meaningful shifts took place across TikTok's API surface between mid-2025 and June 2026.
Research API access tightened further
TikTok has narrowed Research API eligibility more strictly to verified academic and public-interest institutions. Commercial platforms that were using Research API access for content discovery workflows are required to migrate to commercial API endpoints or a licensed third-party data provider. Attempting to use Research API credentials for commercial use cases now risks losing access entirely.
New Creator Search Insights API (2026)
In 2026, TikTok introduced the Creator Search Insights API - the first endpoint to return searchable creator-level data (follower ranges, content category, average engagement rate, audience growth trends) without requiring individual creator OAuth authentication. This partially addresses the long-standing demographic data gap in the commercial API, though it returns follower count ranges rather than exact figures.
TikTok Shop API expanded
The TikTok Shop API, launched in 2024 and significantly expanded through 2025, is now a primary integration target for commerce-facing platforms. It links creator content performance to product-level sales data and operates under the TikTok Shop rate-limiting model, which uses a dynamic QPS (queries-per-second) allocation tied to the number of authorized shops rather than a fixed published ceiling.
Originality Policy enforcement (September 2025)
TikTok enforced its Originality Policy more strictly from September 15, 2025. Platforms posting recycled or watermarked content through the Content Posting API now see spam_risk_too_many_posts and spam_risk_user_banned_from_posting responses more readily, even before hitting numeric rate ceilings. These are not rate-limit errors in the technical sense, but they function as publishing blocks that integration teams must handle alongside 429s.
EU researcher data access (October 2025)
The European Commission's delegated act on data access for vetted researchers came into force on October 29, 2025, following a preliminary finding that TikTok had not fully met its Digital Services Act obligations on researcher data access. This creates a separate EU regulatory pathway for academic researchers that runs in parallel to TikTok's own Research API programme.
Request Limits by Endpoint Category
The table below summarises the confirmed default rate limits by API product as of mid-2026. Where TikTok has not publicly disclosed a specific figure, this is noted.
A few important caveats apply to this table.
- The Display API's 600 requests/minute figure is the publicly documented default. App-level aggregate daily caps exist but are not published and vary by approval tier.
- The Content Posting API's per-user cap (6/minute) is enforced at the user-token level. This means spreading load across multiple user tokens scales the per-minute cap linearly - but an undisclosed daily per-client allowance sits above all user-token caps combined. TikTok adjusts this figure without notice.
- The Research API is restricted to qualifying universities, non-profit academic institutions in the US, EEA, UK, Switzerland, and Brazil. Commercial use cases are not eligible.
- The TikTok Shop API uses dynamic QPS allocation. Your quota is not a fixed number - it is computed based on the number of authorized shops and the resource characteristics of the endpoint called. TikTok does not expose a quota query API, so build your client to adapt to 429 responses rather than hard-coding a threshold.
How TikTok's Rate-Limit Resets Work
TikTok uses two distinct reset mechanisms depending on the API product.
Sliding window (Display API, Content Posting API)
For the Display API and the Content Posting API's per-minute caps, TikTok uses a one-minute sliding window. This means TikTok counts the requests your app sent in the 60 seconds immediately before each incoming request, not from a fixed clock boundary. The practical effect: you cannot safely burst to the limit at the start of a minute and then send nothing. A burst that fills the window is throttled until enough requests fall outside the 60-second lookback.
Daily reset at 12:00 AM UTC (Research API)
Research API daily quotas reset at exactly 12:00 AM UTC. If your integration runs batch jobs against the Research API, schedule them to start after midnight UTC to make full use of the new allocation. Requests made in the final seconds before midnight count against the expiring quota, not the new one.
Response headers
Each TikTok API v2 response includes X-RateLimit-Remaining and X-RateLimit-Reset headers. Validate these on the client side before sending the next request rather than waiting for a 429 to signal that you have run out of headroom.
Error 429 and Other Rate-Limit Codes: What They Mean
When your application exceeds a TikTok API rate limit, TikTok returns HTTP status 429 and throttles further requests from your app until the window resets. The response body includes an error code that tells you which type of limit you hit.
A critical distinction: the TikTok Shop API can return a 429 even when your app has not exceeded its own quota. Platform-level protective throttling - triggered when TikTok's infrastructure detects unusually high load across all callers - produces the same 429 response. The correct handling strategy is the same in both cases: back off and retry. But the cause differs, and a platform-level throttle will self-resolve faster than a quota breach.
Also separate permanent from temporary failures. A revoked OAuth token, an exhausted daily creator quota, and a burst rate-limit breach should not all flow through the same retry policy. Map error codes to retry strategies before they surface in production.
How to Stay Within TikTok's Limits at Scale
Managing TikTok API rate limits under real production traffic requires a layered strategy, not a single config value.
Layer your rate limiter by surface
- Apply per-user protection so one high-volume account does not starve the others sharing your app credentials.
- Apply per-endpoint controls because read and publish paths have different limits and different consequences for breaches.
- Apply queue-aware scheduling so retry attempts do not amplify an existing limit breach. A naive retry loop that fires immediately makes a sliding-window throttle worse, not better.
Use exponential backoff with jitter
When you receive a 429, do not retry immediately and do not retry at a fixed interval. Exponential backoff with random jitter distributes retry load and prevents the thundering-herd pattern where many clients simultaneously retry at the same moment. A simple pattern: wait (2^attempt × base_delay) + random milliseconds before each retry, up to a maximum of five attempts.
Use batch endpoints wherever they exist
On the TikTok Shop API, batch endpoints count as a single request regardless of how many items are in the payload. Replacing N single-item calls with one batch call is the most effective way to reduce request volume. On the Display API, prefer paginated list endpoints over repeated single-resource calls for the same reason.
Read X-RateLimit-Remaining before each request
TikTok includes X-RateLimit-Remaining and X-RateLimit-Reset in every API v2 response. Checking the remaining headroom on the client side before firing the next request - rather than waiting for a 429 - reduces unnecessary failures and keeps your retry queue shorter.
Cache aggressively for read endpoints
Creator profile data, video metadata, and engagement metrics do not change second-to-second. Cache responses from the Display API for a reasonable TTL (typically 15-60 minutes for analytics use cases) to reduce raw request volume without sacrificing data freshness for your users.
Partition accounts across multiple app credentials
A single TikTok API app can manage many user accounts through OAuth, but per-app aggregate daily caps apply across all of them. If you are managing more than roughly 100 accounts, partition users across multiple app credentials (each with its own Client Key and Client Secret) to avoid hitting aggregate ceilings.
Move your integration to the server
Publishing flows, analytics sync, and token refresh should all run server-side. Client-side integration gives you no control over retries, token lifecycle, or tenant isolation. Once a few high-volume customers share the same infrastructure, a single misbehaving client can degrade service for all others. Backend ownership is the prerequisite for any of the strategies above to work reliably.
How to Request a Higher Quota from TikTok
TikTok reviews quota-increase requests for the Display API and Content Posting API on a case-by-case basis. There is no self-serve upgrade path and no published SLA for approval timelines.
For the Display API and Content Posting API
Submit a request through TikTok's official Support Page at developers.tiktok.com. Your request should include your app's current traffic profile, a clear explanation of the use case requiring higher limits, and evidence that you have already implemented best-practice rate-limit handling (backoff, caching, queuing). TikTok is more likely to approve requests from apps that have passed an audit and have a demonstrable production track record.
For the Research API
The Research API daily limit of 1,000 requests per day is currently fixed. TikTok's stated position is that it cannot grant exceptions, though it encourages researchers to email Research-API@tiktok.com to share use cases that may inform future quota decisions. If your research project requires more than 100,000 records per day, design your methodology around pagination checkpoints and multi-day data collection rather than expecting a limit increase.
For the TikTok Shop API
The TikTok Shop API quota grows automatically as you expand your authorized shop scale - no separate application is required. For large promotions or peak-traffic events where you anticipate hitting the dynamic ceiling, contact your TikTok Account Manager or platform technical support in advance to discuss options. Do not wait until the day of the event.
When TikTok's Limits Become a Scaling Bottleneck
Not every application hits TikTok's rate limits in a meaningful way. The limits become a genuine bottleneck in specific architectural conditions.
Managing more than a few hundred users on a shared app credential
The Content Posting API's per-user cap scales linearly with user tokens - more users, more per-minute capacity. But the undisclosed per-client aggregate daily allowance does not scale in the same way, and TikTok adjusts it without notice. Platforms that have grown past a few hundred active publishing users often discover the aggregate ceiling only when they hit it in production.
Polling for content updates at scale
TikTok does not provide native webhooks for content or profile changes. Building polling systems that check for updates across tens of thousands of creators consumes Display API quota quickly. Once you cross 10,000-15,000 active TikTok accounts, naive polling becomes a design constraint, not just an inefficiency.
Multi-platform analytics aggregation
If your platform is pulling TikTok data alongside Instagram, YouTube, and other platform APIs, the cumulative request volume across all integrations typically makes the per-endpoint ceilings on TikTok's Display API the first constraint you hit - even if individual platform volumes look manageable in isolation.
Real-time use cases
TikTok's API is not designed for real-time data access. Rate limits, the absence of webhooks, and the 24-hour data refresh cycle on authenticated accounts mean that use cases requiring sub-minute data freshness are difficult to build on TikTok's native API without hitting limits aggressively. Designing for eventual consistency - accepting that data may be 15-60 minutes stale - is usually the only pragmatic path.
Related Reading
For a full walkthrough of TikTok API authentication, endpoint setup, and the approval process before you encounter rate limits, see our Introduction to TikTok API guide at getphyllo.com/post/introduction-to-tiktok-api
How Phyllo Helps You Scale Past TikTok's Per-User Rate Limits
TikTok's per-user rate limits are enforced at the OAuth token level, which means a platform serving many creators must coordinate quota distribution across every user in its system. When the aggregate daily cap is undisclosed and adjustable, that coordination work becomes a permanent operational burden.
Phyllo is a unified API that sits between your platform and TikTok's native endpoints. When your users connect their TikTok accounts through Phyllo's connect flow, Phyllo manages the OAuth token lifecycle, handles data refresh on a 24-hour cycle for authenticated accounts, and abstracts the polling infrastructure that TikTok's lack of native webhooks otherwise requires you to build yourself.
For platforms that need creator profile data, engagement metrics, audience demographics, and content performance data at scale, Phyllo provides:
- Token lifecycle management - silent expiry and refresh handled automatically, removing the most common cause of production failures in TikTok integrations.
- Smart webhooks - Phyllo notifies your platform of content and profile changes without you building polling infrastructure against TikTok's endpoints.
- Audience demographic data - TikTok's direct API does not return gender, age, or location breakdowns through standard commercial endpoints. Phyllo surfaces this data for authenticated creators.
- Cross-platform normalisation - the same API call that retrieves TikTok creator data also works for Instagram, YouTube, Twitch, LinkedIn, and more, reducing the number of separate rate-limit strategies your team must maintain.
It is worth being direct about what Phyllo is not: it is not a way to bypass TikTok's terms of service, and it has its own rate limits at the platform layer. What it removes is the need for your team to manage per-user token distribution, build polling systems from scratch, and chase undocumented aggregate caps through trial and error in production.
For platforms at an early stage, TikTok's native API may be sufficient. For platforms past a few thousand active creators, the coordination overhead of per-user rate limits typically becomes the development team's dominant ongoing cost - and that is the problem Phyllo is designed to solve.
🔗 Explore Phyllo's TikTok API: See the full data coverage, endpoint list, and integration options for Phyllo's TikTok API at getphyllo.com/tiktok-api
Frequently Asked Questions
What is the TikTok API rate limit for 2026?
TikTok enforces separate limits by product: 600 requests/minute per endpoint for the Display API, 6 posts/minute per user token for the Content Posting API, and 1,000 requests/day for the Research API. There is no single unified limit.
What does TikTok API error 429 mean?
HTTP 429 with error code rate_limit_exceeded means your application has exceeded the request threshold for a given endpoint within the current sliding window or daily quota. TikTok throttles all further requests until the window resets. Check the X-RateLimit-Reset header in the response to determine when to retry.
How do I increase my TikTok API quota?
Submit a request through TikTok's developer Support Page at developers.tiktok.com. Include your current traffic profile and use case justification. TikTok reviews requests individually, and approval is not guaranteed. The TikTok Shop API is an exception: its quota scales automatically as you add more authorized shops.
When does TikTok's API daily quota reset?
Research API daily quotas reset daily, at 12:00 AM UTC. Per-minute limits on the Display API and Content Posting API use a sliding window and do not reset at a fixed clock boundary.
Does the TikTok API have per-user rate limits?
Yes. The Content Posting API enforces a limit of 6 requests per minute per user access token and 25 videos per account per day. If you are managing many user accounts from a single application, these per-user limits compound into an aggregate load that TikTok also caps at the app level - though the app-level aggregate cap is not publicly documented.
