TikTok ShopのAPIは公開されてる？エラーコードの対処法も解説！
TikTok Shopは動画とライブ配信で商品が瞬時に売れる魅力的なマーケットプレイスですが、自社ECとつながっていないと在庫ずれや受注処理の二重管理が発生し、せっかくの販路を活かし切れません。
そこで本記事は、開発者の方向けに、TikTok Shop APIを使って商品データや注文情報をシームレスに同期し、運用を自動化する方法をステップごとに整理しました。
英語中心の公式ドキュメントを読むだけでは把握しづらいポイントを日本語でかみ砕き、コード例とフロー図で実践的に解説します。
このページでわかること
- TikTok Shop APIの種類と公開状況
- OAuth認証フローと必須スコープの取得手順
- 商品・在庫・注文・物流データを同期する実装ステップ
- Webhookとサンドボックスを使ったテストとデバッグ方法
- 監視・バージョン管理・越境EC拡張のベストプラクティス
TikTok shopのAPI公開状況を理解する
TikTokが外部向けに公開しているサーバーサイドAPIは2025年7月現在、「Shop Open Platform（いわゆるSeller API）」と「Research API」の大きく2系統に分かれます。
Shop Open Platformは商品管理や受注処理を自動化したい事業者・SIer向け、Research APIは学術・公共目的でデータを取得したい研究者向けという役割分担です。Shop Open Platformの旧V1エンドポイントは2025年7月1日から段階的に停止が始まり、同年12月31日で完全廃止が予定されています。
| API名 | 主対象 | 主な用途 | 現行バージョン | 申請区分 |
|---|---|---|---|---|
| Shop Open Platform | 加盟店／SIer | 商品・在庫・注文・物流操作 | V2（V1は廃止予定） | パートナーセンター審査 |
| Research API | 研究者・報道機関 | 公開コンテンツ／Shop統計取得 | v2 | 研究者資格審査 |
Shop Open Platform（Seller API）の概要
Shop Open Platformは販売者がTikTok Shopと自社システムを直接つなぐための主要手段です。V2エンドポイントを中心に、商品の登録から配送情報の返送まで一連の業務をカバーしています。呼び出しにはパートナーセンターで取得した「App ID」「App Secret」を用いたOAuth 2.0クライアント認証が必要です。
- /api/v2/product/add
↳SKU情報を含めた新規商品登録 - /api/v2/product/stock/update
↳SKU単位の在庫数更新 - /api/v2/order/get
↳注文一覧と支払い状況の取得 - /api/v2/logistics/ship
↳配送ラベル生成と追跡番号登録 - /api/v2/finance/transaction/list
↳取引明細の取得（V1終了に伴いV2へ移行必須）
商品系エンドポイントは60 req/min、注文系は30 req/minが目安のレートリミットです。大型キャンペーン時はSKUごとに更新ジョブを分散し、リミット超過を避ける設計が推奨されます。
Research APIの概要
Research APIは読み取り専用で、Shopデータとして商品レビューや販売実績などを取得できます。2024年12月以降はEU圏でもShop関連エンドポイントが公開され、対象地域が拡大しました。取得できるデータは公開範囲に限定され書き込みは不可ですが、統計分析や競合調査に有用です。
- /v2/research/tts/shop
↳ショップIDを指定して評価数・フォロワー数・累計販売数などを取得 - /v2/research/tts/product
↳商品ID配列を投げて価格帯・レビュー数・在庫推定を取得 - /v2/research/video/query
↳ハッシュタグや期間で動画を検索し、再生数・いいね数を取得
Research APIは1時間あたり10 000ポイントのクォータ制で、リクエストごとに1–50ポイントを消費します。アクセストークンは24時間有効のため、長時間クロールを行う場合は自動リフレッシュ処理を組み込むと安全です。
TikTok ShopのAPIの基礎知識
TikTok Shop Open Platform（Seller API）は、商品・在庫・注文・物流・財務など店舗運営に欠かせない処理をREST/JSONで呼び出せます。ベースURLは地域によって異なり、グローバル向けは https://open-api.tiktokglobalshop.com/、日本市場向けは https://open-api.tiktokshop.com/ が一般的です。
すべてHTTPSで、リクエストとレスポンスはUTF-8のJSON形式。2025年7月時点の最新バージョンはV2で、V1系は同年末に完全停止予定です。
主要エンドポイント
Seller APIで扱う代表的なリソースは次のとおりです。呼び出し時は必ず timestamp と HMAC-SHA256 署名 sign を付与し、改竄を防ぎます。
- /api/v2/product/add
↳SKU情報を含む商品登録 - /api/v2/product/stock/update
↳SKU単位の在庫数更新 - /api/v2/order/get
↳注文リストと決済状況の取得 - /api/v2/logistics/ship
↳配送ラベル生成と追跡番号登録 - /api/v2/finance/transaction/list
↳取引明細取得（V1終了に伴い移行必須） - /api/v2/webhook/subscription
↳注文作成・キャンセルなどイベント購読
これらは2025年6月時点で有効なV2エンドポイントであり、今後の追加や変更が想定されるため定期的な確認が欠かせません。
利用制限とレートリミット
Shop APIにはアプリ単位で次のような上限が設けられています。
| リソース区分 | 上限値 | 設計時の注意点 |
|---|---|---|
| 汎用 | 50 QPS | 全エンドポイント共通の瞬間的なスパイクを抑制 |
| 商品関連 | 60 req/min | カタログ一括更新はSKUごとにジョブ分割 |
| 注文関連 | 30 req/min | 大量受注時はステータス別にバッチ取得 |
| Research API | 1 000 req/日 | 読み取り専用。超過でHTTP 429 |
超過時は60秒スライディングウィンドウでHTTP 429が返るため、指数バックオフまたはキューイングで再試行を行う設計が推奨されます。
認証方式とセキュリティ
Seller APIは「アプリ認可＋店舗認可」の二段階構成です。パートナーセンターで発行した app_key と app_secret を使い、OAuth 2.0（Authorization Code + PKCE）で店舗管理者が同意すると access_token を取得できます。
- ユーザーを
https://auth.tiktok-shops.com/oauth/authorize にリダイレクト（例：scope=`product.write,order.read`） - コールバックで受け取った `code` を `/oauth/token` にPOST
- JSONレスポンスから `access_token`（有効24 h）と `refresh_token`（有効365 d）を取得
- 期限前に `grant_type=refresh_token` でトークン更新
トークンとシークレットはKMS連携ストアに保管し、Webhook受信時には X-TTK-Signature を検証して改竄を防止します。また、CloudWatch MetricsとLambda Alertsを組み合わせることでHTTP 429や401の急増を即検知し、安全な運用を保てます。
TikTok shopAIPのテストとデバッグ
本番運用に移行する前に、エンドポイントの動作確認と障害時の切り分け手順を整えておくと、リリース後の想定外トラブルを大幅に減らせます。TikTok Shop APIはレスポンスヘッダーで詳細なエラー情報を返すため、ステージング環境で再現ケースを蓄積し、リカバリー方法まで自動化すると安心です。
一般的なエラーコードと対処法
まずは発生頻度が高いステータス／ビジネスコードとその対応策を一覧に整理しました。原因が分かった時点で暫定対応を実施し、再発防止策をCI/CDに組み込む流れが理想的です。
| HTTP | ビジネスコード | 主な原因 | 暫定対応 | 恒久対応 |
|---|---|---|---|---|
| 401 | 105005 | アクセストークン失効 | リフレッシュトークンで再取得 | 定期ジョブで有効期限を監視 |
| 403 | 105103 | 権限不足 | 必要スコープを追加し再認可 | スコープ管理ツールで差分を検知 |
| 404 | 200404 | リソースID誤り | パラメータを再確認 | バリデーションを事前チェックに組込 |
| 429 | 200429 | レートリミット超過 | 指数バックオフで再試行 | キュー制御で平準化 |
| 500 | 200500 | プラットフォーム側の一時障害 | 再試行＋監視通知 | 自動リトライと障害報告フロー |
リカバリーが難しいものはエラーログにリクエストIDを残し、運営窓口へ問い合わせられるよう準備しておくと復旧までがスムーズです。
Postman／Insomniaでの確認手順
ブラウザーより詳細なHTTP制御が行えるツールを使うと、署名付きリクエストやWebhook検証を手軽に再現できます。以下は推奨フローです。
- 環境変数の設定
↳app_key、app_secret、access_token、base_url をワークスペースに登録 - プリリクエストスクリプトで署名生成
↳timestampを生成し、HMAC-SHA256でsignを計算 - APIコレクションを実行
↳商品追加→在庫更新→注文取得の順で呼び出し、依存関係を確認 - テストスクリプトでアサーション
↳HTTP 200かつ business_code == 0 を検証し、失敗時はSlack Webhookへ通知 - モックサーバーでWebhook受信を擬似再現
↳X-TTK-Signatureを検証し、署名ズレがないか確認
この手順をテンプレート化し、チームメンバーが同一操作を繰り返し実行できるよう共有しておくと、リグレッションテストの効率が向上します。
まとめ｜TikTok Shop APIで売上最大化
本記事では、TikTok ShopでEC連携を進める開発者が押さえるべき要素を一通り整理しました。初めにShop Open PlatformとResearch APIの違いを把握し、最新バージョンの公開状況を確認しました。。
さらに、エラーコード別の切り分け表やPostman／Insomniaを利用した再現手順、CloudWatchとWebhook署名検証を組み合わせた監視強化のアイデアも取り上げました。
実際に運用へ移行する際は、トークン失効とレートリミットを想定したリトライ設計、署名ロジックの共通ライブラリ化、バージョン変更を検知するCIジョブを組み込むことで安定したデータ同期が実現します。大量トラフィックが発生するキャンペーン期はSKU単位の分散処理とバックオフを徹底し、障害発生時はリクエストIDを添えて迅速に運営窓口へ報告する流れを整えておくと安心です。
