B站公开数据 API | SandBase

B 站是中国视频文化的重心——长视频投稿、弹幕评论流、热搜榜,还有直接对应到内容调研、趋势发现和创作者分析的 UP 主资料。但想用程序拿到这些数据,通常得逆向 app、管理 cookie,还要在网站每次改版时重建爬虫。

SandBase 的 B 站公开数据 API 把这层搭建成本去掉了。它通过普通 REST 端点读取 B 站公开的视频、搜索结果、热搜榜和用户资料——一把 SandBase API key,不用 B 站登录,也不用 SDK。端点 API 参考是每个参数和响应信封的权威来源;下面展示的业务载荷字段名只是一个示例结构、并非保证的 schema,请以你所调端点的一份真实响应为准核对。

这不是 B 站的官方开放平台。 如果你需要已认证的成员操作或一份授权的数据协议,请用 B 站官方 API;当你的流程需要的是公开、只读的数据(调研、监测)时,用 SandBase。想直接试?领取 SandBase API key,再浏览 B 站端点。

先说结论

• 一个 API 读取 B 站公开的视频、搜索、热搜、用户资料和评论。
• 本文的 Model API 端点用 POST /v1/api/bilibili/<path> 调用——只传该端点的参数,不用 SDK,一把 SANDBASE_API_KEY。
• 端点以自然标识为入参:视频用 bv_id/aid,创作者用 uid/user_id,搜索用 keyword。
• 它只返回公开、只读数据。不能发帖,也拿不到私密数据。这个公开数据流程不需要 Bilibili 登录或 OAuth,但仍需要一把 SandBase API key。

你到底需要哪个 B 站 API?

你的需求	选择	原因
发帖、以成员身份操作,或用账号授权数据	B 站官方平台	成员和账号操作走 B 站官方。
读取公开的视频、搜索、热搜或资料	SandBase B 站公开数据 API	普通 REST、一把 SandBase key、面向只读流程的结构化 JSON。
私密或仅账号可见的数据	都不适用于公开流程	这类数据不在本篇公开数据的范围内。

从 B 站 API 能拿到什么

整个目录横跨一个 app 面和一个 web 面。按用途归类:

• 搜索与发现 —— 综合搜索、按类型搜索,以及热搜榜。
• 视频 —— 按 bv_id/aid 读视频详情、分P、播放信息、弹幕和字幕。
• 创作者 —— 按 uid 读公开资料、投稿视频、动态和关系统计。
• 评论 —— 视频评论和回复串。

动手前请查每个端点的在线 API 参考,确认它所在的面和参数;可用性因端点而异。

SandBase 上的 B 站 API 页面——带标签的概览,加上端点列表,每个端点标有路径。

B 站提供的 vs. SandBase 补上的

公开数据来自 B 站。SandBase 并不拥有或运营 B 站,它只是为符合条件的公开数据流程提供一个统一的 API 层。每一项能力变成一个稳定端点,鉴权收敛成一把 key,响应都是可预期的 JSON——于是 agent 可以沿着同一套约定串起”读热搜榜 → 搜一个关键词 → 读创作者的资料”,而不用再维护一个爬虫。

快速上手:第一次调用

SandBase 有不止一个 API 面。目录里可能会展示 /apis/v1/... 下的 GET 路径;本文用的是每个端点 API 参考里带厂商前缀的 Model API 路径。不要替换 HTTP 方法或 URL——按你所选端点的参考文档来。

读取热搜榜:

import os
import requests

resp = requests.post(
    "https://api.sandbase.ai/v1/api/bilibili/web/hot-search",
    headers={
        "Authorization": f"Bearer {os.environ['SANDBASE_API_KEY']}",
        "Content-Type": "application/json",
    },
    json={"limit": 10},
)
resp.raise_for_status()
body = resp.json()
if body.get("status") != "completed":
    error = body.get("error", {})
    raise RuntimeError(error.get("message", "Bilibili request did not complete"))

# 参考只保证信封,业务字段随端点而定,以真实响应为准;
# 因此用 .get() 逐层取值。
data = body["outputs"][0]["data"]
trending = data.get("data", {}).get("trending", {}).get("list", [])
for item in trending[:5]:
    print(item.get("keyword"), item.get("heat_score"))

curl -X POST https://api.sandbase.ai/v1/api/bilibili/web/hot-search \
  -H "Authorization: Bearer $SANDBASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"limit": 10}'

每个响应都用同一个信封:一个 id、一个 status、model 名称,以及一个 outputs 数组,其中唯一一项在 data 下携带载荷。读 outputs[0].data 之前先判 status,并查每个端点的参考了解它的运行模式。注意 B 站端点常常把载荷包在一个上游的 { code, data, message } 对象里,所以有用的字段在 data.data 下。下面是一个示例响应结构——字段名并非保证的 schema,请把字段名和数值当作示例,以一份真实响应为准核对(载荷会变、数值也会随时间变):

{
  "id": "8ec19c89-2442-432b-9b05-efa2f4c97ce7",
  "status": "completed",
  "model": "bilibili/web/hot-search",
  "outputs": [
    {
      "data": {
        "code": 0,
        "data": {
          "trending": {
            "list": [
              { "keyword": "…", "show_name": "…", "heat_score": 4414039 }
            ]
          }
        }
      }
    }
  ]
}

failed 或 timeout 的请求会带上 error 而没有 outputs。不同端点的响应结构不一样——先看一份真实响应,再按端点逐一对准字段路径。

端点的 API 参考是每个参数名和响应路径的权威来源。

能力地图

能力簇	代表端点	典型用途
热搜	bilibili/web/hot-search	热门话题监测
搜索	bilibili/app/search-all	跨内容的关键词发现
用户资料	bilibili/web/user-profile	按 uid 的公开创作者信号
视频详情	bilibili/web/video-detail	按 aid 读视频
视频评论	bilibili/web/video-comments	互动与情感分析输入

分页方式因端点而异——若干端点接受一个页码或偏移类的请求参数。具体看每个端点的 schema。

B 站端点列表的一部分,横跨 app 和 web 两个面。

在 agent 工作流里串联调用

因为每个端点共用同一套鉴权和同一个响应信封,agent 可以从一个趋势走到一个创作者,而不用为每个页面单独写特例。一个常见的内容调研模式是这样:

1. 读榜。 调 bilibili/web/hot-search 拿趋势列表,再挑你关心的关键词。
2. 搜关键词。 用 keyword 调 bilibili/app/search-all 拉匹配的视频和创作者。
3. 给创作者建档。 用 uid 调 bilibili/web/user-profile,附上像昵称、等级和签名这样的账号上下文。

每一步都返回同样的 { id, status, model, outputs } 结构,所以你的 agent 只需判一次 status,读 JSON 的那段代码(包括 data.data 的解包)在每一步都能复用。

常见用例

用 B 站热搜 API 做趋势监测

按计划定时轮询 bilibili/web/hot-search 追踪趋势榜——每一项带一个关键词和一个热度分。输入:必填的 limit(整数)。输出:排名的热门关键词列表。端点:hot-search。

用 B 站搜索 API 做内容发现

用一个关键词调 bilibili/app/search-all,围绕某话题摸清视频和创作者。输入:关键词。输出:匹配结果。端点:search-all。

用 B 站创作者 API 做频道调研

用 bilibili/web/user-profile 读取公开创作者,拿到像昵称、等级和签名这样的字段。输入:uid。输出:结构化的资料记录。端点:user-profile。完整工作流看如何做 B 站创作者调研。

为什么在 API 层做这件事

你当然可以让无头浏览器去抓 B 站、解析 HTML,但那条路很脆:标记会变,app 和网页端渲染不一样,你维护的是一堆选择器而不是在做功能。通过一个统一 API 读取,意味着你的代码依赖命名的 JSON 字段和一个统一的响应信封,而不是页面布局。鉴权是一把 key 而不是轮换 cookie;而且因为每个端点都返回同样的 { id, status, model, outputs } 结构,重试、日志和错误处理都集中在一个你写一次、到处复用的帮助函数里。

这种一致性正是让工作流对 agent 可组合的原因。把热搜关键词换成任意话题、把一个 uid 换成另一个,代码路径完全一样。再加第四次读取——比如某个视频的评论——它就接在同一个判状态的帮助函数后面。实际的回报是:你把时间花在数据对你的调研意味着什么上,而不是花在跟一个不断变化的目标较劲、维持爬虫存活上。当你需要的不止单次读取时,查线上列表找到合适的端点,接入前先确认它的参数。

边界与限制

• 只读、公开数据。 不能发帖、关注,也拿不到私密/仅账号可见的数据。
• 速率与量级。 把响应当作尽力而为的读取;作为客户端韧性措施,遇到 HTTP 429 这类瞬时错误时用退避重试。
• 参数与结构随上游而定。 标识各异(bv_id/aid、uid/user_id、keyword);载荷常嵌在上游的 data 对象下;分页是各端点自己的请求参数。先看真实响应、读 schema。
• 对照在线参考确认端点。 可用性和字段可能变化;在依赖某个具体端点之前先确认。
• 这不是 B 站官方合作。 SandBase 只是提供对公开数据的统一访问;请遵守 B 站的条款以及你使用场景下适用的规则。

常见问题

我需要 B 站开发者应用或登录吗? 不需要。你用 SANDBASE_API_KEY 向 SandBase 鉴权。这些读取端点不需要 B 站账号或你这边的 OAuth。

用什么来标识视频或创作者? 用自然标识:视频用 bv_id 或 aid,创作者用 uid/user_id。搜索用 keyword。

为什么数据嵌在 data.data 下? B 站端点常常透传上游的 { code, data, message } 信封,所以有用的载荷在 data.data 下。读每个端点的 schema 确认确切路径。

能读私密或仅账号可见的数据吗? 不能。这个 API 只返回公开数据。私密和账号授权的内容都不在范围内。

从热搜榜开始

创建一把 SandBase API key,调 hot-search,先看清返回的 schema,再扩展到搜索、视频或创作者。准备好之后:

• 领取 SandBase API key
• 浏览 B 站端点
• 打开 hot-search 的 API 参考