TikTok 接口一分钟能调几次?官方给了两个数,差 100 倍
- TikTok 官方文档里同时存在 600 次/分钟 和 6 次/分钟 两个速率,两个都是真的。
- 600 次/分钟 属于读取类的 Display API(用户信息、视频查询、视频列表);6 次/分钟 属于发布类的 Content Posting API。
- 通用判据:看到同一平台有两个差一个数量级的速率,先问它们管的是读还是写。读的额度慷慨,写的额度吝啬。
- 超限的表现是 HTTP 429 加 rate_limit_exceeded,而不是静默失败——这一点对排查很有用。
如果你搜过 TikTok 的接口限制,大概率见过两个互相打架的说法:有人说一分钟只能调 6 次,有人说能调 600 次。
更让人困惑的是,两边给的都是官方文档链接。
这不是谁记错了。两个数都是真的,它们属于两套不同的 API。
两个数,两套 API
| API | 干什么的 | 官方原文 | 速率 |
|---|---|---|---|
| Display API | 读:拿用户信息、查视频、列视频 | "/v2/user/info/ — 600"、"/v2/video/query/ — 600"、"/v2/video/list/ — 600";"Request rate calculation is based on a one minute sliding window." | 600 次/分钟 |
| Content Posting API | 写:发布内容 | "Each user access_token is limited to 6 requests per minute." | 6 次/分钟 |
两份文档都在 developers.tiktok.com 上,都是当前有效的。它们之间不矛盾,因为它们说的不是同一件事。
补充两个相关的数(同样来自官方文档):Content Posting API 侧还有一句 "There may be at most 5 pending shares within any 24-hour period."(24 小时内最多 5 个待处理的分享),以及上传链接 "valid for one hour after issuance"(签发后一小时内有效)。
一条可以复用的判据
这件事真正有价值的地方,不在于记住 600 和 6 这两个数,而在于它给了一条通用的读法:
看到同一个平台有两个差一个数量级以上的速率数字,先问这两个数管的是读还是写。读的额度普遍慷慨,写的额度普遍吝啬 —— 因为写才会产生垃圾内容。
这条判据在其它平台上同样成立。平台限制读取,主要是为了保护自己的服务器;平台限制写入,是为了保护内容生态。后者的动机强得多,所以数字也小得多。
这也解释了一个常见的困惑:为什么分析类工具(拉数据、看趋势)从来不抱怨限速,而发布类工具永远在排队。它们走的是两条粗细完全不同的管子。
顺带记一个同族但形状不同的例子:Instagram 的内容发布文档里,同一个页面的两段分别写着 24 小时 100 条和 50 条两个数。那不是两套 API,更像是同一份文档的不同段落由不同的人在不同时间维护。处理方式还是一样的:按更保守的那个数规划,并优先用平台提供的「查我这个号当前用量」的接口 —— 查自己的号,永远比找一个通用数字可靠。
这对用第三方工具的人意味着什么
如果你自己不写代码,只是用别人的工具,上面的数字依然会影响你 —— 只是以另一种形式出现。
- 发布慢不一定是工具烂。 每个用户令牌每分钟 6 次请求,而一次发布通常要好几个请求(初始化、上传、查状态)。批量发十条,排队是必然的。
- 「24 小时最多 5 个待处理分享」是队列深度,不是每日上限。 这两件事经常被混为一谈。它限制的是「同时挂在那里没处理完」的数量。
- 拉数据快、发布慢是正常现象。 看到工具的数据面板秒刷新、发布却要等,不是它偷懒。
我们在TikTok 第三方工具一天能发几条那篇里讲过一个更容易被忽略的点:这些限制是按人算的,不是按工具算的。换一个工具不会让你的额度变大。
超限之后会怎样
官方写明超限的响应是:HTTP 状态 429,错误码 rate_limit_exceeded。
这一点对排查很有用 —— 它是显式报错,不是静默失败。所以如果你的发布失败但错误信息不是这个,那原因多半在别处(内容审核、登录态、字段格式),别往限速上猜。
文档也写了提高额度的路径:通过官方支持页申请审核。这条路对有规模的开发者是通的,对个人使用者意义不大。
一个更大的问题:你真的需要走 API 吗
说到这里值得退一步。
走开放 API 发布,天花板就是平台给的那个数 —— 换任何一个工具都不会变大,因为额度挂在你的账号上而不是工具上。 这是很多人换了三个工具还是觉得慢的根本原因。
另一条路是不走 API:在本地浏览器里以真人的方式操作。这条路的速率上限不是接口给的,而是「一个人手动能做多快」—— 听起来更慢,但对多账号场景反而更合适,因为每个号各自在自己的环境里跑,不共享一个 API 额度池。
NoobClaw 走的是后一条路:在你自己电脑上,每个号一个独立指纹浏览器环境,按拟真人节奏操作。代价是它跑不出「一分钟发一百条」那种速度 —— 但那个速度本来也不该是目标,毕竟发布类额度被卡得这么死,原因正是平台不希望有人跑那么快。
常见问题
600 次/分钟 是所有接口共享的吗?
官方文档是按端点分别列出的(/v2/user/info/、/v2/video/query/、/v2/video/list/ 各 600),并说明速率按一分钟滑动窗口计算。也就是说这是逐端点的额度,不是一个总池子。但这一条只适用于 Display API 侧,发布侧是另一套。
我用的工具没提这些限制,是不是它不受限?
不是。这些限制在平台侧生效,任何走官方接口的工具都受同一套约束。工具不提,通常是因为它把排队和重试藏在了后台 —— 你感觉到的是「有点慢」,而不是一条报错。判断方法:让它批量发二十条,看总耗时是不是线性增长。
提高额度需要什么条件?
官方给的路径是通过支持页提交申请并接受审核。实际上这条路是给有一定规模和合规资质的开发者准备的,个人开发者通过的概率不高。更现实的做法是接受这个额度,并据此规划你的发布节奏 —— 反正它也不是瓶颈,大多数人的瓶颈是内容产量,不是接口速度。
