TikTok Content Posting API:開発者ガイド
TikTokAPI開発者向け

TikTok Content Posting API:開発者ガイド

TikTok Content Posting APIで公開できる内容、未審査アプリが非公開でしか投稿できない理由、initとポーリングの流れ、 公式に記載されたレート制限について解説します。

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のドキュメントでレビュー期間を明示していないため、その期間は非公開かつ未確定のものとして扱ってください。自分でコントロールできない承認を前提にローンチ日を計画することになります。

公開の呼び出しの流れは?

  1. POST /v2/post/publish/creator_info/query/でクリエイターが許可しているプライバシーレベルとインタラクション設定を確認する。
  2. POST /v2/post/publish/video/init/にpost_info(タイトル、privacy_level、無効化フラグ、video_cover_timestamp_ms、商用コンテンツの切り替え)とsource_infoを添えて呼び出す。
  3. sourceがFILE_UPLOADの場合は、宣言したchunk_sizeとtotal_chunk_countに合わせて、initが返したupload_urlにバイトデータをPUTする。sourceがPULL_FROM_URLの場合は、TikTokが検証済みのドメインから代わりに取得する。
  4. initで得たpublish_idを添えてPOST /v2/post/publish/status/fetch/を呼び出し、ポーリングする。
  5. 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です。

レート制限は?

リファレンスドキュメントには、いずれもユーザーアクセストークンごとに、次の2つの数値が明確に記載されています。

  • ダイレクト投稿のinit:1分あたり6リクエスト。
  • ステータス取得:1分あたり30リクエスト。

1ユーザーあたり1分間に6回のinitは、スケジューラーとしては十分ですが、一括インポートには厳しい数字です。1分あたり30回のステータス取得は十分に見えますが、数百件の処理中の投稿が1つのポーラーを共有するようになると、グローバルなループではなくトークンごとのバックオフが必要になります。

読んだContent Posting APIのページからは、1ユーザーあたりの1日の投稿数上限、動画ファイルサイズの上限、最長再生時間について、明記されたものは確認できませんでした。アカウントごとの動画再生時間の上限を知るための本来の情報源はcreator infoのレスポンスなので、数字を決め打ちするのではなく、そちらを読むべきです。

注: ここに記載した数値は、2026年9月時点でTikTokのContent Posting APIドキュメントと照合して確認しています。プラットフォームは予告なくこれらを変更することがあります。

実際に3週間を消費するもの

審査です。 これが最大の壁で、InstagramやLinkedInの審査とは特殊な点で異なります。コードを出荷し、アカウントを接続し、公開まで済ませても、すべての投稿が誰にも見えないままということがあり得ます。ログを見る限り何もおかしく見えません。ステークホルダーがステージング環境で成功したPUBLISH_COMPLETEを見て、機能が完成したと判断させないようにしてください。

PULL_FROM_URLのためのドメイン確認。 TikTokにメディアを取得させるのは、チャンク分割アップロードよりはるかに簡単ですが、URLプレフィックスの所有権を証明する必要があります。メディアが自動生成されたホスト名のバケットに置かれている場合、この簡単な経路を使う前に、ストレージにカスタムドメインを追加する必要が出てきます。

トークンの更新。 TikTokのアクセストークンはリフレッシュトークンで更新され、接続が期限切れになるとクリエイターは再接続が必要になります。どのプラットフォームでも同じですが、大変なのは更新の呼び出し自体ではなく、状態管理と更新失敗時の通知です。

非同期の失敗処理。 initがpublish_idを返すことは公開ではありません。アップロードの成功も同様です。PUBLISH_COMPLETEだけが公開であり、FAILEDは非対応のエンコーディングなどの理由で数分後に届くこともあります。publish_idを保存し、processing状態を維持し、後で整合性を取る必要があります。このために必要な状態モデルについては、ソーシャルメディアスケジューリングAPIガイドで解説しています。

キャプションも自分で書く場合は、TikTok文字数カウンターでタイトルがどこで切れるかを確認できます。

まとめ

  • initし、アップロードまたは取得を行い、それからステータスをポーリングする。成功はPUBLISH_COMPLETEのみ。
  • 未審査のクライアントは非公開でしか投稿できません。公開投稿には審査が必要です。
  • video.publishスコープには、アプリへの承認とクリエイターの同意の両方が必要です。
  • ユーザートークンごとに、init 1分あたり6リクエスト、ステータス取得1分あたり30リクエスト。
  • レビューおよび審査にかかる期間はTikTokから公開されていません。

審査を自分で通さずにTikTokへ公開する

このセットアップコストを回避する一つの方法は、すでに審査を通過済みのAPIを通じて公開することです。BulkPublishはTikTokと他の14のプラットフォームを1つのREST APIでカバーしており、init、アップロード、ポーリング、リトライはすべてこちら側で処理するため、あなたが行う呼び出しはチャンネルIDを添えた単一の投稿作成リクエストだけです。クロス投稿する場合は、同じ呼び出しでInstagram ReelsとYouTube Shortsも対象にできます。エンドポイントは/developers/に、REST統合の概要は/integrations/rest-api/に記載されています。

関連記事