TikHubのAPIキー、APIドキュメント、GitHubのSDKを手順どおりに検証

2026年11月3日、TikHubが公開している開発者向け資料をすべてダウンロードし、スクリプトで集計しました。openapi.jsonは3.1 MBで1,058件のエンドポイントパスが記載されており、モデルが読み込むと約840,000トークンになります。そのうち1,052件のエンドポイントでは、ドキュメント上の成功レスポンスがデータフィールドを持たない汎用ラッパーになっています。GitHub上のTypeScript、Go、Java、C++のSDKは最終コミットが2025年3月で、現在アクティブな1,055件のエンドポイントのうち32.3%しかカバーしていません。例外はPython SDKで、バージョン2.2.0は99.2%をカバーしています。

同じ夜、EveryInfra経由で実際に3回APIを呼び出しました。使用したのはcurl、当社のPython SDK、当社のリモートMCPサーバーです。TikTokのプロフィール、Douyinの動画、Xiaohongshuのノートを取得し、合計費用は$0.006668でした。TikHubの定価では同じ3件の取得に当社の1.8倍の費用がかかるため、当社のほうが約44%安くなります。TikHubのほうが安くなるのは、1日の利用量が多い場合と、ドキュメント化されていないXiaohongshuのエンドポイントを1つ使う場合の2つで、どちらも以下で説明します。

対象範囲、情報源、他の記事との違い

TikHubについては、すでに3本の記事があります。TikHubの代替の記事では、全体のカバー範囲と価格を比較しています。TikHubの料金を解説では、1,470件の料金表と無料クレジットを詳しく分析しています。TikHub Douyin APIの代替ではDouyinの37の機能を1つずつ価格比較しており、TikHubの代替ページに概要をまとめています。この記事が答えるのは別の問いです。「tikhub api key」「tikhub api doc」「tikhub github」で検索する人が、コードを1行書く前に知りたいことです。

キーはどこにあるのか？　認証はどう行うのか？　どのドキュメントを読めばよく、どのSDKがまだ動くのか？　最初に成功レスポンスを得るまで何ステップかかるのか？　料金には最後に、簡単な確認として触れるだけです。

TikHubについては公開資料のみを使いました。具体的には、料金ページと導入ページ、ドキュメントサイト、openapi.jsonです。キーなしで利用できる価格表とデモエンドポイント、公開されているGitHub Organization、PyPIとnpmのページも含みます。これらはすべて2026年11月3日、シンガポール時間00:15から00:37の間に確認しました。

TikHubのアカウントは新規登録しておらず、TikHubの有料エンドポイントも一切呼び出していません。そのため、TikHubの有料エンドポイントの挙動に関する記述はすべて、TikHub自身のドキュメントに基づいています。EveryInfra側の数値はすべて、同じ30分間に行った実際のAPI呼び出しから得たものです。トークン数は、ダウンロードした各ファイルにo200k_baseトークナイザーを実行するスクリプトで算出しました。

tikhub api keyの取得方法：どちらも4つのアクション

新しいユーザーがまず欲しいのはキーです。TikHubの導入ページのタイトルは「First API Call in 4 Steps」です。1つ目のステップは、新規登録とメールアドレスの確認です。2つ目はAPIマーケットプレイスで各エンドポイントの料金と無料クレジットのルールを確認すること、3つ目は有料エンドポイントのためにチャージすること、4つ目はコーディングを始めることです。私たちはこのページを一語ずつ読みました。

4つのステップのどこにも、APIキーを作成するようには書かれていません。キーの手順は、ドキュメントサイトのREADME - Englishページの末尾にある「Get API Token」というセクションにあります。ログインしてユーザーセンターを開き、APIトークンのメニューをクリックします。次にトークンを作成し、リクエストヘッダーにコピーします。導入ページだけに従った読者は、4つのステップをすべて終えても、キーがどこにあるのかわかりません。

メールアドレスの確認は任意ではありません。チュートリアルとFAQのページでは、403レスポンスの原因の1つとして「email is not verified」が挙げられています。同じページには、1ユーザーあたり最大100個のAPIキーを作成できるとあり、プロジェクトごとに専用のキーを簡単に用意できます。料金ページによると、新規アカウントには$0.05（約50リクエスト分）の無料クレジットが1人1回付与されます。削除して作り直したアカウントには、2回目は付与されません。

同じページには、すべてのエンドポイントで無料クレジットが使えるわけではないとも書かれており、一部のエンドポイントは最初の呼び出しから有料残高が必要です。最小チャージ額は$5で、支払い方法はPayPal、Alipay（1日あたり最大$250）、USDT（ネットワーク手数料も負担）です。2026年7月20日に更新された返金ポリシーには「All Sales Are Final」とあります。返金を受けるには、エンドポイントが本当に動作せず、そのことをTikHubの技術チームが確認する必要があります。

もう1つ落とし穴があります。TikHubには2種類のキーがあります。ソーシャルデータのエンドポイント用のキーは、user.tikhub.ioのユーザーセンターで発行します。TikHubはベータ版のAIプロキシサービスも運営しています。そのAI APIページによると、ai.tikhub.ioで別途新規登録し、そのコンソールでキーを作成します。

同じページによると、このプロキシはOpenAI Python SDK、Anthropic SDK、Google AI SDKでは動作しません。素のHTTPリクエストを送る必要があります。一方のサービスのキーは、もう一方では使えません。「tikhub api key」で検索してAIプロキシのページにたどり着いた場合、そこで作成したキーではデータエンドポイントを利用できません。

EveryInfraでも必要なアクションは4つです。GitHub、Google、電話番号、メールアドレスのいずれかでログインします。コンソールのAPI Keysでキーを作成します。完全なキーが表示されるのは1回だけです。その後、ドキュメントの説明どおり、Authorization: Bearerヘッダーで送信します。

無料で試したい場合は、当社のGitHubリポジトリ2つにスターを付けると、コンソールで$1のトライアルクレジットを受け取れます。有効期間は24時間です。何回呼び出せるかは各機能の価格によって変わります。下の無料クレジットのセクションで、3つのケースについて計算しています。

スターを付けたくない場合は、代わりにチャージできます。料金ページの最小プランは$10です。TikHubと比べると、当社では別途のメール確認は不要ですが、最小チャージ額はTikHubの$5の2倍です。初日の支払いをできるだけ抑えたい人には、TikHubのほうが手軽です。

チームにとって最も重要なのは、「キーの作成」と「キーのスコープ」の行です。1ユーザーあたり100個のキーは、プロジェクトごとにコストを分けるには十分な数です。ただし、1つのキーを一部のエンドポイントに限定できるかどうかは、TikHubの公開ドキュメントには書かれていません。唯一の手がかりは、「token lacks required permissions」に関するステータスコードの注記です。当社のキーは、コンソールで製品ごとに制限できます。

たとえば、AIエージェントにはデータAPIへのアクセスを許可し、CAPTCHAの解決へのアクセスは許可しないようにできます。キーを無効化して、すべての呼び出しが401を返すようにすることもできます。キーのスコープを変更するとき、上限を引き上げるとき、支払いを行うときは、必ず人がコンソールにログインして操作する必要があります。APIで作成したキーの権限が、作成元のキーより広くなることはありません。そのため、キーを持つAIエージェントがそのキーを使ってアカウントを変更することはできません。

認証：Bearerヘッダー、Cookie、URL内のキー

どちらのサービスもAuthorization: Bearer <key>を使います。この形式はRFC 6750に由来します。この規格のセクション2.3では、URLクエリ内のトークンは「SHOULD NOT be used」とされています。セクション5.3ではさらに2点を挙げています。ブラウザ履歴やサーバーログに残る可能性があるため、BearerトークンをページのURLに含めないこと。平文で送信される可能性のあるCookieに保存しないこと。

TikHubのREADMEでは2つの方法が示されています。方法1はヘッダーで、こちらが推奨です。方法2はAuthorizationという名前のCookieで、「not recommended, only when method one is not available」と記されています。Swaggerページにも細かな注意点があります。右上のAuthorizeをクリックしたら、Bearerプレフィックスを付けずにトークンだけを貼り付けます。プレフィックスはページが自動で付けます。

認証に失敗したときにサービスが返す内容は、ドキュメント以上に多くを物語ります。問題が起きたとき、AIエージェントが見られるのはレスポンスボディだけです。シンガポール時間00:19:39に、TikHubのTikTokプロフィールエンドポイントをキーなしで呼び出しました。0.21秒で401が返ってきました。

レスポンスヘッダーにはWWW-Authenticate: Bearerが含まれていました。これはRFC 9110の15.5.2節が401に求めているものです。ボディのmessageはREADMEの「api-token-introduction」アンカーを指していました。メッセージの中国語版とDiscordのリンクもありました。docsフィールドはnullで、時刻はロサンゼルスのタイムゾーンでした。

シンガポール時間00:18:54に、EveryInfraをキーなしで呼び出しました。401が返り、コードはmissing_key、fault: account、retryable: falseでした。next_stepsフィールドは、キーをAuthorizationヘッダーに入れるよう呼び出し元に伝え、課金は一切発生していないと示していました。EveryInfraのレスポンスヘッダーにはWWW-Authenticateが含まれていないため、この点ではTikHubのほうが標準に忠実です。

より一般的なミスは、パラメータの誤りです。シンガポール時間00:19:24に、usernameの代わりにuserを指定してtiktok/profileを呼び出しました。EveryInfraは422 missing_paramを返し、不足しているフィールドとしてusernameを挙げました。さらに、userはこの機能のパラメータではないと示し、動作するサンプルとプラットフォームのカタログURLを添えていました。

TikHubのopenapi.jsonでは、973個のエンドポイントが422のバリデーションエラーを宣言しており、ドキュメントに記載された形式はWebフレームワークのデフォルトのフィールド検証メッセージです。TikHubのキーを持っていなかったため、パラメータ名のスペルミスに実際にどのように応答するかは確認できませんでした。比較はここまでとします。

キーをGit、ログ、チャット履歴に残さない

キーを手に入れたあとによくある事故は、他人に推測されることではありません。自分でリポジトリやスクリーンショット、AIツールとのチャットに貼り付けてしまうことです。GitHubのサポートされているパターンの一覧では、シークレットスキャンのルールを汎用ルール、AIが検出するシークレット、プロバイダールールの3つに分けています。11月3日時点で、一覧にはプロバイダールールが531件ありました。

ここで最も重要なのは、ある汎用ルールです。http_bearer_authentication_headerという名前で、コードに書き込まれたAuthorization: Bearerヘッダーを探します。GitHubはこのルールの精度を「中」としています。そのため、ヘッダーごとコミットしたキーは検出される可能性があります。ただし、通知を受け取り、代わりにキーを失効させられるのは、GitHubのパートナープログラムに参加しているプロバイダーだけです。それ以外の場合は、コンソールで自分でキーを無効にする必要があります。

2026年10月28日に、GitHubはプッシュ保護にAIによるシークレット検出を追加しました。この新しいチェックは決まったキー形式を必要とせず、変数名、ファイルパス、周辺のコードを調べます。初期の結果では、プッシュ保護が阻止したプッシュの数が2倍以上になりました。

ただし、この機能はデフォルトでオフです。まずAIによるシークレット検出とプッシュ保護を有効にする必要があります。対象はSecret ProtectionまたはAdvanced Securityを契約している組織に限られ、AIクレジットを消費します。ほとんどの個人開発者にとっては、次の3つの習慣が、どちらのサービスでも引き続き身を守る手段になります。

キーは環境変数か、クライアントのシークレット設定に保存します。MCPの設定には、キーそのものではなく${EVERYINFRA_API_KEY}のような参照を書きます。プロジェクトごとに別のキーを用意すれば、漏えいしても無効にするのは1つのキーだけで済みます。TikHubでは1ユーザーあたり最大100個のキーを作れるため、最後の習慣は簡単に実践できます。EveryInfraのコンソールでも複数のキーを作成でき、それぞれにIP許可リストを追加し、そのキーに不要なプロダクトをオフにできます。

両サービスとも、より弱い方式を1つまだ受け付けています。TikHubはAuthorizationという名前のCookieでトークンを受け付けており、非推奨としています。RFC 6750の5.3節によると、Cookie内のトークンにはクロスサイトリクエストフォージェリへの対策が必要で、平文で送信されうるCookieで送ってはいけません。EveryInfra側では、初期のMCPコネクタがURLクエリにキーを入れることができました。

EveryInfraのドキュメントには、この方式は今も動作するものの、URLは履歴やログに残るため新しい設定では使わないよう記載されています。EveryInfraのAIエンドポイントは、URL内のキーをそもそも拒否します。RFC 6750は、クエリでのトークンの使用を「SHOULD NOT」としています。現在はどちらのサービスもヘッダーを推奨しており、この点では一致しています。

TikHubの公開ドキュメントには、個々のキーを無効化またはローテーションする方法の説明がなく、401の6つの原因が挙げられているだけです。EveryInfraでは、無効化したキーは401を返し、再び有効にしたりローテーションしたりできるのはコンソールで操作する人間だけです。

キーを取得する前にできること

どちらのサービスも、新規登録の前に中身を確認できます。TikHubには8つのデモエンドポイントがあります。ドキュメントサイトには9項目が並んでおり、9つ目はデモのキャッシュ状態を表示するものです。デモエンドポイントはトークン不要で、固定のオブジェクトを返し、1時間キャッシュします。対象は、Douyinの固定のWeb版・アプリ版動画、Douyinの検索、Kuaishouの固定動画です。さらに、TikTokの固定ユーザー、TikTokアプリの固定動画、Instagramの固定ユーザー、WeChat記事の抽出も含まれます。

シンガポール時間00:19:38に、TikTokの固定ユーザーのデモを呼び出しました。0.65秒で200が返り、tiktokアカウントのデータが含まれていました。フォロワー96,500,000人、動画1,514本で、statsV2には正確なフォロワー数96,519,349人が入っていました。キーがまったくなくても実際のレスポンスの形がわかる、優れた設計です。ただし、紛らわしい点が1つあります。

デモのレスポンスには「Request successful. This request will incur a charge.」と、課金が発生する旨が書かれています。トークンを送っていないので、課金されるはずがありません。おそらく、すべてのエンドポイントが1つのレスポンスモデルを共有しており、この文がそのモデルのデフォルトのテキストになっているためでしょう。

EveryInfraにはデモエンドポイントはありません。代わりに、機能カタログ、検索ツールの一覧、CAPTCHAタイプの一覧、MCPのtools/listメソッドがすべてキーなしで使えます。カタログの各項目には、必須パラメータと任意パラメータ、1回の呼び出しで取得できる最大行数、price_usd、available、response_fieldsが記載されています。そのため、何かを呼び出す前に、返ってくるフィールド名と各呼び出しの料金がわかります。

シンガポール時間00:21:11に、APIキーなしでhttps://api.everyinfra.com/mcpにtools/listを送信したところ、12個のツールが返されました。2つのアプローチには、それぞれ異なる強みがあります。TikHubのデモでは、実際のレスポンスが1件どのようなものかを確認できます。EveryInfraのカタログでは、最初の呼び出しの前にすべてのフィールド名と料金を確認できます。

無料クレジットで何回試せるか

「無料クレジットはあるか」の次に来る本当の問いは、「必要なエンドポイントをそれぞれ数回試すのに足りるか」です。双方のトライアルクレジットを、この記事の3つのシナリオの価格で割りました。TikHubの無料クレジットは$0.05で、料金表1,472件のうち631件（42.9%）が無料クレジットに対応しています。ドキュメントが推奨するXiaohongshuのノートエンドポイントは対応していません。このシナリオでは無料クレジットで呼び出せる回数は0回で、先に$5をチャージする必要があります。当社の$1のスタークレジットはCAPTCHAの解決以外のすべてに使えますが、24時間で有効期限が切れます。

この表は、単に「当社のトライアルのほうが手厚い」という意味ではありません。TikHubの$0.05分の無料クレジットには有効期限の記載がないため、今登録して来週テストする人に向いています。当社の$1分のトライアルクレジットは1日以内に使う必要があるため、今日中に動くフローを作りたい人に向いています。

どちらの場合も、呼び出し回数は料金によって変わります。TikHubでは、同じ$0.05でも$0.01のエンドポイントなら5回しか呼び出せず、無料クレジットを受け付けないエンドポイントでは1回も呼び出せません。当社では、TikTokプロフィールのような$0.000556の機能なら1,800回近く、Xiaohongshuのノートなら179回呼び出せます。ご自身のケースを見積もるには、カタログのprice_usdで割るか、当社のコマンドラインツールを--dry-run付きで実行してください。見積もりが表示されます。

TikHubのAPIドキュメントはどこにあるか：5つの入口と840,000トークンのファイル

TikHubのドキュメントには入口が5つあり、内容の重複も多くあります。まず、ホスティング型のAPIドキュメントツールで構築されたdocs.tikhub.ioのドキュメントサイトがあり、エンドポイントごとのページとMarkdown形式のエクスポートが用意されています。次に、api.tikhub.ioのSwaggerページでは、トークンを貼り付けてブラウザで呼び出しを試せます。メインサイトにはAPIリファレンスページとチュートリアルページがあります。さらに、AI向けのllms.txtとllms-full.txtもあります。これらはすべて1つのopenapi.jsonから生成されており、PostmanやSDKジェネレーターにインポートするのもこのファイルです。

openapi.jsonについて知っておくべき点が3つあります。1つ目に、infoブロックにはバージョンV5.3.2、更新日時2026年6月22日と記載されていますが、パス数は変わり続けています。10月3日にPython SDKが同期した時点では1,050パスでした。当社が数えたところ、2026年11月2日には1,056パス、2026年11月3日には1,058パスで、バージョン番号は変わっていませんでした。バージョン番号で仕様の変更を判断すると、判断を誤ります。

第2に、1,058個のエンドポイントのうち1,052個が、成功レスポンスを1つの汎用的なResponseModelに向けています。このモデルはcode、message、request_id、time_zone、cache_urlなどのラッパーフィールドを定義していますが、dataの型は「any」です。つまり、仕様書はリクエストの方法を示していても、どのフィールドが返るかは示していません。フィールドは呼び出してみて初めてわかります。第3に、ファイルが大きいことです。約840,000トークンあり、当社のカタログ全体（240,429トークン）の3.5倍です。AIエージェントがこれをマニュアルとして丸ごと読むことはできません。

同様のファイルサイズの問題に直面した開発者はほかにもいます。ある開発者は、TikHubのopenapi.jsonをClaude Codeのスキルに変換する方法を解説した公開ガイド（中国語）を書き、コードをGitHubで公開しています。考え方は、エンドポイントを検索するレイヤーを構築することです。そうすれば、モデルはファイル全体を読まずに、必要な部分だけを調べられます。これは、実際に需要があることを示しています。エンドポイントの数が多いサービスほど、「先に探してから呼び出す」ためのインデックスが必要になります。

TikHubの解決策は、プラットフォームごとに1つのMCPサーバーを用意するというものです。詳しくは後述します。当社の解決策は、フィルター付きのカタログです。GET /api/v1/social/catalog?platform=tiktok&compact=1は、説明を省いたTikTokのみの情報を6,809バイト、1,870トークンで返します。これはTikHubのエンドポイント1ページよりも小さいです。

ドキュメントサイトには、もう1つ小さな落とし穴があります。メニューの3番目の項目は「Getting Started」という名前ですが、これはTikHubマーケットプレイスで販売したい事業者向けのガイドです。ショップを開設し、デジタル商品を販売し、1%の出金手数料を支払う方法を説明しており、APIの呼び出しとは関係ありません。開発者向けのスタートガイドはドキュメントサイトではなく、メインサイトのtikhub.io/getting-startedにあります。「tikhub api doc」で検索してドキュメントサイトにたどり着き、メニューを順にクリックした読者は、最初に無関係なページを読むことになります。

料金表とドキュメントの食い違いも、迷う原因になります。TikHubの料金表はトークンなしで閲覧できます。シンガポール時間00:19:39の時点で1,472件、一意のパスは1,471件でした。同じ時刻のopenapi.jsonと、パスごとに照合しました。

両方にあるのが1,038パス、料金表のみにあるのが433パス、ドキュメントのみにあるのが20パスでした。料金表にのみある433件のエンドポイントには料金が設定されていますが、パラメータのドキュメントはありません。大半は旧バージョンのようですが、すべてではありません。料金のセクションで示したとおり、最も安いXiaohongshuのノートエンドポイントもその1つです。

EveryInfraは入り口が少なめです。/docsは人間向けのガイドです。機能カタログとそのコンパクト版は、プログラムやAIエージェント向けです。当社のOpenAPIファイルはバージョン2.0.0で、59パスあります。すべてのデータ機能を1つのPOST /api/v1/social経由で呼び出し、platformとactionの2つのフィールドで指定します。

ほかに25,845バイトのllms.txtがあり、TikTokプロフィールAPIのように、プラットフォームごと・機能ごとのドキュメントページもあります。カタログ内の573件の機能すべてにresponse_fieldsが記載されているため、呼び出す前にフィールド名と型を確認できます。一方、この設計には弱点もあります。573件の機能を1つのエンドポイントに集約しているため、汎用のOpenAPIジェネレーターではpost(body)メソッドが1つ生成されるだけです。パラメータ補完は当社独自のSDKに依存します。これについては次のセクションで説明します。

ドキュメントをAIエージェントに渡す：最初の呼び出しまでにどれだけ読むか

多くの開発者は、もうAPIドキュメントを自分では読みません。Claude CodeやCursorなどのコーディングエージェントに読ませて、呼び出しコードを書かせます。そうなると、ドキュメントのサイズがコンテキストの使用量とコストに直結します。そこで「TikTokのプロフィールエンドポイントを見つけ、最初のリクエストを書く」という1つのタスクを取り上げ、公開資料をもとに、両サービスで最も安く済む読み方を割り出しました。トークン数はすべて、2026年11月3日のシンガポール時間00:16〜00:23にダウンロードした元ファイルをo200k_baseでトークン化するスクリプトで算出しています。

TikHub側では、最も安く済む読み方は2段階です。エージェントはまずドキュメントサイトのllms.txtインデックス（1,274行、約47,604トークン）を読み、TikTok Webの「get user profile」エンドポイントの行を見つけます。次に、そのエンドポイントのMarkdownページ（約2,295トークン）を開きます。合計で約49,899トークンです。メインサイトのllms.txtは1,279トークンしかありませんが、記載されているのはプラットフォームとリンクで、エンドポイントではありません。そのため、エージェントは結局ドキュメントサイトに移動する必要があります。

約839,775トークンあるopenapi.jsonの全体は、どのエージェントにとっても現実的な読み物ではありません。TikHubのMCPサーバーという別のルートもあります。TikTok用のサーバーには163のツールがあるため、接続したモデルは163件のツール説明を受け取ります。一覧の取得には認証トークンが必要なため、そのサイズは計測していません。

当社側では、最も安く済む読み方は1段階です。GET /api/v1/social/catalog?platform=tiktok&compact=1で、6,809バイト、約1,870トークンです。TikTokの全機能のパラメータ、料金、レスポンスフィールド名が含まれており、リクエストを書くにはこれで十分です。この読み方では、TikHubの読み込み量は当社の約26.7倍になります。この比率は1つのエンドポイントのためにエージェントが読む量を測ったもので、ドキュメントの品質を測ったものではありません。

TikHubのエンドポイントページには、2言語の説明と詳しいパラメータ例があります。当社のコンパクト版カタログは説明を省いて名前だけを残しているため、読む量は少なくて済む一方、内容も簡素です。どちらのサービスもAI向けにllms.txtを公開しています。これはllms.txtの提案に由来する考え方で、短いMarkdownインデックスを置き、詳細はリンク先に置くというものです。両サービスともこの形式に従っています。

tikhub github：公開リポジトリ12件を1件ずつ確認

シンガポール時間00:16の時点で、TikHubのGitHub Organizationには公開リポジトリが12件ありました。GitHub APIを使って、各リポジトリのスター数と最終プッシュ日時を取得しました。続いて、SDKとプラグインのリポジトリ6件をクローンしました。スクリプトでソースコード内にハードコードされている/api/v1/...のエンドポイントパスをすべて抽出し、同日のopenapi.jsonと照合しました。

Python SDKは組織内で最もよく整備されたリポジトリで、まずこの点は評価に値します。10月2日（太平洋時間）のコミットには「sync SDK to live OpenAPI spec, skip deprecated endpoints (1048 endpoints)」とあり、翌日にはバージョン2.2.0がPyPIで公開されました。ここから抽出した1,048件のパスはすべて現在のドキュメントにも残っており、無効になったものは1つもありません。同期・非同期の両クライアント、自動リトライ、レート制限への対応を備え、mypy --strictをパスし、READMEは英語、中国語、フランス語、スペイン語、日本語で用意されています。

足りないのは、10月3日以降に追加された9つのエンドポイントだけです。内訳は、Bilibiliの投稿コメントのエンドポイント、LinkedInの非同期ジョブのエンドポイント5つ、Threadsの新しいエンドポイント2つ、TikTok Shopのベストセラーリストです。エンドポイントは月に約9つのペースで増えているため、次の同期までは常に少し遅れることになります。

ほかの4言語は大きく遅れています。TypeScript、Go、Java、C++のSDKは2025年3月にOpenAPI仕様から生成され、それ以降変更されていません。ソースに含まれる586件のパス（Goは588件）のうち、245件（Goは247件）はすでにドキュメントから消えています。これらのメソッドを呼び出すと、404などのエラーが返ります。残りの341件は、現在のエンドポイントの32.3%をカバーしています。TypeScript SDKには、さらに直接的な問題があります。

npmでのパッケージ名は@tikhubio/tikhub-api-ts-sdkで、最新バージョンは1.0.1です。しかし、npmページにある2つのインストールコマンドはどちらも@tikhub/tikhub-api-ts-sdkになっています。シンガポール時間の00:36にnpmレジストリへ問い合わせたところ、この名前は404を返したため、コマンドをそのままコピーすると失敗します。GitHubのREADMEにあるコマンドは正しいものです。

Python SDKのPyPIページには、より軽微な不備があります。「Homepage」リンクの参照先がTikHub-API-Python-SDK-V2になっており、こちらも404を返します。また、READMEのバージョン表記は2.1.1のままですが、PyPIでは2.2.0です。

ほかのリポジトリにも、それぞれ用途があります。TikHub-API-Demoには2024年12月時点のサンプルスクリプトが、Douyin、Instagram、Kuaishou、TikTok別に収められています。TikHub-Multi-Functional-DownloaderはUI付きのデスクトップ向けダウンローダーで、スター数は193とPython SDKに次いで多くなっています。tikhub-mcp-distは、MCPサーバーをローカルで動かしたい人向けです。

TikHub_n8n_Integrationはn8nにTikHubのノードを追加するもので、最後のプッシュは393日前です。TikHub自身のアカウントは、Reddit上でClaude、n8n、TikHubを組み合わせたワークフローを投稿しています。Spinneretは2026年11月2日時点でも更新が続いていますが、認証情報とプロキシをスケジューリングするためのサービスで、APIの呼び出しとは関係ありません。

「tikhub github」で検索すると、自分でホストできるオープンソースのスクレイパーも見つかります。呼び出しごとの費用はかかりませんが、リクエスト署名、プラットフォーム側の防御策への対応、バージョン更新、自前のサーバーの運用をすべて自分で行う必要があります。

言語ごとに適した選択肢

SDKのデータを選択肢に落とし込むと、答えは言語によって分かれます。Pythonの開発者には、どちらにもすぐに使えるパッケージがあります。TikHubのpip install tikhubはカバー範囲が最も広く、非同期クライアントも備えています。当社のpip install everyinfraは依存関係がなく、コマンドラインツールとコスト見積もりが付属しています。JavaScriptやTypeScriptの開発者にとって、TikHubのnpmパッケージから得られるものはあまりありません。2025年3月で更新が止まっており、カバー率は32.3%で、インストールコマンドのパッケージ名を手作業で修正する必要があります。

当社のnpmパッケージはPython版と同じ日に公開され、依存するのはNode 18以降に組み込まれたfetch関数だけです。Go、Java、C++、PHPの開発者には、どちらのサービスでも素のHTTPを使うのが最適です。TikHubのこれらの言語向けSDKは古くなっていますが、チュートリアルページにはコピーして使えるGo、Java、PHPのリクエストサンプルがあります。当社にはこれらの言語向けのSDKはありません。その代わり、すべてのデータ機能で同じPOST /api/v1/socialエンドポイントを使用します。リクエスト用の関数を1つ書けば、あとはプラットフォームごとにplatformとactionを変えるだけです。

この背景には、見落としやすい設計上の違いがあります。APIの形によって、SDKの重要度が決まるという点です。TikHubのエンドポイントはそれぞれ独自のパスと独自のパラメータ名を持つため、1,055件のエンドポイントが1,055個の関数になります。1か月遅れたSDKではエンドポイントが抜け落ち、1年半遅れたSDKではメソッドの約4割がもう動きません。保守の負担は大きく、5つのSDKのうち1つしか追随できていないのもそのためです。当社のエンドポイントは1つなので、SDKで更新が必要なのは機能名のリストだけです。

新しい機能が公開されても、古いSDKから文字列を渡せばそのまま呼び出せます。エディタで自動補完されないだけです。どちらの設計もあらゆる場面で優れているわけではありません。TikHubの設計では、型チェッカーがすべてのエンドポイントのパラメータを検査できます。当社の設計では、SDKが壊れにくくなります。

当社のサンプルコードは、公開リポジトリeveryinfra-agent-pluginsにあります。ドキュメントのプロキシの例には、2026年10月24日にドキュメントの各言語で1回ずつ実行したことが明記されています。

当社の場合：Python SDK、コマンドライン、リモートMCPサーバー

EveryInfra SDKは2026年11月1日に公開されました。PyPIのeveryinfra 0.3.0とnpmのeveryinfra 0.3.0は同じ日にリリースされました。同じファイルは、SHA-256チェックサム付きでGitHubリリースsdk-v0.3.0にもあります。このSDKはOpenAPIから生成されたものではありません。前述のとおり、573の機能が1つのエンドポイントを共有しているため、汎用のジェネレーターでは汎用メソッドが1つ生成されるだけだからです。

代わりに、バックエンドの機能レジストリからプラットフォーム名と機能名をリテラル型として生成しています。これにより、エディタで名前を自動補完でき、タイプミスもすぐに検出できます。11月3日の早朝に0.3.0をインストールして数えたところ、型の一覧には106のプラットフォームと573の機能があり、現在のカタログと1件ずつ照合した結果、過不足なく一致しました。

同じパッケージで、コマンドラインツールeveryinfraもインストールされます。everyinfra catalog --findとeveryinfra describe tiktok/profileはAPIキーなしで使え、機能、パラメータ、レスポンスフィールド、料金を表示します。--dry-runはリクエストと定価に基づく見積額を表示するだけで、何も送信しません。--max-cost-usdは、見積額が設定した上限を超える場合に送信を拒否します。

everyinfra mcp-config --client claudeは、指定したクライアント向けのMCP設定を出力します。キーを環境変数経由で参照し、ファイルには書き込みません。TikHubのSDKにはこうした機能がありません。これらは、AIエージェントに自分の代わりにAPIを呼び出させる際の3つの不安に対応しています。エージェントが誤った対象を呼び出すこと、APIを呼び出しすぎること、キーをファイルに書き込んでしまうことです。

リモートMCPについては、両サービスのアプローチが異なります。TikHubはプラットフォームごとに分けています。MCPページとllms.txtには、https://mcp.tikhub.io/tiktok/mcpのようなアドレスがプラットフォームごとに1つずつ記載されており、必要なプラットフォームごとに設定項目を1つ追加します。トークンなしで閲覧できるプラットフォーム一覧には各サーバーのツール数が載っており、Douyinは319、TikTokは163です。利点は、エンドポイントごとに独立したツールになっていることです。

欠点は、Douyinのサーバーだけで319件のツール説明がモデルに提示されることです。当社のアドレスはhttps://api.everyinfra.com/mcpの1つだけで、ツールは12個です。

データ機能はすべて、platformとactionの2つの引数を取るeveryinfra_call_apiを経由します。機能は、無料のeveryinfra_list_capabilitiesツールで先に探します。tools/listの合計は3,779トークンです。MCPの仕様はどちらの設計も認めています。現行のリビジョンは2026年7月28日付です。そのトランスポートのセクションでは、プロトコルがステートレスになっています。initializeハンドシェイクもセッションIDもありません。Streamable HTTPでは、各メッセージが同じアドレスへの1回のHTTP POSTとなり、各リクエストは_metaにプロトコルバージョンを含めます。

00:21:11に送った2件のMCPリクエストは、この方式で動作しました。ハンドシェイクなしでtools/listを送り、続けてtools/callを送ったところ、どちらも結果が返りました。認可のセクションはOAuth 2.1をベースにしていますが、認可はOPTIONAL（任意）であると明記しています。単純なキーを使う場合、クライアントがサインインフローを代わりに実行できないため、キーはご自身で貼り付ける必要があります。

どちらのサービスもOAuthは使わず、リクエストヘッダーでキーを受け取ります。設定例は次のとおりです。フィールド名はクライアントによって異なるので、各クライアントのドキュメントを確認し、キーは環境変数に保存してください。

{
  "mcpServers": {
    "everyinfra": {
      "type": "http",
      "url": "https://api.everyinfra.com/mcp",
      "headers": { "Authorization": "Bearer ${EVERYINFRA_API_KEY}" }
    }
  }
}

実際に試した3つの呼び出し：curl、Python SDK、MCP

「キーの取得から最初の呼び出しに成功するまで」を具体的に示すため、両サービスが提供している一般的なデータ取得処理を3つ選び、それぞれ異なる呼び出し方法を使いました。各呼び出しでは1つのオブジェクトを取得します。対象はTikTokのプロフィール、Douyinの動画、Xiaohongshuのノートです。当社側では tiktok/profile、douyin/video、xiaohongshu/note が該当します。TikHubのドキュメントで対応するエンドポイントは、tiktok/web/fetch_user_profile、douyin/web/fetch_one_video、そしてノート用に最初に推奨されているxiaohongshu/app_v2/get_image_note_detailです。

1つ目の呼び出しにはcurlを使いました。シンガポール時間00:18:54に送信し、30秒後にアカウント「tiktok」のデータが返りました。フォロワー96,500,000人、動画1,514本で、課金額は$0.000556です。これはTikHubのデモレスポンスにあるものと同じアカウントですが、TikHubのstatsV2が正確な数（96,519,349）を返すのに対し、当社は丸めた数値を返します。正確なフォロワー数が必要なら、この点ではTikHubのほうが優れています。

curl -X POST https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer $EVERYINFRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"platform":"tiktok","action":"profile","params":{"username":"tiktok"}}'

2回目の呼び出しにはPython SDK 0.3.0を使いました。シンガポール時間00:20:19に送信し、27.4秒後にDouyinのエアフライヤーのレビュー動画が返りました。この動画のいいね数は33,693、コメント数は2,101で、呼び出しの料金は$0.000556でした。コードは数行で、キーは環境変数から読み込みます。

import os
from everyinfra import EveryInfra
ei = EveryInfra(os.environ["EVERYINFRA_API_KEY"])
video = ei.data("douyin", "video", url="https://www.douyin.com/video/7633263781723770163")
print(video["billing"]["charged_usd"])

3つ目の呼び出しはリモートMCP経由です。シンガポール時間00:21:11に、ツールeveryinfra_call_apiに対するtools/callを送信しました。42.2秒で、2026年10月25日に投稿されたXiaohongshuのノートが返りました。いいね992件、コメント567件で、課金額は$0.005556です。result.content[0].textフィールドには、billingを含め、REST呼び出しと同じJSONが入っています。

1点、お伝えしておくべきことがあります。成功した3件の呼び出しはいずれも遅く、27〜42秒かかりました。当社の同期呼び出しには85秒の制限があり、それを超えた呼び出しはタイムアウトとして失敗し、課金されません。バッチ処理については、"mode": "async"を追加してジョブIDを取得し、後で結果を取得する方法をドキュメントで推奨しています。TikHubのトークンを持っていなかったため、同社の実際のエンドポイントの所要時間は計測できませんでした。

わかっているのは、同社のデモエンドポイントがキャッシュされた固定オブジェクトを0.65秒で返したことだけです。openapi.jsonのinfoブロックにはタイムアウト設定が30〜60秒と記載されており、30秒を超えるリクエストには独自のプロキシを使うよう勧めています。この記事では、どちらのサービスが速いかの結論は出していません。

レスポンスの読み方：データと費用の格納場所

最初の呼び出しに成功した後、次に確認すべきなのはレスポンスの解析方法です。両者のラッパーは大きく異なります。TikHubのすべてのエンドポイントは同じラッパーを使います。openapi.jsonのResponseModelとデモレスポンスを基に数えると、トップレベルのフィールドは15個あります。code、message、message_zh、request_id、support、time、time_stamp、time_zone、docs、cache_message、cache_message_zh、cache_url、router、params、dataです。データはdataに入っており、その構造はエンドポイントによって異なります。

ほとんどの場合、各プラットフォームが返すレスポンスと同じ形です。たとえばTikTokのプロフィールでは、データはdata.userInfo.userとdata.userInfo.statsの下に、そのプラットフォーム独自のcamelCase形式のフィールド名で格納されています。利点は網羅性で、プラットフォームが返したものをすべて受け取れます。その代わり、プラットフォームごと、エンドポイントのバージョンごとに専用のパーサーが必要になります。

TikHubのラッパーには、呼び出し費用の情報が含まれていません。ドキュメントによると、呼び出しは200を返した時点で課金されます。使用額を確認するには、同社のユーザー用エンドポイントを呼び出します。ドキュメントサイトのTikHub-User-APIグループには、日次の使用量を取得するものと料金を計算するものがあります。EveryInfraのラッパーにはid、platform、action、results、billing、quotaがあります。

resultsフィールドでは、カタログのresponse_fieldsにあるフィールド名を使います。TikTokのプロフィールならusername、follower_count、video_countです。billing.charged_usdはこの呼び出しに実際にかかった米ドル建ての金額、balance_after_usdは呼び出し後の残高です。バッチではcharged_usdを合計すれば総額がわかります。この記事の3件の呼び出しの費用も、この方法で確認しました。

料金の簡単な比較

価格については2本の記事で詳しく扱っているため、ここでは3つのシナリオを並べるだけにします。どのシナリオも1つのオブジェクトを読み取るため、1,000回の呼び出しあたりの価格と1,000件の結果あたりの価格は同じ数値になります。

定価では、3つのシナリオすべてでTikHubの料金は当社の1.8倍で、当社は約44%安くなります。これは当社カタログの$0.000556の価格帯と一致します。TikHubのほうが安くなるケースは2つあります。第1に、呼び出し量が多い場合です。TikHubのllms.txtには日次の割引段階が記載されており、1日30,000回を超えると半額になります。TikTokプロフィールのエンドポイントは割引対象なので、最上位の段階では1,000回あたり$0.50となり、当社の$0.556を下回ります。

第2に、ドキュメントにないエンドポイントを使う場合です。TikHubの料金表には、1回の呼び出しあたり$0.001のv5 Xiaohongshuノートエンドポイントがあります。これはドキュメントが推奨するapp V2エンドポイントの10分の1で、当社の価格はこのエンドポイントの5.6倍です。ただし、v5はopenapi.jsonに含まれていないためパラメータのドキュメントがなく、どれだけ安定しているかも判断できません。価格の全体比較は、TikHubの料金を解説とDouyinの37機能を1つずつ価格比較をご覧ください。

最初の請求額には、失敗した呼び出しも含めて考えるべきです。APIを学んでいる間は、たいてい失敗が多くなります。シンガポール時間00:18:54のキーなしの呼び出しと、00:19:24のパラメータを間違えた呼び出しは、どちらもエラーを返し、charged_usdは0でした。当社は課金前にパラメータを検証するため、名前のスペルミスで課金されてから返金されることはありません。TikHubのFAQには、「成功したリクエストのみ」に課金すると書かれています。200を返したリクエストが課金対象で、失敗したリクエストは課金されません。価格は1リクエストあたり$0.001〜$0.01です。

このルールに従えば、TikHubでも401、403、422のエラーは無料のはずですが、APIキーがないため検証はできませんでした。本当の違いは「200なのにデータがない」場合です。当社は空の結果を同じcharge_idで返金します。TikHubには空の結果の返金について説明したページが見つからず、返金ポリシーにはチャージは返金不可と書かれています。

そのため、AIエージェントがパラメータを試している間にエラーになった呼び出しは、どちらのサービスでもおそらく料金がかかりません。差が出るのは、成功しても中身が空の呼び出しです。たとえば、名前が変わったアカウントや削除された動画が該当します。プラットフォームはそれでも200を返すためです。バッチにこうした対象が多いほど、2つの請求額の差は開きます。

TikHubのほうが適している場合

このセクションがなければ、ここまでの比較は公平とはいえません。以下の各行は、すべて本記事で引用した公開資料に基づいています。

TikHubには、当社にはない設計がもう1つあります。成功したレスポンスにはそれぞれcache_urlが含まれ、その呼び出しの生のJSONを24時間無料で再取得できます。TikHubのチュートリアルページによると、これによりパースのバグがあっても2回目の呼び出しの料金はかかりません。チームメンバーが同じ結果を再現することもできます。当社ではrequest_idで呼び出し記録とその課金額を確認できますが、当時のレスポンス全体は確認できません。

逆に当社は、失敗した呼び出しや空の結果を自動で返金し、呼び出し前にレスポンスフィールドを確認できます。さらに、各キーでプロダクトごとに有効・無効を切り替えられ、送信前にコストを見積もれます。対応範囲も広く、当社のカタログにある106のプラットフォームには、ソーシャルメディアに加えてEC、ローカルレビュー、地図、求人サイトも含まれます。TikHubのMCPプラットフォーム一覧は、15のプラットフォームと「Others」グループです。最新の一覧はカタログで確認してください。

状況に応じた選び方

ここまでの比較を、いくつかの判断基準にまとめます。まず、Pythonを使うと決めていて、TikHubの1,055件のうちXingtuやDouyin Indexのようなごく特定のエンドポイントが必要な場合です。それぞれにパーサーを書けるなら、TikHubのPython SDKがすぐに使える選択肢になります。ドキュメントの量は多いものの、各エンドポイントのページは詳細です。

第2に、JavaScript、Go、Javaで開発する場合、TikHubのSDKはあまり役に立たず、どちらのサービスでもHTTPリクエストを自分で送ることになります。違いは、最初にどれだけ読む必要があるかです。当社のプラットフォーム別カタログは約1,870トークンで、呼び出し前にレスポンスフィールドがわかります。第3に、AIエージェントに呼び出しを任せるなら、特に重要な問いが3つあります。

パラメータと価格を事前に調べられるか。間違った呼び出しに料金がかかるか。キーがファイルに漏れるおそれはないか。

当社のテストでは、401と422のレスポンスは課金されず、次に何をすべきかをエージェントに示しました。当社のCLIでは、送信前にコストを見積もることもできます。TikHubのデモエンドポイントでは、エージェントが最初に実際のレスポンスを1件確認でき、401レスポンスには標準のヘッダーが含まれます。4つ目は、割引対象の1つのエンドポイントを1日に数万回呼び出す場合です。

あるいは、料金は設定されているもののドキュメントがないエンドポイントでも構わない場合です。どちらの場合も、TikHubの単価のほうが安くなることがあります。決める前に、TikHubの料金表で試算してください。

最近の変更（2026年10月〜11月）

• 2026年11月3日：TikHubのopenapi.jsonのパス数は1,058で、11月2日より2つ増えましたが、バージョン表記はV5.3.2のままです。影響：このファイルからSDKを生成・同期する場合は、変更を検出する際にバージョン番号に頼らないでください。
• 2026年11月1日：EveryInfraのPython SDK 0.3.0とnpm SDK 0.3.0がリリースされ、同日にカタログの対応プラットフォーム数が91から106に増えました。影響：SDKの型リストを最新のカタログと照合してください。当社のテストでは、このバージョンの型リストはカタログと一致していました。
• 2026年10月28日：GitHubのプッシュ保護で、AIが検出したシークレットをブロックできるようになりました。この機能はパブリックプレビューで、デフォルトでは無効です。Secret ProtectionまたはAdvanced Securityを利用している組織のみが対象です。影響：固定形式のないAPIキーも、プッシュ時にブロックできるようになりました。ただし、組織がこの機能を有効にする必要があります。個人リポジトリでは、引き続きAPIキーをリポジトリに含めないよう自分で管理する必要があります。
• 2026年10月20日：GitHubのシークレットスキャン用カスタムパターンAPIが、不正な引数に対して500ではなく422を返すようになりました。呼び出し側は、入力エラーとサーバーエラーを区別できるようになりました。影響：TikHubでも当社のAPIでも、リトライは同じ方針で実装してください。4xxではリクエストを修正し、リトライは5xxの場合のみにします。どちらのサービスも、不正なパラメータには422を返します。
• 2026年10月13日：GitHubが新しいシークレット検出モデルについて説明しました。まず正規表現ルールで候補を集め、次に小型モデルがファイルパス、変数名、周辺のコードを読み取ります。ユーザーの承認率は11.5%向上し、スキャン時間の中央値は86%短縮されました。影響：固定のプレフィックスがないキーも検出しやすくなっています。ただし、最も安全なのは、やはりリポジトリに一度も入れないキーです。

FAQ

質問は、これらのキーワードに対するGoogle検索の候補とフォーラムの投稿から集めたもので、2026年11月3日に確認しました。各回答には出典を記載しています。

TikHub APIキーはどこで作成できますか？

user.tikhub.ioにログインし、ユーザーセンターを開いて、APIトークンメニューでトークンを作成します。手順はドキュメントREADMEの「Get API Token」セクションに記載されています（検索候補：「tikhub api key」「tikhub api token」）。先にメールアドレスの確認を済ませてください。未確認の場合、API呼び出しは403エラーになります。ユーザー1人あたり最大100個のAPIキーを作成できます。ai.tikhub.ioのAIプロキシ用APIキーは別体系で、データエンドポイントへのアクセスには使用できません。

TikHubのAPIドキュメントサイトとSwaggerの違いは何ですか？

どちらも同じopenapi.jsonを表示しています（検索候補：「tikhub api doc」「api tikhub io」）。docs.tikhub.ioはエンドポイントごとに1ページあり、パラメータを調べるのに最適です。api.tikhub.ioはSwaggerのページで、トークンを貼り付けて呼び出しを試せます。トークンは「Bearer」プレフィックスなしで貼り付けてください。どちらにも、ほとんどのエンドポイントのレスポンスフィールドは載っていません。1,052個のエンドポイントでは汎用ラッパーしかドキュメント化されていないため、フィールドは実際に呼び出して確認することになります。

TikHubのGitHubにあるSDKで、今も使えるものはどれですか？

Python SDKです（検索候補：「tikhub github」「tiktok api python github」）。10月3日公開のバージョン2.2.0は、現在のエンドポイントの99.2%をカバーしています。TypeScript、Go、Java、C++のSDKは2025年3月から更新がなく、カバー率は32.3%です。また、ドキュメントから削除されたエンドポイントを呼ぶメソッドが245個含まれています。これらの言語では、SDKを使わずHTTPで直接呼び出すほうが安全です。

Pythonの例が載ったTikTok APIのドキュメントはありますか？

はい、どちらにもあります（検索候補：「tiktok api documentation python」）。TikHubのチュートリアルページにはPython、JavaScript、Go、Java、PHP、cURLのサンプルがあり、Python SDKのREADMEではリソース名による呼び出し方を紹介しています。当社のドキュメントにはcurlの例があり、pip install everyinfraで型付きのクライアントを利用できます。最初の呼び出しは、上記の短い例だけで完結します。

TikTokにAPIはありますか？無料のTikTok APIキーはありますか？

TikTokには独自のAPIがありますが、制限があります（検索候補：「does tiktok have an api」「tiktok api key free」）。2026年8月4日に更新されたDisplay APIで読み取れるのは、アプリを承認したユーザーのプロフィールと動画のみです。Research APIは、要件を満たす研究機関からの申請が必要です。公開アカウントや他人の動画を取得するには、サードパーティのAPIが必要です。多くのサービスでは少額のトライアルクレジットを提供しています。TikHubは$0.05を付与し、当社は2つのリポジトリにスターを付けると$1を付与します（有効期限24時間）。

TikHubはClaudeやn8nで使えますか？

はい。TikHubはプラットフォームごとにMCPサーバーを提供しており、Claude Codeプラグインのリポジトリとn8n連携のリポジトリもあります（出典：TikHubのMCPページとGitHub）。TikHub自身のアカウントもRedditにClaude、n8n、TikHubを使ったワークフローを投稿しています。なお、n8nのリポジトリは最終プッシュが393日前です。当社のリモートMCPサーバーは、ヘッダー付きのリモートMCPに対応したあらゆるクライアントで動作し、必要なのは上記の設定例だけです。

TikHubは信頼できるサービスですか？

Redditユーザーが「Is TikHub AI legit」と質問したr/Seedance_AIのスレッドでは、返信から明確な答えは得られませんでした。TikHubのチュートリアルページには、提供するのは公開データのみで、データを所有しているわけではないと書かれています。返金ポリシーでは、エンドポイントが実際に機能しない場合を除き、購入後の返金には応じないとしています。当社はTikHubのコンプライアンスについて判断しません。まずデモエンドポイントと$0.05のクレジットを試してから、チャージ額を決めることをおすすめします。

始め方

1. 機能カタログまたはインフラマーケットプレイスで、必要な機能を探します。例：tiktok/profile。パラメータ、レスポンスフィールド、料金を確認します。APIキーは不要です。
2. 新規登録して、コンソールでAPIキーを作成します。APIキー全体が表示されるのは一度だけなので、環境変数EVERYINFRA_API_KEYに保存してください。
3. ドキュメントのクイックスタートにあるcurlの例で、最初のリクエストを送信します。pip install everyinfraを実行してSDKを使うことも、上記のMCP設定をクライアントに貼り付けることもできます。レスポンスのbilling.charged_usdを確認してください。
4. 401または422が返ってきた場合は、まずレスポンスのnext_stepsを確認してください。ほかのプラットフォームについては、TikTok、Douyin、Xiaohongshuの各ページとMCPセットアップガイドをご覧ください。

参考文献

1. Getting Started: First API Call in 4 Steps、TikHub、2026-11-03閲覧、https://tikhub.io/getting-started
2. Social Media API Tutorials and Code Examples、TikHub、2026-11-03閲覧、https://tikhub.io/tutorials
3. Pricing、TikHub、2026-11-03閲覧、https://tikhub.io/pricing
4. FAQ: Billing, Rate Limits and Platform Support、TikHub、2026-11-03閲覧、https://tikhub.io/faq
5. llms.txt、TikHub、2026-11-03閲覧、https://tikhub.io/llms.txt
6. llms-full.txt、TikHub、2026-11-03閲覧、https://tikhub.io/llms-full.txt
7. MCP Integration Guide、TikHub、2026-11-03閲覧、https://tikhub.io/mcp
8. Social Media API Reference、TikHub、2026-11-03閲覧、https://tikhub.io/api-reference
9. README - English、TikHubドキュメントサイト、2026-11-03閲覧、https://docs.tikhub.io/4592766m0
10. README（中国語版）、TikHubドキュメントサイト、2026-11-03閲覧、https://docs.tikhub.io/4579297m0
11. Getting Started（販売者向けオンボーディング）、TikHubドキュメントサイト、2026-11-03閲覧、https://docs.tikhub.io/5432442m0
12. llms.txt（ドキュメントサイトのインデックス）、TikHubドキュメントサイト、2026-11-03閲覧、https://docs.tikhub.io/llms.txt
13. Get user profile (TikTok Web API)、TikHubドキュメントサイト、2026-11-03閲覧、https://docs.tikhub.io/186826057e0
14. Demo: fixed TikTok user、TikHubドキュメントサイト、2026-11-03閲覧、https://docs.tikhub.io/337619232e0
15. Get all endpoints information、TikHubドキュメントサイト、2026-11-03閲覧、https://docs.tikhub.io/186826055e0
16. About TikHub AI API、TikHubドキュメントサイト、2026-11-03閲覧、https://docs.tikhub.io/7781112m0
17. TikHub Refund Policy（2026-07-20更新）、TikHubドキュメントサイト、2026-11-03閲覧、https://docs.tikhub.io/9453198m0
18. openapi.json（V5.3.2）、TikHub、2026-11-03閲覧、https://api.tikhub.io/openapi.json
19. Swagger UI、TikHub、2026-11-03閲覧、https://api.tikhub.io/
20. 料金一覧エンドポイント get_all_endpoints_info、TikHub、2026-11-03閲覧、https://api.tikhub.io/api/v1/tikhub/user/get_all_endpoints_info
21. デモエンドポイント demo/tiktok/web/fetch_user_profile、TikHub、2026-11-03閲覧、https://api.tikhub.io/api/v1/demo/tiktok/web/fetch_user_profile
22. MCPプラットフォーム一覧、TikHub、2026-11-03閲覧、https://mcp.tikhub.io/platforms
23. TikHubのGitHub Organization、GitHub、2026-11-03閲覧、https://github.com/TikHub
24. TikHub-API-Python-SDK、GitHub、2026-11-03閲覧、https://github.com/TikHub/TikHub-API-Python-SDK
25. コミットc4620078：SDKを公開中のOpenAPI仕様に同期（1048エンドポイント）、GitHub、2026-10-02、https://github.com/TikHub/TikHub-API-Python-SDK/commit/c4620078fa6930380c6c2a0a51597718c762e27a
26. TikHub-API-TypeScript-SDK、GitHub、2025-03-17、https://github.com/TikHub/TikHub-API-TypeScript-SDK
27. TikHub-API-GoLang-SDK、GitHub、2025-03-09、https://github.com/TikHub/TikHub-API-GoLang-SDK
28. TikHub-API-Java-SDK、GitHub、2025-03-09、https://github.com/TikHub/TikHub-API-Java-SDK
29. TikHub-API-CPP-SDK、GitHub、2025-03-09、https://github.com/TikHub/TikHub-API-CPP-SDK
30. TikHub-API-Demo、GitHub、2024-12-02、https://github.com/TikHub/TikHub-API-Demo
31. tikhub-plugin、GitHub、2026-06-16、https://github.com/TikHub/tikhub-plugin
32. tikhub-mcp-dist、GitHub、2025-09-23、https://github.com/TikHub/tikhub-mcp-dist
33. TikHub_n8n_Integration、GitHub、2025-10-05、https://github.com/TikHub/TikHub_n8n_Integration
34. TikHub-Multi-Functional-Downloader、GitHub、2025-03-18、https://github.com/TikHub/TikHub-Multi-Functional-Downloader
35. Spinneret、GitHub、2026-11-02、https://github.com/TikHub/Spinneret
36. tikhub_api_skill、GitHub、2026-11-03閲覧、https://github.com/liangdabiao/tikhub_api_skill
37. tikhub 2.2.0、PyPI、2026-10-03、https://pypi.org/project/tikhub/
38. @tikhubio/tikhub-api-ts-sdk, npm, read 2026-11-03, https://www.npmjs.com/package/@tikhubio/tikhub-api-ts-sdk
39. EveryInfra機能カタログ、EveryInfra、2026-11-03閲覧、https://api.everyinfra.com/api/v1/social/catalog
40. EveryInfra機能カタログ、compact=1、EveryInfra、2026-11-03閲覧、https://api.everyinfra.com/api/v1/social/catalog?compact=1
41. EveryInfra OpenAPI 2.0.0、EveryInfra、2026-11-03閲覧、https://api.everyinfra.com/openapi.json
42. EveryInfra llms.txt、EveryInfra、2026-11-03閲覧、https://api.everyinfra.com/llms.txt
43. everyinfra 0.3.0、PyPI、2026-11-01、https://pypi.org/project/everyinfra/
44. everyinfra 0.3.0、npm、2026-11-01、https://www.npmjs.com/package/everyinfra
45. everyinfra-agent-pluginsのリリースsdk-v0.3.0、GitHub、2026-11-01、https://github.com/everyinfra/everyinfra-agent-plugins/releases/tag/sdk-v0.3.0
46. everyinfra-agent-plugins、GitHub、2026-11-03閲覧、https://github.com/everyinfra/everyinfra-agent-plugins
47. RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage、IETF、2012-10、https://datatracker.ietf.org/doc/html/rfc6750
48. RFC 9110: HTTP Semantics、IETF、2022-06、https://www.rfc-editor.org/rfc/rfc9110.html
49. MCP仕様：Transports（2026-07-28）、Model Context Protocol、2026-11-03閲覧、https://modelcontextprotocol.io/specification/2026-07-28/basic/transports
50. MCP仕様：Authorization（2026-07-28）、Model Context Protocol、2026-11-03閲覧、https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
51. /llms.txtファイルの提案、llmstxt.org、2026-11-03閲覧、https://llmstxt.org/
52. About secret scanning、GitHub Docs、2026-11-03閲覧、https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning
53. Display API Overview（2026-08-04更新）、TikTok for Developers、https://developers.tiktok.com/doc/display-api-overview
54. Research API：アクセスと利用資格、TikTok for Developers、2026-11-03閲覧、https://developers.tiktok.com/products/research-api/
55. DIY：APIドキュメント全体をClaude Codeのスキルにする（中国語）、Juejin、2026-11-03閲覧、https://juejin.cn/post/7595096774546096137
56. Is TikHub AI legit and works?、Reddit r/Seedance_AI、2026-11-03閲覧、https://www.reddit.com/r/Seedance_AI/comments/1u2gjmx/is_tikhub_ai_legit_and_works_seems_very_cheap_for/
57. Day 1 on TikTok: Claude, TikHub API and n8n workflow、Reddit r/ClaudeAI、2026-11-03閲覧、https://www.reddit.com/r/ClaudeAI/comments/1levnmu/day_1_on_tiktok_400_likes_90_saves_on_first_video/
58. Supported secret scanning patterns、GitHub Docs、2026-11-03閲覧、https://docs.github.com/en/code-security/secret-scanning/introduction/supported-secret-scanning-patterns
59. 定義済みのシークレットパターン以外にも対応するプッシュ保護、GitHub Changelog、2026-10-28、https://github.blog/changelog/2026-10-28-push-protection-beyond-predefined-secret-patterns/
60. Updates to GitHub secret scanning、GitHub Changelog、2026-10-20、https://github.blog/changelog/2026-10-20-updates-to-github-secret-scanning/
61. GitHubのシークレット検出モデル：ノイズを抑えてより多くのシークレットを検出、GitHub Blog、2026-10-13、https://github.blog/ai-and-ml/githubs-model-for-secret-detection-finding-more-secrets-with-less-noise/