TikTok Content Posting API 会代表创作者发布视频和图片内容，流程是先调用 init，再上传文件或拉取 URL，最后轮询状态。开始之前最重要的一点是:在你的客户端通过 TikTok 审核之前，你发布的所有内容都会被限制为仅自己可见。你可以把整套集成搭建并测试完毕，却仍然无法发出一条公开帖子。
Content Posting API 能发布什么，又有哪些被限制？
该 API 支持视频和图片内容的直接发布，还有一条会把内容发送到创作者收件箱、由其自行完成发布的草稿路径。相关端点是视频用的 POST /v2/post/publish/video/init/、图片用的 POST /v2/post/publish/content/init/，以及用来查询结果的 POST /v2/post/publish/status/fetch/。此外还有 POST /v2/post/publish/creator_info/query/，官方要求你先调用这个接口，了解该创作者账号允许哪些操作。
真正的限制在于审核。TikTok 官方原话是:“未经审核的客户端所发布的所有内容都将被限制为私密可见模式。“在直接发布参考文档页面上，说法同样直白:未审核的客户端”只能发布到私密账号”，尝试发布会在 /publish/video/init/ 这一步被拦截。
| 关注点 | 官方文档怎么说 |
|---|---|
| 所需权限范围 | video.publish，需为你的应用获批，并由用户本人授权 |
| 未审核应用 | 内容被限制为私密可见模式 |
| 隐私级别 | PUBLIC_TO_EVERYONE、MUTUAL_FOLLOW_FRIENDS、FOLLOWER_OF_CREATOR、SELF_ONLY |
| 媒体来源 | FILE_UPLOAD 或 PULL_FROM_URL |
| URL 拉取 | 需要验证你对该 URL 前缀或域名的所有权 |
SELF_ONLY 会是你在开发期间不得不长期使用的取值。同样值得注意的是，某个创作者能使用的隐私级别集合并不是固定的:你需要查询 creator_info 并使用返回的结果，而不是硬编码 PUBLIC_TO_EVERYONE 然后碰运气。
注: 以上数据截至 2026 年 9 月，对照 TikTok Content Posting API 文档核实。平台可能随时改动这些数值且不另行通知。
身份验证是如何工作的？审核需要多久？
获取携带 video.publish 权限的用户访问令牌，走的是标准 OAuth 流程。这里叠加了两层授权:你的应用必须获得该权限范围，而且每个创作者本人也必须在连接时单独授权。二者缺一不可。
审核则是完全独立的另一个环节。它发生在你已经拥有一套可用的集成之后，因为 TikTok 预期你在提出审核申请之前就已经测试过这套流程。TikTok 在 Content Posting API 文档中没有说明审核所需的时长，因此这个时间线应视为未公开、未知。你的上线日期需要围绕一个你无法掌控的审批结果来规划。
发布调用的顺序是什么？
- 调用
POST /v2/post/publish/creator_info/query/，检查该创作者被允许的隐私级别和互动设置。 - 调用
POST /v2/post/publish/video/init/，附带post_info(标题、privacy_level、各项禁用开关、video_cover_timestamp_ms、商业内容开关)和source_info。 - 如果
source是FILE_UPLOAD，就按你声明的chunk_size和total_chunk_count，分块用PUT把字节数据上传到 init 返回的upload_url。如果source是PULL_FROM_URL,TikTok 会改为从你已验证的域名自行拉取。 - 调用
POST /v2/post/publish/status/fetch/，带上 init 返回的publish_id，并进行轮询。 - 把
PUBLISH_COMPLETE视为成功，把FAILED视为终态。在此之前的任何状态都不算是已发布的帖子。
# 1. init a direct post
curl -X POST "https://open.tiktokapis.com/v2/post/publish/video/init/" \
-H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
-d '{
"post_info": { "title": "Ship it.", "privacy_level": "SELF_ONLY" },
"source_info": { "source": "PULL_FROM_URL",
"video_url": "https://verified.example.com/clip.mp4" }
}'
# -> { "data": { "publish_id": "v_pub_url~..." } }
# 2. poll
curl -X POST "https://open.tiktokapis.com/v2/post/publish/status/fetch/" \
-H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
-d '{ "publish_id": "v_pub_url~..." }'文档中列出的状态值有 PROCESSING_UPLOAD(文件上传路径)、PROCESSING_DOWNLOAD(URL 拉取路径)、SEND_TO_USER_INBOX(草稿交给创作者本人)、PUBLISH_COMPLETE 和 FAILED。
速率限制是多少？
参考文档中明确给出了两个数字，均按每个用户访问令牌计算:
- 直接发布 init:每分钟 6 次请求。
- 状态查询:每分钟 30 次请求。
对定时发布工具来说，每个用户每分钟 6 次 init 请求已经相当宽裕，但对批量导入场景来说就比较紧张。每分钟 30 次状态查询听起来很多，但当你有数百条帖子共用同一个轮询器同时处理中时，你就需要按每个令牌单独做退避处理，而不是用一个全局循环。
我们在读过的 Content Posting API 页面中，没有找到明确记录的按用户每日发帖配额、最大视频文件大小或最长时长限制。创作者信息接口的返回结果才是获取该账号视频时长上限的预期来源，应该去读取它，而不是硬编码一个数字。
注: 以上数据截至 2026 年 9 月，对照 TikTok Content Posting API 文档核实。平台可能随时改动这些数值且不另行通知。
真正会耗费你三周时间的是什么？
**审核。**这是最大的一项，而且它和 Instagram 或 LinkedIn 的审核方式有一个明显不同之处:你可以把代码上线、连接账号、正常发布，却发现每一条帖子都是不可见的。你的日志里不会显示任何异常。不要让某位相关人员在预发布环境里看到一次成功的 PUBLISH_COMPLETE，就断定这个功能已经完成。
**PULL_FROM_URL 的域名验证。**让 TikTok 直接拉取你的媒体文件，比分块上传要简单得多，但前提是你必须证明自己拥有该 URL 前缀。如果你的媒体存放在一个由系统生成主机名的存储桶上，在能走这条便捷路径之前，你需要先给存储加上一个自定义域名。
**令牌刷新。**TikTok 的访问令牌通过刷新令牌来更新，一旦连接过期，创作者就必须重新连接。和所有平台一样，真正的工作量不在于刷新调用本身，而在于状态机的维护以及刷新失败时的通知机制。
**异步失败处理。**init 返回一个 publish_id 并不代表发布成功。上传成功也不代表发布成功。只有 PUBLISH_COMPLETE 才算数，而 FAILED 可能在几分钟后才出现，原因可能是编码格式不受支持等。需要存储 publish_id，维护一个”处理中”状态，并做好状态核对。我们的社交媒体定时发布 API 指南详细介绍了所需的状态模型。
如果你还要自己写文案，TikTok 字符计数器能告诉你标题会在哪里被截断。
简版总结
- 先 init，再上传或拉取，然后轮询状态。只有
PUBLISH_COMPLETE才算成功。 - 未审核的客户端只能私密发布。公开发布必须通过审核。
video.publish权限范围需要你的应用获批，并获得创作者本人的同意。- 每个用户令牌每分钟 6 次 init 请求，30 次状态查询。
- 审核和评估所需时长，TikTok 官方并未公布。
无需自行走完审核也能发布到 TikTok
绕开这套搭建成本的一种办法，是通过一个已经完成审核的 API 来发布。BulkPublish 通过一个 REST API 覆盖 TikTok 及另外 14 个平台，init、上传、轮询和重试都由我们这边处理，你只需要用一个渠道 ID 发起一次创建帖子的请求即可。如果你要跨平台发布，同一个调用也能同时面向 Instagram Reels 和 YouTube Shorts。相关端点文档见 /developers/,REST 集成概览见 /integrations/rest-api/。