TikHub API Key、文档与 GitHub 上手实测

2026 年 11 月 3 日我们把 TikHub 公开的文档、GitHub 仓库和 SDK 逐个下载下来对照：它的 openapi.json 有 1,058 个接口路径、3.1 MB，按 o200k 分词约 84 万 token，1,052 个接口的返回结构只写了一个不带字段的通用外壳；GitHub 上 TypeScript、Go、Java、C++ 四个 SDK 最后一次提交在 2025 年 3 月，源码里 586 个接口路径有 245 个已经不在今天的文档里，只覆盖当前 1,055 个未弃用接口的 32.3%。只有 Python SDK 跟得上（覆盖 99.2%，10 月 3 日发的 2.2.0），但它也已经漏了之后新增的 9 个接口。同一天我们用 EveryInfra 的 curl、Python SDK 和远程 MCP 各调一次 TikTok 主页、抖音作品和小红书笔记，三次一共扣 $0.006668，按标价算 TikHub 是我们的 1.8 倍（我们低约 44%）；但它的小红书 v5 接口和量大折扣更便宜，后面照实写。

先说本文和站内另外三篇 TikHub 文章的分工。TikHub 替代方案比的是整体能力和价格，TikHub pricing 详解拆的是它 1,470 行价目和免费额度，TikHub 抖音 API 替代逐项比了 37 项抖音能力，总览在 /alternatives/tikhub。本篇只回答搜「tikhub api key」「tikhub api doc」「tikhub github」的人真正想知道的事：Key 在哪拿、怎么鉴权、文档在哪、GitHub 上的 SDK 和示例还能不能用、从注册到第一次成功调用要走几步。价格只在最后算一小笔账。TikHub 一侧只用公开材料：它的定价页、上手页、文档站、openapi.json、不带 Key 就能读的价目接口和演示接口、GitHub 公开仓库和 PyPI、npm 页面，读取时间是 2026 年 11 月 3 日 00:15–00:37（新加坡时间）；我们没有注册 TikHub，也没有调用它的付费接口。EveryInfra 一侧全部是同一时段的真调。

tikhub api key 怎么拿：两边各要几个动作

搜「tikhub api key」的人，第一个问题是 Key 在哪拿。TikHub 的上手页标题是「First API Call in 4 Steps」，四步是：注册并验证邮箱、浏览 API 市场看每个接口的价格和能不能用免费额度、给付费接口充值、开始写代码。我们逐字读了一遍，这四步里没有「创建 API Key」这个动作。建 Key 的说明在它文档站的 README - English 末尾「Get API Token」一节：登录后进用户中心，点 API token 菜单，创建 token，再复制到请求头里。中文版 自述文档 写法相同。也就是说，只看上手页的人走完四步还不知道 Key 在哪，要再翻到文档 README 的最后才找得到。

邮箱验证不是可有可无。TikHub 的教程与常见问题页写得很清楚：返回 403 的原因之一就是「email is not verified」，同一页还写了每个用户最多可以建 100 把 API Key，适合给不同项目分开用。免费额度按定价页的说法是新账户自动送 $0.05，约 50 次请求，每人只送一次，删过号再注册不再送；但「不是每个接口都接受免费额度」，只收付费余额的接口要先充值。充值最低 $5，可以用 PayPal、支付宝（单日上限 $250）和 USDT（要另付链上手续费）。退款政策（2026 年 7 月 20 日更新）写的是「All Sales Are Final」，只有接口确实不可用、并经它的技术团队确认时才退。

还有一个容易混的地方：TikHub 有两种 Key。社交数据接口的 Key 在 user.tikhub.io 的用户中心建；它另有一个测试中的 AI 代理服务，文档写明要去 ai.tikhub.io 单独注册、在那里的控制台拿 Key，而且这个 AI 代理「不兼容官方 SDK」，只能直接发 HTTP 请求。搜「tikhub api key」落到 AI 代理那一页的人，拿到的 Key 调不了数据接口，反过来也一样。

EveryInfra 这边也是四个动作。登录页上可以用 GitHub、Google、手机号或邮箱注册；进控制台在「API Keys」里建 Key，完整 Key 只在创建时显示一次；然后把它放进 Authorization: Bearer 头发请求。要先试用，可以在 GitHub 给两个仓库点星，在控制台领 $1 额度，24 小时内有效，能调多少次按单价算（下文「免费额度」一节有三个场景的次数）；不想点星就直接充值，定价页上最小的充值档是 $10。和 TikHub 比，我们少一个「验证邮箱」的动作，但起步充值额是它的两倍，这一点 TikHub 更友好。

这张表里对多数人影响最大的是第三、四行。TikHub 允许一个人建 100 把 Key，这对按项目分账很方便，但它的公开文档没有说一把 Key 能不能限制只调某些接口，只在状态码说明里出现过「API token lacks required permissions」。我们的 Key 可以在控制台按产品拉闸：只给 AI 代理开数据接口、不给它开验证码，或者把一把 Key 停用，调用就返回 401。改 Key、改权限、付款这几件事永远只能人登录控制台做，经 Key 新建的 Key 不会比原来那把更宽，这是为了让 AI 代理拿着 Key 也改不了账户。

鉴权：Bearer 头、Cookie 和网址里的 Key

两边都用 Authorization: Bearer <Key>。这是 RFC 6750 定义的写法，同一份标准第 2.3 节写明把令牌放进网址查询参数「SHOULD NOT be used」，第 5.3 节又写了两条：不要把 bearer 令牌放在页面网址里，因为浏览器历史和服务器日志都可能留下；也不要把它存进可以明文发送的 Cookie。TikHub 的 README 给了两种方法：方法一是请求头（推荐），方法二是放进名为 Authorization 的 Cookie，写明「不推荐，只在方法一不可用时用」。它在 Swagger 页面上还有一个细节：点右上角 Authorize 时只填 token，不要带 Bearer 前缀，前缀由页面自己加。

鉴权失败时返回什么，比文档写了什么更能说明问题，因为 AI 代理遇到错误时只看得到返回体。我们在 00:19:39（新加坡时间）不带 Key 请求 TikHub 的 TikTok 主页接口，0.21 秒返回 401，响应头里带 WWW-Authenticate: Bearer，这符合 RFC 9110 第 15.5.2 节对 401 的要求；返回体里 message 指向 README 的「api-token-introduction」锚点，还给了一段中文 message_zh 和 Discord 地址，docs 字段是 null，时间按洛杉矶时区给。同一时刻我们不带 Key 请求 EveryInfra，返回 401 和 missing_key，带 fault: account、retryable: false，next_steps 写的是把 Key 放进 Authorization 头，并明说「Nothing was charged」。我们这边的响应头里没有 WWW-Authenticate，这一点 TikHub 做得更标准。

参数写错是更常见的情况。00:19:24 我们故意把 tiktok/profile 的 username 写成 user，EveryInfra 返回 422 missing_param，告诉你缺的是 username、user 不是这个能力的参数，并附一个能直接跑的示例和这个平台的目录地址。TikHub 的 openapi.json 里有 973 个接口声明了 422 校验错误，返回格式是框架默认的字段校验信息；我们没有它的 Key，没能看到它对一个写错参数名的请求实际怎么回，这一点只能写到这里。

Key 放在哪：环境变量和密钥扫描

拿到 Key 之后，最常见的事故不是被人猜中，而是自己把它贴进了代码仓、截图或者对话。GitHub 的支持模式列表把密钥扫描规则分成三类：通用规则、AI 检测和服务商规则，11 月 3 日我们读到的服务商规则共 531 条。和本文关系最大的是通用规则里的 http_bearer_authentication_header：它找的正是写死在代码里的 Authorization: Bearer … 请求头，GitHub 给它标的精度是「中」。把 Key 连同请求头一起提交，有机会被它认出来；但扫描到之后，只有加入 GitHub 合作计划的服务商才会收到通知、替你作废这把 Key，其他情况要你自己去控制台停用。10 月 28 日GitHub 又把 AI 检测接进了推送拦截（push protection）：不看固定格式，按变量名、文件路径和上下文判断一段字符是不是密钥，早期结果里被拦下的推送数量翻了一倍多。不过它默认关闭，要先开 AI 检测和推送拦截，只对买了 Secret Protection 或 Advanced Security 的组织开放，还按 AI 额度另算费用。对多数个人开发者，最稳的仍是三条：Key 只放环境变量或客户端的密钥配置；MCP 配置里写 ${EVERYINFRA_API_KEY} 这样的引用，不写明文；每个项目单独一把 Key，出事只停那一把。TikHub 允许每人 100 把 Key，单独一把很容易做到；我们的控制台也能建多把，并且可以给每把设 IP 白名单、关掉用不到的产品。

两家都还保留了一种不太安全的传法。TikHub 支持把 token 放进名为 Authorization 的 Cookie，它自己也标了「不推荐」；RFC 6750 第 5.3 节的说法是，令牌如果存进 Cookie，必须防跨站请求伪造，而且不能用可以明文发送的 Cookie。我们这边是早期的 MCP 连接器允许把 Key 写在网址参数里，/docs 写明「还能用，但网址容易留在历史和日志里，新接入请不要用」，AI 接口则直接拒绝网址里的 Key。RFC 6750 对网址传令牌的要求是「SHOULD NOT」，两家现在推荐的写法都是请求头，这一点一致。

不带 Key 能先做什么

在决定注册之前，两边都允许先摸一摸。TikHub 有 8 个「Demo」演示接口（文档站列了 9 项，另一项是看演示缓存状态），不用 token，返回固定对象、缓存 1 小时：抖音 Web 和 App 各一个固定作品、抖音综合搜索、快手固定视频、TikTok 固定用户和 App 固定视频、Instagram 固定用户、微信公众号文章提取。我们在 00:19:38 调了 TikTok 固定用户那个，0.65 秒返回 200，内容是 tiktok 官方账号，粉丝数 96,500,000、作品 1,514 个，statsV2 里还有精确到个位的 96,519,349。这是一个很好的设计：没有 Key 也能看到真实的返回结构。有一处让人困惑：这个免费演示接口返回的 message 是「Request successful. This request will incur a charge.」，中文版是「本次请求将被计费」，可我们根本没带 token，不可能被计费。原因是它所有接口共用一个返回模型，这句话是模型的默认值。

EveryInfra 没有演示接口，但能力目录、搜索工具目录、验证码类型目录和 MCP 的 tools/list 都不用 Key。目录里每项能力写了必填和可选参数、单次条数上限、price_usd、available 和 response_fields，也就是说不调也能知道会回哪些字段、要花多少钱。00:21:11 我们不带 Key 请求 https://api.everyinfra.com/mcp 的 tools/list，返回 12 个工具。两种做法各有长处：TikHub 的演示让你看到一次真实返回长什么样，我们的目录让你在调用前就知道每个字段名和价钱。

免费额度够试几次

「有没有免费额度」之后，真正要问的是「够我把要用的接口各试几次」。我们把两边的试用额度按本文三个场景的单价折算了一遍。TikHub 送 $0.05，价目里 1,472 行接口有 631 行（42.9%）接受免费额度；它文档推荐的小红书笔记接口不接受，所以这个场景用免费额度一次也调不了，要先充值 $5。EveryInfra 点星领 $1，只要不是验证码识别都能用，但 24 小时内要用完。

这张表的意思不是「我们的试用更大方」这么简单。TikHub 的 $0.05 不限时，适合先注册、过几天再慢慢试；我们的 $1 要在 24 小时内用完，适合当天就要跑通一个流程的人。两边的次数都随接口单价变：TikHub 一侧，同样 $0.05，碰上每次 $0.01 的接口只够 5 次，碰上不接受免费额度的接口一次也没有；我们这边，TikTok 和抖音这类 $0.000556 一次的能力能调近 1,800 次，小红书笔记单价高，就只有 179 次。真要估自己的场景，用目录里的 price_usd 去除就行，命令行的 --dry-run 也会直接给出估价。

tikhub api doc 在哪：五个入口和一份 84 万 token 的接口文件

TikHub 的文档有五个入口，内容大量重叠：文档站 docs.tikhub.io（用 Apifox 搭的，每个接口一页，也能导出 Markdown）、api.tikhub.io 上的 Swagger 页面（可以在浏览器里填 token 直接试调）、官网的 API 参考页、教程页，以及给 AI 读的 llms.txt 和 llms-full.txt。这些入口的底稿是同一份 openapi.json。

openapi.json 本身有三个值得注意的地方。第一，它的 info 里写着版本 V5.3.2、更新时间 2026-06-22，但路径数在变：10 月 3 日 Python SDK 同步时是 1,050 个，11 月 2 日我们读到 1,056 个，11 月 3 日是 1,058 个，版本号没有跟着改。用版本号判断「文档有没有更新」会判错。第二，1,058 个接口里有 1,052 个的成功返回只引用了一个通用的 ResponseModel：它定义了 code、message、request_id、time_zone、cache_url 这些外壳字段，data 的类型是「任意」。换句话说，文档告诉你怎么问，但没告诉你会回哪些字段，字段要靠实际调一次去看。第三，文件太大：按 o200k 分词约 84 万 token，是我们整份能力目录 240,429 token 的 3.5 倍，不可能整份塞给一个 AI 代理当说明书。

掘金上有开发者专门写过一篇把 TikHub 的 openapi.json 做成 Claude Code 技能的文章，代码放在 GitHub，思路就是先给接口建一个搜索层，让模型按需查，而不是整份读。这说明问题是真实存在的：接口越多，越需要一个「先找再调」的目录。TikHub 官方给的办法是按平台拆 MCP 服务（下文细说），我们给的办法是能力目录加查询参数：GET /api/v1/social/catalog?platform=tiktok&compact=1 只回 TikTok 一个平台、去掉说明文字，6,809 字节、1,870 token，比 TikHub 单个接口的文档页还小。

TikHub 文档站还有一个小坑。它的目录第三项叫「⚡ Getting Started」，点进去讲的却是商家入驻：怎么在 TikHub 商城开店、卖数字商品、平台抽 1% 提现费，和调 API 无关。真正给开发者的上手页在官网 tikhub.io/getting-started，不在文档站。搜「tikhub api doc」落到文档站的人，按目录顺序点，会先读到一篇和自己无关的内容。

价目和文档对不上，是另一类找不到的问题。TikHub 的价目接口不带 token 也能读，我们在 00:19:39 读到 1,472 行（1,471 个不重复路径），和同时刻的 openapi.json 逐条比对：1,038 个两边都有，433 个只在价目里，20 个只在文档里。只在价目里的接口有价格但查不到参数说明，多数是旧版本，但不全是旧的：后面价格一节会讲到，小红书笔记最便宜的那个接口就只在价目里。

EveryInfra 的文档入口少一些：/docs 是给人读的总文档，能力目录和 compact 版是给程序和 AI 读的，OpenAPI 是 2.0.0 版、59 个路径，因为数据能力全部走同一个 POST /api/v1/social，用 platform 和 action 两个字段区分；还有给 AI 的 llms.txt（25,845 字节）和每个平台、每项能力各一页的接口文档，例如 TikTok 主页接口。目录里 573 项能力全部带 response_fields，字段名和类型在调用前就能看到。我们的短处也要说：OpenAPI 只有 59 个路径，因为 573 项能力挤在一个端点里，用通用的 OpenAPI 生成器生成 SDK，得到的只是一个 post(body)，参数补全要靠我们自己的 SDK，下一节讲。

把文档交给 AI 代理：第一次调用前要读多少

现在很多人不是自己读文档，而是让 Claude Code、Cursor 这类编码代理去读，再让它写调用代码。这时文档的大小直接变成上下文占用和费用，所以我们把「找到 TikTok 主页接口并写出第一个请求」这件事，按两边公开的材料各算了一遍最省的读法。所有 token 数都由脚本用 o200k 分词从原文件现算，文件是 2026 年 11 月 3 日 00:16–00:23（新加坡时间）下载的。

TikHub 一侧最省的路径是两步：先读文档站的 llms.txt 目录（1,274 行，约 47,604 token），在里面找到「TikTok-Web-API 获取用户的个人信息」这一行，再打开它的单页 Markdown（约 2,295 token），合计约 49,899 token。官网的 llms.txt 只有 1,279 token，但它只列平台和入口链接，没有接口清单，读完还得去文档站。整份 openapi.json 约 839,775 token，任何一个代理都不该整份读。走它的 MCP 也是一个办法：TikTok 服务有 163 个工具，模型连上后会拿到 163 份工具说明，具体多少 token 要带 token 才能列出来，我们没有测。

EveryInfra 一侧最省的路径是一步：GET /api/v1/social/catalog?platform=tiktok&compact=1，6,809 字节、约 1,870 token，里面是 TikTok 全部能力的参数、单价和返回字段名，读完就能写请求。按这条路径算，TikHub 一侧要读的量是我们的约 26.7 倍。要说明的是，这个倍数比的是「为了一个接口要读多少」，不是文档质量：TikHub 每个接口页里的中英双语说明、参数示例都写得很细，我们的 compact 目录去掉了说明文字，只留字段名，读起来更省，也更干。两边还有一个共同点：都提供了给 AI 读的 llms.txt，这个做法来自 llms.txt 提案，它建议放一个简短的 Markdown 索引，把详细内容放在链接后面，两家都是这么做的。

tikhub github：12 个公开仓库逐个看

TikHub 的 GitHub 组织在 00:16 有 12 个公开仓库。我们用 GitHub API 读了每个仓库的星标数和最后推送时间，又把其中 6 个 SDK 和插件仓库克隆下来，用脚本把源码里写死的 /api/v1/... 接口路径全部取出，和当天的 openapi.json 比。

Python SDK 是 TikHub 维护得最好的一个，这一点要先肯定。它在 10 月 2 日（太平洋时间）的提交里写着「sync SDK to live OpenAPI spec, skip deprecated endpoints (1048 endpoints)」，第二天以 2.2.0 发到 PyPI。我们取出的 1,048 个路径全部还在今天的文档里，一个死链都没有；它有同步和异步两套客户端，自动重试和限速处理，类型检查按 mypy --strict 过，README 有英、中、法、西、日五种语言。它只差今天比 10 月 3 日多出来的 9 个接口：B 站动态评论、领英的 5 个异步任务接口、Threads 的两个新版接口和 TikTok 商城热销榜。按一个月 9 个的速度，下一次同步之前会一直差一点。

另外四种语言就差很多了。TypeScript、Go、Java、C++ 四个 SDK 都是 2025 年 3 月用 OpenAPI 生成器生成后就没再动过，源码里的 586 个路径有 245 个（Go 是 247 个）已经从文档里消失，调这些方法会得到 404 或者别的错误；剩下 341 个只覆盖当前接口的 32.3%。TypeScript SDK 还有一个更直接的问题：它在 npm 上的包名是 @tikhubio/tikhub-api-ts-sdk，最新版 1.0.1，但 npm 页面上两处安装命令写的都是 @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 月的示例脚本，按抖音、Instagram、快手、TikTok 分目录；TikHub-Multi-Functional-Downloader 是一个带界面的无水印下载器，193 星，是这个组织里除 Python SDK 外星标最多的；tikhub-mcp-dist 是给想在本机跑 MCP 的人用的；Spinneret 是 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，只要写一次请求函数，换平台只改 platform 和 action。

这里有一个容易被忽略的差别：接口的「形状」决定了 SDK 有多重要。TikHub 每个接口有自己的路径和参数名，1,055 个接口就是 1,055 个函数，SDK 落后一个月就会缺接口，落后一年半就会有四成方法调不通；所以它的 SDK 维护负担很重，也难怪五个 SDK 里只有 Python 一个跟上了。我们只有一个端点，SDK 里真正需要更新的只是能力名的清单，新能力上线后，旧版 SDK 照样能用字符串去调，只是 IDE 不会补全。两种设计没有绝对的好坏：TikHub 的方式让每个接口的参数都能被类型检查，我们的方式让 SDK 很难过时。

我们自己的示例代码放在公开仓库 everyinfra-agent-plugins 里，/docs 上配合代理的组合示例写明了 2026 年 10 月 24 日实测过，中英西三份各跑一次。

我们这边：Python SDK、命令行和远程 MCP

EveryInfra 的 SDK 是 11 月 1 日才发的。PyPI 上的 everyinfra 0.3.0 和 npm 上的 everyinfra 0.3.0 同一天发布，同一批文件也放在 GitHub Release sdk-v0.3.0 里，附 SHA256 校验。它不是从 OpenAPI 生成的，原因上面说过：573 项能力共用一个端点，OpenAPI 生成器只能生成一个通用方法。我们从后端的能力注册表直接生成平台名和能力名的字面量类型，IDE 能补全、拼错当场标红。11 月 3 日凌晨我们装上 0.3.0 数了一遍：它的类型清单里有 106 个平台、573 项能力，和线上目录逐项对上，没有多也没有少。

同一个包带一个命令行 everyinfra。everyinfra catalog --find 和 everyinfra describe tiktok/profile 不要 Key，直接查能力、参数、返回字段和价格；--dry-run 只打印请求和按标价估的费用，什么都不发；--max-cost-usd 估价超过上限就不发。everyinfra mcp-config --client claude 会打印各家客户端的 MCP 配置，默认引用环境变量，不把 Key 写进文件。这几条是 TikHub 的 SDK 没有的，它们针对的是「让 AI 代理替你调接口」时最怕的事：调错了、调多了、Key 落进了文件。

远程 MCP 两边做法不同。TikHub 按平台拆服务：MCP 页面和 llms.txt 写的是每个平台一个地址，例如 https://mcp.tikhub.io/tiktok/mcp，要几个平台就加几条配置；不带 token 就能读的 /platforms 列了每个平台的工具数，抖音 319 个、TikTok 163 个。工具多的好处是每个接口直接是一个工具，坏处是一个抖音服务就要让模型看 319 个工具的说明。我们只有一个地址 https://api.everyinfra.com/mcp，列 12 个工具，数据能力全部通过 everyinfra_call_api 加 platform、action 两个参数调，要找能力先调免费的 everyinfra_list_capabilities；tools/list 一共 3,779 token。MCP 规范本身对这两种做法都允许。现行规范是 2026 年 7 月 28 日的修订版，传输层一节把协议改成了无状态：不再有 initialize 握手和会话编号，Streamable HTTP 下每条消息都是对同一个地址的一次 HTTP POST，协议版本和客户端能力写在每个请求的 _meta 里。我们 00:21:11 那两次请求就是这样发的：先 tools/list、再 tools/call，没有先握手，照样拿到了结果。鉴权一节以 OAuth 2.1 为基础，但开头写明鉴权对实现是「OPTIONAL」；两家都没有用 OAuth，都是请求头带 Key，这在规范里是允许的，代价是客户端没法替你走一遍登录授权，Key 要你自己填。下面是一个配置示例，字段写法以你用的客户端文档为准，Key 用环境变量引用：

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

三次真调：curl、Python SDK 和 MCP 各一次

为了把「从拿到 Key 到第一次成功调用」这件事落到实处，我们挑了两边都有的三个常见场景，每个场景换一种调用方式。三个场景都是读一个对象：一个 TikTok 账号的主页、一条抖音作品、一篇小红书笔记，对应 EveryInfra 的 tiktok/profile、douyin/video、xiaohongshu/note，对应 TikHub 文档里的 tiktok/web/fetch_user_profile、douyin/web/fetch_one_video 和它推荐优先用的 xiaohongshu/app_v2/get_image_note_detail。

第一次用 curl，00:18:54（新加坡时间）发出，30 秒后返回：tiktok 官方账号，粉丝 96,500,000、作品 1,514 个，扣 $0.000556。和 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"}}'

第二次用 Python SDK 0.3.0，00:20:19 发出，27.4 秒返回一条抖音空气炸锅测评作品：点赞 33,693、评论 2,101，扣 $0.000556。代码只有三行，Key 从环境变量读：

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"])

第三次走远程 MCP，00:21:11 发 tools/call，工具是 everyinfra_call_api，42.2 秒返回一篇 2026 年 10 月 25 日发布的小红书笔记：点赞 992、评论 567，扣 $0.005556。返回的 result.content[0].text 里是和 REST 一样的 JSON，billing 也在里面。

有一点要照实说：这三次成功调用都慢，27–42 秒。我们的同步调用上限是 85 秒，超过按超时失败、不扣费；批量跑时文档建议加 "mode": "async" 拿任务号再取结果。TikHub 那边我们没有 token，测不了它真实接口的耗时，只知道它的演示接口 0.65 秒（返回的是缓存的固定对象），它的 openapi 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 下面，字段名是平台自己的驼峰写法。好处是信息全，平台给什么就有什么；代价是每个平台、每个版本的接口都要单独写一套解析。

这个外壳里没有「本次扣了多少钱」。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 加起来就是总花费，本文的三次真调就是这样对账的。

价格只算一小笔账

价格已经有两篇专文，这里只把三个场景的单价放在一起。三个都是「一次请求读一个对象」，所以每千次请求和每千条结果是同一个数。

按标价算，三个场景 TikHub 都是我们的 1.8 倍（我们低约 44%），这和目录里 $0.000556 这一档的单价一致。有两种情况 TikHub 更便宜。一种是量：TikHub 的 llms.txt 写了按天累进的折扣，每天 3 万次以上降到 5 折，TikTok 主页这个接口允许打折，打满后 $0.50 每千次，比我们的 $0.556 低。另一种是「文档外的接口」：小红书笔记在 TikHub 价目里有一个 v5，每次 $0.001，只有它文档推荐的 App V2 接口的十分之一，我们的单价是它的 5.6 倍；但这个 v5 不在 openapi.json 里，没有参数说明，它的稳定性我们无从判断。更完整的价格对比，见 TikHub pricing 详解和 37 项抖音能力逐项比价。

算账时还要把「调错的那几次」算进去，上手阶段这部分往往不少。本文 00:18:54 那次不带 Key 的请求和 00:19:24 那次参数写错的请求，EveryInfra 都返回错误并扣 $0，charged_usd 是 0；参数检查在扣费之前，写错参数名不会先扣再退。TikHub 的 FAQ 写的是「只对成功的请求计费」：返回 200 才扣，失败的请求不扣，单价从每次 $0.001 到 $0.01 按接口不同。按这个说法，401、403、422 这类错误不扣钱，但我们没有它的 Key，没有实测它对错误请求的扣费。两边真正不一样的是「200 但没数据」：我们的空结果按同一个 charge_id 退回，TikHub 的公开文档里没有找到空结果退费的说明，它的退款政策页写的是充值一律不退。所以让 AI 代理反复试参数的阶段，两边的错误请求大概率都不花钱，差别在拿到空结果的那几次：比如查一个刚改名的账号、一条已删除的作品，平台照样回 200，只是里面没有数据。批量查询里这类目标越多，两边的实际花费差得越远。

什么时候 TikHub 更合适

不写这一节，前面的对照就不公平。下面每一条都来自上面引用的公开材料。

TikHub 还有一个我们没有的设计：每个成功的响应带一个 cache_url，24 小时内可以免费重新打开这次的原始 JSON，教程页说用途是解析写错了不用再付一次钱、也方便给同事复现。我们这边要复查一次调用，可以用 request_id 查调用记录和扣费结算，但看不到当时的完整返回。反过来，我们比它多的是：失败和空结果自动退回预扣、调用前就能看到每项能力的返回字段、一把 Key 能按产品拉闸、命令行能先估价再发，以及覆盖面：目录里 106 个平台除了社交媒体，还有电商、点评、地图和招聘这些 TikHub 的 15 个平台（另有一个「其他」类）没有的类别，具体以目录为准。

按你的情况选

把前面的对照收成几条判断。第一，如果你已经确定只用 Python、要的正好是 TikHub 那 1,055 个接口里很细的一类（比如星图、抖音指数），并且愿意自己写每个接口的解析，TikHub 的 Python SDK 是现成的路，文档虽然厚，但每个接口页写得很细。第二，如果你用的是 JavaScript、Go 或 Java，TikHub 的 SDK 帮不上多少忙，两家都要自己发 HTTP，这时差别在于要读多少文档：我们按平台取的目录只有约 1,870 token，调用前就知道返回字段。第三，如果是让 AI 代理替你调，最要紧的三件事是：它能不能先查到参数和价钱、调错了会不会扣钱、Key 会不会被它写进文件。本文实测里，我们的 401 和 422 都没扣费并给出下一步，命令行能先估价再发；TikHub 的演示接口能让代理先看一次真实返回，401 带标准的响应头。第四，如果你每天要调几万次同一个允许打折的接口，或者能接受用价目里没有文档的接口，TikHub 的单价可能更低，先按它的价目接口算一遍再决定。

行业动向

• 2026-11-03：TikHub 的 openapi.json 是 1,058 个路径，比 11 月 2 日多 2 个，版本号仍是 V5.3.2。对读者意味着：用它生成或同步 SDK 时，不要只看版本号判断有没有变化。
• 2026-10-28：GitHub 推送拦截开始支持 AI 检测的密钥，公开预览，默认关闭，只对买了 Secret Protection 或 Advanced Security 的组织开放。对读者意味着：没有固定格式的 Key 也可能在推送时被拦下，但要组织自己打开；个人仓库仍要靠自己不提交。
• 2026-10-20：GitHub 密钥扫描的自定义规则接口把参数错误从返回 500 改成返回 422，好让调用方分清「我填错了」和「服务器坏了」。对读者意味着：不管接 TikHub 还是我们，重试逻辑都按 4xx 先改请求、5xx 才重试来写，两家都把参数错误放在 422。
• 2026-11-01：EveryInfra 的 Python 和 npm SDK 0.3.0 发布，同一天能力目录从 91 个平台扩到 106 个。对读者意味着：SDK 的类型清单和线上目录要一起看，我们实测这一版两边一致。
• 2026-10-13：GitHub 公开了新的密钥识别模型：先用正则广撒网，再用一个小模型看文件路径、变量名和上下文，用户接受率提高 11.5%，扫描耗时中位数降 86%。对读者意味着：没有固定前缀的 Key 正在变得更容易被认出来，但 Key 本身最好还是不进仓库。
• 2026-10-03：TikHub Python SDK 2.2.0 发布，同步到 1,048 个接口。对读者意味着：一个月后它已经差 9 个新接口，用新接口时直接按 HTTP 调。

常见问题

问题来自 2026 年 11 月 3 日读到的 Google 搜索联想词和论坛原帖，每问后面写了出处。

tikhub api key 在哪里创建？

登录 user.tikhub.io，进用户中心，点 API token 菜单创建（联想词「tikhub api key」，步骤见它的文档 README「Get API Token」一节）。注册后要先点验证邮件，否则调用会返回 403。每个用户最多 100 把 Key。注意 ai.tikhub.io 那个 AI 代理服务的 Key 是另一套，调不了数据接口。

tikhub api doc 和 Swagger 有什么区别？

内容是同一份 openapi.json（联想词「tikhub api doc」）。docs.tikhub.io 是按接口分页的文档站，适合查参数；api.tikhub.io 是 Swagger 页面，可以填 token 直接试调，填的时候不要带「Bearer」前缀。两处都没有写每个接口返回哪些字段，因为 1,052 个接口的返回只写了通用外壳，要实际调一次才知道。

tikhub github 上哪个 SDK 能用？

Python SDK（联想词「tikhub github」「tikhub api python」）。它 10 月 3 日发的 2.2.0 覆盖了当前 99.2% 的接口；TypeScript、Go、Java、C++ 四个 SDK 2025 年 3 月之后没更新，只覆盖 32.3%，有 245 个方法对应的接口已经不在文档里。用这四种语言，直接按 HTTP 调更稳。

tikhub 使用教程在哪里看？

官网有一个教程页（联想词「tikhub 使用教程」「tikhub 使用方法」），内容是常见问题加 Python、JavaScript、Go、Java、PHP 和 cURL 的请求示例；上手页 tikhub.io/getting-started 讲注册、充值四步。中文社区里也有用户写过实际用法，比如掘金上那篇把 openapi.json 做成 Claude Code 技能的文章。要注意文档站目录里叫「Getting Started」的那一页是商家入驻说明，不是调用教程。

tikhub api python 怎么开始？

装官方包 pip install tikhub，把 Key 设成环境变量，再按 README 里的资源名调用（联想词「tikhub api python」）。它的 2.2.0 版覆盖当前 99.2% 的接口；如果要用的是 10 月 3 日之后新上的接口，SDK 里还没有，直接用 HTTP 请求更快。

tikhub login 之后 403 怎么办？

先看是不是邮箱没验证（联想词「tikhub login」）。它的 README 列了 403 的四种原因：路由权限不够、账户停用、邮箱未验证、token 权限不够；如果是 402，则是余额不足，并且分「接受免费额度」和「不接受免费额度」两种，后一种要充值才能调。

TikHub 是正规的吗，数据合法吗？

Reddit 上有人问过「Is TikHub AI legit」（r/Seedance_AI 原帖），回帖没有给出结论。TikHub 的教程页自己的说法是只提供公开数据、不拥有这些数据，退款政策写的是除接口确实不可用外概不退款。我们不评价它的合规性，只建议先用演示接口和 $0.05 免费额度试，再决定充多少。

tiktok api key free 有吗？

TikTok 官方的 Display API 只能读授权用户自己的资料和视频（联想词「tiktok api key free」）；Research API 要以研究机构身份申请。第三方接口一般都有小额试用：TikHub 送 $0.05，我们点星送 $1、24 小时内有效。

上手步骤

1. 在 能力目录 或基础设施市场找到要的能力，例如 tiktok/profile，看参数、返回字段和单价，不用 Key。
2. 注册并在控制台建一把 Key，完整 Key 只显示一次，放进环境变量 EVERYINFRA_API_KEY。
3. 照 /docs 快速开始 的 curl 发第一次请求，或 pip install everyinfra 用 SDK，或把上面的 MCP 配置贴进客户端；看返回里的 billing.charged_usd。
4. 遇到 401、422 先读返回里的 next_steps；更多平台见 TikTok、抖音、小红书 平台页和 MCP 接入。

参考资料

1. Getting Started — First API Call in 4 Steps，TikHub，2026-11-03 读取，https://tikhub.io/getting-started
2. Social Media API Tutorials & Code Examples（教程与常见问题），TikHub，2026-11-03 读取，https://tikhub.io/tutorials
3. Pricing，TikHub，2026-11-03 读取，https://tikhub.io/pricing
4. llms.txt，TikHub，2026-11-03 读取，https://tikhub.io/llms.txt
5. llms-full.txt，TikHub，2026-11-03 读取，https://tikhub.io/llms-full.txt
6. MCP Integration Guide，TikHub，2026-11-03 读取，https://tikhub.io/mcp
7. Social Media API Reference，TikHub，2026-11-03 读取，https://tikhub.io/api-reference
8. README - English，TikHub 文档站，2026-11-03 读取，https://docs.tikhub.io/4592766m0
9. 自述文档 - 中文，TikHub 文档站，2026-11-03 读取，https://docs.tikhub.io/4579297m0
10. ⚡ Getting Started（商家入驻），TikHub 文档站，2026-11-03 读取，https://docs.tikhub.io/5432442m0
11. llms.txt（文档站目录），TikHub 文档站，2026-11-03 读取，https://docs.tikhub.io/llms.txt
12. 获取用户的个人信息 / Get user profile，TikHub 文档站，2026-11-03 读取，https://docs.tikhub.io/186826057e0
13. 【Demo】TikTok 固定用户信息，TikHub 文档站，2026-11-03 读取，https://docs.tikhub.io/337619232e0
14. 获取所有端点信息 / Get all endpoints information，TikHub 文档站，2026-11-03 读取，https://docs.tikhub.io/186826055e0
15. About TikHub AI API，TikHub 文档站，2026-11-03 读取，https://docs.tikhub.io/7781112m0
16. TikHub Refund Policy（2026-07-20 更新），TikHub 文档站，2026-11-03 读取，https://docs.tikhub.io/9453198m0
17. openapi.json（V5.3.2），TikHub，2026-11-03 读取，https://api.tikhub.io/openapi.json
18. Swagger UI，TikHub，2026-11-03 读取，https://api.tikhub.io/
19. 价目接口 get_all_endpoints_info，TikHub，2026-11-03 读取，https://api.tikhub.io/api/v1/tikhub/user/get_all_endpoints_info
20. 演示接口 demo/tiktok/web/fetch_user_profile，TikHub，2026-11-03 读取，https://api.tikhub.io/api/v1/demo/tiktok/web/fetch_user_profile
21. MCP platforms，TikHub，2026-11-03 读取，https://mcp.tikhub.io/platforms
22. TikHub GitHub 组织，GitHub，2026-11-03 读取，https://github.com/TikHub
23. TikHub-API-Python-SDK，GitHub，2026-11-03 读取，https://github.com/TikHub/TikHub-API-Python-SDK
24. 提交 c4620078：sync SDK to live OpenAPI spec（1048 endpoints），GitHub，2026-10-02，https://github.com/TikHub/TikHub-API-Python-SDK/commit/c4620078fa6930380c6c2a0a51597718c762e27a
25. TikHub-API-TypeScript-SDK，GitHub，2025-03-17，https://github.com/TikHub/TikHub-API-TypeScript-SDK
26. TikHub-API-GoLang-SDK，GitHub，2025-03-09，https://github.com/TikHub/TikHub-API-GoLang-SDK
27. TikHub-API-Java-SDK，GitHub，2025-03-09，https://github.com/TikHub/TikHub-API-Java-SDK
28. TikHub-API-CPP-SDK，GitHub，2025-03-09，https://github.com/TikHub/TikHub-API-CPP-SDK
29. TikHub-API-Demo，GitHub，2024-12-02，https://github.com/TikHub/TikHub-API-Demo
30. tikhub-plugin，GitHub，2026-06-16，https://github.com/TikHub/tikhub-plugin
31. tikhub-mcp-dist，GitHub，2025-09-23，https://github.com/TikHub/tikhub-mcp-dist
32. TikHub-Multi-Functional-Downloader，GitHub，2025-03-18，https://github.com/TikHub/TikHub-Multi-Functional-Downloader
33. Spinneret，GitHub，2026-11-02，https://github.com/TikHub/Spinneret
34. tikhub_api_skill，GitHub，2026-11-03 读取，https://github.com/liangdabiao/tikhub_api_skill
35. tikhub 2.2.0，PyPI，2026-10-03，https://pypi.org/project/tikhub/
36. @tikhubio/tikhub-api-ts-sdk，npm，2026-11-03 读取，https://www.npmjs.com/package/@tikhubio/tikhub-api-ts-sdk
37. EveryInfra 能力目录，EveryInfra，2026-11-03 读取，https://api.everyinfra.com/api/v1/social/catalog
38. EveryInfra 能力目录 compact=1，EveryInfra，2026-11-03 读取，https://api.everyinfra.com/api/v1/social/catalog?compact=1
39. EveryInfra OpenAPI 2.0.0，EveryInfra，2026-11-03 读取，https://api.everyinfra.com/openapi.json
40. EveryInfra llms.txt，EveryInfra，2026-11-03 读取，https://api.everyinfra.com/llms.txt
41. everyinfra 0.3.0，PyPI，2026-11-01，https://pypi.org/project/everyinfra/
42. everyinfra 0.3.0，npm，2026-11-01，https://www.npmjs.com/package/everyinfra
43. everyinfra-agent-plugins Release sdk-v0.3.0，GitHub，2026-11-01，https://github.com/everyinfra/everyinfra-agent-plugins/releases/tag/sdk-v0.3.0
44. RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage，IETF，2012-10，https://datatracker.ietf.org/doc/html/rfc6750
45. RFC 9110: HTTP Semantics，IETF，2022-06，https://www.rfc-editor.org/rfc/rfc9110.html
46. MCP 规范 Transports（2026-07-28），Model Context Protocol，2026-11-03 读取，https://modelcontextprotocol.io/specification/2026-07-28/basic/transports
47. MCP 规范 Authorization（2026-07-28），Model Context Protocol，2026-11-03 读取，https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
48. Display API Overview（2026-08-04 更新），TikTok for Developers，https://developers.tiktok.com/doc/display-api-overview
49. TikTok Research Tools: Access and Eligibility，TikTok for Developers，2026-11-03 读取，https://developers.tiktok.com/products/research-api/
50. 开源 DIY 一个文档全接口转 Claude code skill，掘金，2026-11-03 读取，https://juejin.cn/post/7595096774546096137
51. 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/
52. FAQ — Billing, Rate Limits and Platform Support，TikHub，2026-11-03 读取，https://tikhub.io/faq
53. Supported secret scanning patterns，GitHub Docs，2026-11-03 读取，https://docs.github.com/en/code-security/secret-scanning/introduction/supported-secret-scanning-patterns
54. Push protection beyond predefined secret patterns，GitHub Changelog，2026-10-28，https://github.blog/changelog/2026-10-28-push-protection-beyond-predefined-secret-patterns/
55. Updates to GitHub secret scanning，GitHub Changelog，2026-10-20，https://github.blog/changelog/2026-10-20-updates-to-github-secret-scanning/
56. GitHub's model for secret detection: Finding more secrets with less noise，GitHub Blog，2026-10-13，https://github.blog/ai-and-ml/githubs-model-for-secret-detection-finding-more-secrets-with-less-noise/