Bilibili API in Python: official, open-source and pay-per-call routes, tested

On November 11, 2026, between 00:14 and 00:24 Singapore time, we ran a full Bilibili data chain three times. We used Python and the requests library. Each chain had five requests: keyword search, video detail, hot comments, danmaku and subtitles. All 15 requests returned HTTP 200, and each chain cost $0.00278.

The most useful finding is that danmaku is a sample, not the full set. One science video had 36,824 danmaku. We called the danmaku capability six times for it and got only 190 unique rows, or 0.52%. We also checked the two other routes against their own primary documents.

The Bilibili Open Platform admits only legal entities set up in mainland China. Its data endpoints read only the videos of the creators who authorize your app. The two most-starred community projects for the Bilibili API stopped work after lawyer letters on January 28 and July 6, 2026.

This article is for one type of reader: a researcher, teacher or analyst outside China who knows Python and wants public data from Bilibili. Bilibili is the main Chinese site for long videos about study, science, games and animation. Its special feature is danmaku, which some English sources call "bullet comments". Viewers type short lines that fly across the video at the exact second they were sent. Each line is tied to a time in the video. That makes danmaku a direct record of where an audience reacts.

Our running example is online teaching. We searched Bilibili for the Chinese words for "linear algebra open course". Two uploads of the MIT 18.06 Linear Algebra lectures were in the top three results by views, with 2,625,573 and 1,426,675 views. Many English-speaking teachers and learning researchers want to know how a Chinese audience reacts to a lecture like that. We explain what each route needs, what it returns and what it costs.

Summary: which route fits which reader

The three routes serve almost separate groups of people. The table puts side by side what each route needs, what it can return and its main risk. Each row has a source or a live test later in this article.

Our reading is this. Are you a media agency or a brand service company in China that publishes for creators under contract? Then the Open Platform is the only proper choice. It can write and it can read private account data, which no other route can do. If you only want to download a few public videos for a class, a command-line downloader is enough.

But it can stop working at any time, and its maintainers can stop too. Maybe you want ongoing public videos, comments and danmaku about a topic for research, and you are not a Chinese company. Then a pay-per-call API is the route with the least setup. The sections below give the evidence.

Route 1: the Bilibili Open Platform and what it needs

Many guides describe "the Bilibili API" as a public API that anyone can request. The Open Platform's own documents do not support that. Its platform introduction says it serves media organizations, creators who can develop software, companies in vertical industries and brand service companies. The documentation home page groups its features into six areas: account consent, user management, video management, open data, article management and live streaming.

It describes open data as user data and video data after the user gives consent. The important words are "after the user gives consent". You get the data of the creator who authorized your app. You do not get data about any video on the site.

Admission: a mainland Chinese legal entity and a stamped letter

On November 11, 2026, at 00:31 Singapore time, we took a screenshot of the admission section of the Open Platform management rules. The text sets four conditions for a developer. It must be a legal entity that is set up and exists lawfully in mainland China. It must have a good record and not be on the lists of abnormal business operations or of untrustworthy parties. It must have a Bilibili developer account.

It must meet other conditions that Bilibili sets. The developer must also send a copy of its business license, valid for at least one more month. It must add a letter of commitment with the company seal. If the details do not match the form, Bilibili rejects the request. This rule closes the platform to individual developers, to companies outside mainland China and to researchers who apply as persons.

The same page limits how developers use the data. A developer must not leak the account data or video data of a linked creator. The page lists source files, the number of uploads, danmaku, and shares, comments and likes as examples. When a linked creator asks for deletion, the developer must delete the data and must not keep an anonymized copy. When a developer leaves or is removed, it must delete or return the user data and operating data it got from the platform.

The developer service agreement defines a linked creator as a Bilibili account that the developer connects to the service. The developer must have full rights of use or a lawful operating license for that account. In short, Open Platform data is for people who work for creators. It is not for people who study other creators' videos.

Open data: only the authorizing creator's own videos

We opened each data endpoint in the documentation. The endpoint that returns data for a single video has the scope ARC_DATA. The page marks it as needing both a permission request and user consent. The authorized user must be the author or a co-author of the video. It returns nine values: title, publish time, views, danmaku count, comment count, favorites, coins, shares and likes. The endpoint for growth data across all videos returns the change over the last 30 days.

The endpoint that returns details of one video has the scope ARC_BASE and also works only for the authorized user's own videos. The endpoint for basic public user information returns only a nickname, an avatar and an openid. The page explains that the openid is unique only per developer and app, so that apps cannot follow a user across services. The Open Platform privacy policy tells users the same thing from their side. The platform shares a user's own video data with the linked developer, and the user can withdraw consent at any time.

The last row needs an explanation. We read every group in the left index of the documentation. The groups are account consent, user management, video management, article management, open data, live streaming, events, customer service, commerce, creator support and courses. We found no endpoint that searches all videos by keyword.

We also found none that reads the comments of any video or the danmaku of a recorded video. This is the index as we read it on November 11. The platform can add endpoints later, so check the current documentation before you choose a route.

Signatures and OAuth: calling the official API from Python

Even with approval, the call pattern is different from a typical REST API. The OAuth 2.0 guide says you first join the platform and register an app to get a client_id and a secret. Then a user gives consent and you exchange a code for an access_token. When the app requests a new scope, users who already gave consent must give it again. Each refresh_token works once.

The signature guide asks for a set of request headers that start with x-bili-. You sort them, join them into one string, sign it with HMAC-SHA256 and your app_secret, and put the result in the Authorization header. A timestamp more than 10 minutes old makes the platform drop the request. The guide gives Go code and links a C# sample repository. It has no Python sample.

Below is our Python version of the guide. It uses only the standard hmac module. We have no Open Platform account, so we did not run it against a live app. Treat it as a configuration example.

"""Bilibili Open Platform v2.0 request signature, rewritten from the official doc (not run against a live app)."""
import hashlib, hmac, json, time, uuid

def bili_headers(client_id: str, app_secret: str, access_token: str, body: dict | None) -> dict:
    raw = json.dumps(body, separators=(",", ":")) if body else ""
    signed = {
        "x-bili-accesskeyid": client_id,
        "x-bili-content-md5": hashlib.md5(raw.encode()).hexdigest(),   # md5 of "" for GET
        "x-bili-signature-method": "HMAC-SHA256",
        "x-bili-signature-nonce": str(uuid.uuid4()),
        "x-bili-signature-version": "2.0",
        "x-bili-timestamp": str(int(time.time())),                     # must be within 10 minutes
    }
    to_sign = "\n".join(f"{k}:{signed[k]}" for k in sorted(signed))
    sig = hmac.new(app_secret.encode(), to_sign.encode(), hashlib.sha256).hexdigest()
    return {**signed, "Accept": "application/json", "Content-Type": "application/json",
            "access-token": access_token, "Authorization": sig}

The signature is the easy part. The real barrier comes first. Without a mainland Chinese legal entity and a creator who gives consent, every request that this code signs will fail. The signature guide lists these status codes for signing errors.

The live-stream exception

The only public Open Platform feature that deals with danmaku is on the live-stream side. The long-connection protocol for the live open platform says the client first gets a server address from an app endpoint. Next, it sends an auth packet over WebSocket. Then it sends a heartbeat every 20 seconds.

The server pushes messages such as LIVE_OPEN_PLATFORM_DM. Messages identify users by open_id, and the page marks the old uid field as soon to be removed. The open-source blivedm library reads live danmaku in Python. Its README says it supports both the web interface and the live open platform, and its last push was on August 15, 2026.

This route suits interactive features for your own live room. It does not solve the problem in this article. Danmaku on a recorded video is tied to a second inside the video, and we found no endpoint that reads it.

Route 2: open-source libraries and API notes on GitHub

Search for "bilibili api python github" or "bilibili api collect" and the same group of projects comes first. On November 11, 2026, at 00:21 Singapore time, we read the public GitHub API for seven common projects. We recorded stars, last push, license and archive state, and then read each README. This section reports only what those public pages say. We do not rate the projects.

Two lawyer letters in 2026

The key facts are in the first two rows. The README of bilibili-API-collect, a large set of notes on Bilibili web endpoints, now holds one statement. On January 28, 2026, the maintainer got a warning letter by email from a law firm that acted for Bilibili. The letter said the project had collected and organized non-public endpoints, call logic, parameters, access controls and security checks.

It also said the project had shared them with the public as documents and code samples. The maintainer stopped work that day and deleted the documents and source code. Before the deletion, a contributor made a copy. Its description says the base content is synced to January 25, 2026, and it is also archived.

The README of the Python library bilibili-api now starts with a statement and a notice of infringement. The notice is from a Shanghai law firm and is dated July 6, 2026. The notice lists four kinds of action. The first two are getting past login and access control, and getting past anti-bot checks and request signatures. The other two are taking paid series and paid course content, and collecting danmaku to find the real identity of users.

It asks the maintainers to stop development, delete or roll back the code and publish a statement. The repository statement says work stops that day and the repository will close for good. Its PyPI package, bilibili-api-python, had its last release, 17.4.2, on June 19, 2026, and needs Python 3.10 or later. You can still install it, but nobody will fix it. So the library at the top of the results for "bilibili api python" and "bilibili api pypi" is now a frozen version.

This has two effects for readers. First, scripts built on these two projects will break when Bilibili changes an endpoint, and you must fix them yourself. Second, many tutorials teach the actions that the notice names, such as getting past signatures and anti-bot checks or finding who sent a danmaku. Read the section "Compliance and limits" before you keep that code.

WBI signatures, bot checks and login cookies

Projects that are still active also fix Bilibili code often. The yt-dlp Bilibili extractor prints "Downloading wbi sign" before it reads a video page. That step gets the parameters for the WBI signature that the website uses. You can see the line in the logs that users post in issues.

Issue #17847, opened on October 17, reports HTTP 567 on video file addresses. A maintainer could not reproduce it from their network, but the reporter saw it on several IP addresses in Poland. Issue #17879, opened on October 21, reports that the tool finds only an html format. A comment says a video address without /en/ sent the browser to a 404 page that day.

Issues #17894 and #17890, both from October 22, report "Unable to extract initial state". People in the thread think it looks like bot detection, because the page source has no initial state data. The fix in pull request #17898, opened the same day, was still not merged when we checked on November 11. The last commit to the Bilibili extractor file is from July 3.

MediaCrawler merged pull request #1000 on November 5, one day after it was opened. It fixes how the tool reads the WBI keys for Bilibili. The old code read the keys from the browser's localStorage. When the page or the browser context closed, that read raised an error, the whole batch crashed and unsaved data was lost.

The fallback request also had no login cookie, so the endpoint returned 412 or "not logged in", and the tool got no valid key. This one pull request shows three facts. The website endpoints need a WBI signature. The signing keys come from the page.

The request works best with a logged-in session. We do not teach how to get past these checks, and we do not advise it. We list them to show that the cost of your own script is not the first version. It is the weekly work to follow the site's changes.

The user agreement and robots.txt

At 00:23 Singapore time we read the robots.txt file of the main Bilibili site. For all user agents it disallows /medialist/detail/, /index.html and eight language paths such as /en/, /ja/ and /es/. A separate group covers some link-preview bots. The language paths match the yt-dlp report that /en/video/ opened while /video/ went to a 404 page.

The site seems to be changing its language addresses. A robots file is a statement to crawlers, not a legal text. The Bilibili user agreement, in force since May 7, 2025, is more direct. Clause 5.6, item 3, forbids getting the platform's services, content or data with robots, spiders, crawlers or any other automatic program, script or software.

The ban applies to you and to people who act for you, unless you have prior written permission. Clause 1.2 says the service is for non-commercial use by users. These two clauses apply to every route. We quote them here so that you can make your own decision.

Route 3: a pay-per-call API, with a full Python chain

On the third route, you send HTTP requests and pay per call. You do not maintain signatures, bot checks or page parsing yourself. We tested the EveryInfra data API. It has eight Bilibili capabilities, and our chain uses five of them. They are bilibili/search for keyword search, bilibili/video for video detail and bilibili/comments for hot comments.

The last two are bilibili/danmaku for danmaku and bilibili/subtitles for subtitles. We also tested bilibili/user_posts, bilibili/profile and bilibili/popular. Names, parameters, prices and fields come from the free catalog endpoint, which we read at 00:13 Singapore time. All eight capabilities had available=true. The trending list cost $0.000806 per page, and the other seven cost $0.000556 per call.

Search returns 20 rows by default and up to 50. We read the catalog again on November 12, 2026, Singapore time. Subtitles now cost $0.000792 per call, and the other seven prices did not change. At the new price, one full chain costs $0.003016. The charges in our tests use the prices of November 11. The Bilibili data API page gives an overview.

Below is the script we ran. It needs only requests, and it reads the key from an environment variable. Search sorts by views. The script keeps videos between 5 and 60 minutes long, because the longest results are often course compilations of 30 hours or more.

Then it picks the video with the most danmaku and fetches detail, comments, danmaku and subtitles. It saves each request and the full response as a JSON file, so you can check the numbers later. On a 429 response it waits 60 seconds and retries, because our test key allows 10 calls per minute.

"""Bilibili chain: search -> video -> comments -> danmaku -> subtitles."""
import json, os, sys, time
from pathlib import Path
import requests

API = "https://api.everyinfra.com/api/v1/social"
KEY = os.environ["EVERYINFRA_API_KEY"]          # never hard-code the key
SESSION = requests.Session()
SESSION.headers.update({"Authorization": f"Bearer {KEY}", "Content-Type": "application/json"})

def call(action, params, tag, name):
    body = {"platform": "bilibili", "action": action, "params": params}
    for attempt in range(4):
        t0 = time.time()
        r = SESSION.post(API, json=body, timeout=120)
        dt = round(time.time() - t0, 2)
        if r.status_code == 429:                  # rate limited: wait, then retry
            time.sleep(60)
            continue
        break
    data = r.json()
    Path(tag).mkdir(exist_ok=True)
    Path(tag, f"{name}.json").write_text(json.dumps(
        {"elapsed_s": dt, "http_status": r.status_code, "request": body, "response": data},
        ensure_ascii=False, indent=1))
    print(name, r.status_code, dt, data.get("count"), (data.get("billing") or {}).get("charged_usd"))
    return data

def rows_of(data):
    rows = data.get("results") or []
    return rows if isinstance(rows, list) else [rows]

def main(keyword, tag):
    s = call("search", {"keyword": keyword, "sort": "most_viewed", "limit": 20}, tag, "1_search")
    pool = [v for v in rows_of(s) if 300 <= (v.get("duration_sec") or 0) <= 3600] or rows_of(s)
    url = max(pool, key=lambda v: v.get("danmaku_count") or 0)["url"]
    call("video", {"url": url}, tag, "2_video")
    call("comments", {"url": url, "limit": 10}, tag, "3_comments")
    call("danmaku", {"url": url, "limit": 200}, tag, "4_danmaku")
    call("subtitles", {"url": url}, tag, "5_subtitles")

if __name__ == "__main__":
    main(sys.argv[1], sys.argv[2])

Set EVERYINFRA_API_KEY in your shell, then run python bili_chain.py "<keyword>" run1. Bilibili is a Chinese-language site, so Chinese keywords return far more results than English ones. Three details in the code need a note. First, requests.Session reuses connections.

The requests documentation says repeated requests to the same host reuse the TCP connection. We used requests 2.34.2, which needs Python 3.10 or later on PyPI. Second, keep timeout=120. In our test, one video detail call took 64.95 seconds, so the client timeout must allow for that.

Third, filter by length before you pick a video. In the first test, the three most viewed search results were 117,379, 100,509 and 100,483 seconds long. All were full courses of about 30 hours, which makes it hard to tie danmaku and subtitles to one lesson.

You can also connect the same capabilities to an AI tool without code. Below is a remote MCP configuration example. Field names differ a little between clients, and the key again comes from an environment variable. After you connect it, the AI calls the everyinfra_call_api tool with the same platform, action and params. The MCP server page shows how to connect each client.

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

Live test: three keywords from three fields

We chose keywords from three fields to test one script on different content. The Chinese keywords meant "linear algebra open course" (education), "black hole popular science" (science communication) and "citrus growing techniques" (agriculture). The chains started at 00:14, 00:16 and 00:22 Singapore time. "Done" in the table is the time when the subtitles step returned.

All 15 requests returned HTTP 200. Each call cost $0.000556, each chain $0.00278 and the three chains $0.00834. Before the test we set a target: a median serial time of 20 seconds or less for the five steps. The real median was 91.54 seconds, far from the target. The video detail step was the cause.

It took 23.96, 64.95 and 37.45 seconds in the three tests, which is 46.6%, 71.0% and 37.4% of the serial time. Search and comments took less than 2 seconds each, and danmaku took 9.63 to 13.02 seconds. In test 3, the subtitles step took 48.88 seconds, the only case where it was slower than video detail.

The slow detail step does not match the stream addresses. Test 1 returned 6 video streams and 3 audio streams, with a top quality of 480P. It was the fastest call. The slowest call, in test 2, had only 22 fields and no streams. We do not know the cause.

In test 1 the streams expired at 02:15 Singapore time on November 11, about 2 hours after the call. Maybe you need only counts. Search rows already have views, likes, comment count, danmaku count and favorites, so you can skip the detail call.

The screenshot shows what the API returns. The top card is the danmaku request from test 1 with two of its rows. The bottom card is the subtitles request with its first two lines. We kept only two rows, hid the author name and removed the balance field.

The raw responses show a few more results that you may not expect. First, the comments step returns hot comments, ranked by likes.

In test 2 the top ones had 7,825, 5,544 and 2,812 likes and 204, 504 and 46 replies. In test 1, the first comment came from the video's own author and repeated the description. Second, search rows had 19 or 20 fields, and none of the 60 rows had coin_count or share_count. This matches the field note in the catalog, so get coins from video detail. Third, the subtitles for the farming video in test 3 had the language "English" and one word of text.

The times were strings such as "00:00:01.560". Tests 1 and 2 gave times as numbers of seconds. That video has music and pictures but no speech, and the call was still charged $0.000556. A script that analyzes subtitles must check the number of segments and the time format first.

The table gives the top hot comments of each test in translation. Likes and replies are as the API returned them at the time of the call.

The third hot comment of test 1 asks a question that appears five times in the danmaku of that video. The teaching section below shows this. One question can show up in both data types, so read them together.

Fields: what each step returns

The table lists the main fields that each step returned in our tests. We checked each one against the catalog response_fields. It shows only the fields that analysis uses most. The catalog has the full list.

The missing sender field in danmaku needs a comment. The July notice named "collecting danmaku to find the real identity of users" as one of the infringing actions. The danmaku rows we got have only text, time in the video, display mode, color, pool and send time. The fields do not let you find the sender.

For research this helps, because you do not need a separate step to remove identities. The time fields posted_at and sent_at are ISO 8601 with a time zone. For example, the test 2 video shows 2025-10-05T02:30:00+00:00, which is 10:30 on October 5 in Singapore. Tools such as pandas and most databases can read these values directly.

We also called three capabilities outside the chain once each, between 00:25 and 00:26 Singapore time. The user ID was the creator of the test 2 video.

The profile has gender and birthday fields. For this creator, gender was set to hidden and the birthday showed only a month and a day. These are personal fields. A research project that studies videos does not need them, so do not store them.

Danmaku is a sample, and repeats do not fill the gap

The test 3 video has a danmaku_count of 19, and the danmaku call returned 19 rows, so we got all of them. The test 1 and test 2 videos have many more danmaku, and each call returned 100 rows.

For a video with few danmaku, one call gives the full set. For a video with many, one call gives only a part. The test 1 video has 3,731 danmaku, so 100 rows is 2.7%. The test 2 video has 36,824, so 100 rows is 0.27%.

We wanted to know if more calls fill the gap. We called danmaku five more times for the test 2 video. The first was at 00:25 Singapore time, and the other four were from 00:27 to 00:28. The call at 00:17 and the call at 00:25 had only 10 rows in common, so the second call added 90 new rows. The next four calls were the same as the 00:25 call and added nothing.

Six calls gave 190 unique rows, or 0.52% of 36,824, at a cost of 6 times $0.000556, or $0.003336. The two different samples were also very different. The 00:17 sample had send times from October 5, 2025 to November 8, 2026. The 00:25 sample had send times only from October 5 to October 28, 2025, the first three weeks after the video went live.

These numbers show two things. First, the danmaku capability returns a sample, not the full set. The sample can change over minutes. But repeated calls in a short time return the same batch, so more calls do not build the full set. Second, the sample leans toward the start of the video.

In test 2, 89 of 100 rows were in the first 15 seconds. Of those, 66 were the same short joke: two characters that split the word for "OK". In test 1, the 100 rows covered only the first 606 seconds of a 3,289-second video, which is 18.4%. We set a rule before the test. We would say that danmaku can draw a full timeline only if the rows covered at least 80% of the video.

Test 1 failed that rule. Test 2 covered 92.9% of the time. But 89% of the rows were in the first 15 seconds, and later minutes had about one row each. Our conclusion: one danmaku call can show what viewers react to at the start and in the first minutes. It cannot show which minute of the whole video has the most danmaku.

For a full timeline, use subtitles. In test 1 the subtitles had 983 lines, and the last line ended at 3,287.3 seconds, which covers the whole video.

The rows also differ in when they were sent and how they look. The send dates below are in Singapore time.

Short rows in test 2 match the many two-character jokes. Longer rows in test 1 are full questions and comments about the lesson.

A teaching example: where a lecture makes students react

Teachers and learning researchers often ask where students get stuck and where they get interested. Surveys and platform dashboards answer part of that, but the dashboard is open only to the video's owner. Danmaku is different because each line has a time in the video, so you can align it with the subtitles. You see what viewers said at a given second and what the teacher said at that second. We used the standard bisect module for the alignment and Counter for counts per minute. You do not need any extra package.

import bisect, json, re
from collections import Counter

dm = json.load(open("run1/4_danmaku.json"))["response"]["results"]
seg = json.load(open("run1/5_subtitles.json"))["response"]["results"]["segments"]
starts = [float(s["start"]) for s in seg]

def said_at(t):                                   # subtitle line playing at second t
    i = max(0, bisect.bisect_right(starts, t) - 1)
    return seg[i]["text"]

QWORDS = ["为什么", "怎么", "吗"]   # Chinese "why", "how", question particle
per_minute = Counter(int(d["video_time_seconds"] // 60) for d in dm)
questions = [(d["video_time"], d["text"], said_at(d["video_time_seconds"]))
             for d in dm if re.search(r"[?？]", d["text"]) or any(w in d["text"] for w in QWORDS)]
print(per_minute.most_common(4), len(questions))

Test 1 is a 55-minute problem class on determinants for the Chinese graduate entrance exam in math. Of the 100 danmaku, 25 were in minute 0 and 17 in minute 2. The peak was minutes 6 and 7, with 37 rows in two minutes. The subtitles show why.

In those two minutes, the teacher explained how to swap rows in a determinant and compared it to "bubbles going up". Viewers at once posted lines about bubble sort and joked that the math teacher now teaches computer science. Of the 37 rows, 19 named computer science, data structures, programming or their own major. One viewer wrote that they studied architecture and never learned computing.

Another asked where a business school student would learn bubble sort. For the teacher, this is a clear signal. An analogy from another field gets attention, but it is a new barrier for students who never learned programming. The next version can add one sentence that explains the analogy.

Questions are another signal. With a simple rule, a question mark or a Chinese question word, we found 15 question rows. Five were forms of one question. The viewer asks the teacher how to compute a determinant with three rows and four columns. A determinant exists only for a square matrix.

The question shows that some viewers do not yet know that a determinant belongs to square matrices. It appears again and again in the first seconds of the video. A short note card at the start of the next lesson would help. At 5:07 another row asked why there is a matrix inside a determinant. At that second, the subtitles show the teacher on the properties of cofactors.

All of this comes from a sample of 100 rows. It tells you that a reaction exists. It does not tell you what share of the audience had it.

The table pairs some question rows from test 1 with the subtitle line that plays at the same second. Both columns are our translations.

The last subtitle line shows a limit of AI transcripts. In this formula the teacher almost certainly said "minus one to the power N", and the transcript lost the word "minus". At 9:23 the subtitle line is too short to make sense. Check a subtitle line against the video before you quote it.

The science video is different. In test 2, 89 of 100 rows were in the first 15 seconds, and most were jokes. Only 4 were questions. Two of them asked about a black hole of one micrometer and of one nanometer. The top hot comment, "Next time, can you show a one-nanometer black hole?", had 7,825 likes.

The second, "Where do things that fall into a black hole go?", had 504 replies. The same curiosity appeared once in danmaku and once in comments. Danmaku is a quick line at one moment. The comment section is where people keep the discussion going. For science communicators, the question with the most replies is often the topic of the next video.

The farming video shows a third pattern. The test 3 film about oranges had only 19 danmaku, and one call returned all of them. Four were questions. One viewer asked what the clipped-in thorn is for.

Others asked how the fruit all ripens at the same time and how the farmers would harvest without it. In the hot comments, one viewer from Guangxi listed local citrus types. Another wrote about taking bees to the orange hills of Zigui County in Hubei to make orange-blossom honey. For an agricultural extension team or a regional marketing team, these 19 rows are already a short list of what viewers want to know.

Cost per 1,000 rows: danmaku is cheapest

Many people who search for "bilibili api" want the price of 1,000 rows. We did not divide the catalog price by the limit. We used the real row counts and the real charges from the three chains, three calls per capability.

The price per call is the same, so the cost per 1,000 rows depends on how many rows one call returns. Danmaku returns the most, so it is the cheapest, about 3.7 times cheaper than search. This is the opposite of our earlier Douyin Python test. On Douyin, search is billed per page and costs the most, and comments are billed in tiers of 20 and cost the least. On Bilibili, every capability is billed per call, so the one that returns more rows is cheaper.

A Bilibili plan should therefore get more danmaku and search rows. Subtitles are billed per video. For $0.000556 in our test ($0.000792 from November 12) you get the full timed text of one video. In test 1 that was 983 lines, the most information of the three text types.

Add the repeat danmaku calls and the picture changes a little. Danmaku had 8 calls in total: 3 in the chains and 5 repeats on the test 2 video. They returned 719 rows and cost $0.004448, about $0.0062 per 1,000 rows. But only 309 of those rows were unique. Per 1,000 unique rows the cost is about $0.0144. As shown above, repeat calls do not pay off.

Monthly cost for three use cases

Unit prices are not enough on their own, so we priced three real use cases. Prices come from the catalog that we read on November 12, 2026. A subtitles call costs $0.000792, a trending page costs $0.000806, and the other calls cost $0.000556. The table states the number of calls for each case.

The first case costs less than 15 cents a month, close to zero for a course team. Its real cost is the human time to read and sort the rows. In the second case, search is 10 calls a day, or $0.1668 a month, which is 33% of the total. The deep pulls are the rest. The third case uses bilibili/popular, the most expensive of the eight capabilities, at $0.000806 per page.

At 00:26 Singapore time we got one page of 20 rows. All 20 had an IP location and a category. That page had 3 rows from the daily life category, 2 from esports and 1 from each of 15 other categories. These figures cover only API fees, not your own servers or storage. The pricing page and the data market list all prices.

Errors and charges: when you pay nothing

When your own script fails, the hard question is whether the failure cost money and whether you should retry. At 00:26 and 00:27 Singapore time we made some calls fail on purpose and made one async call. With the earlier tests, the results are below.

The 422 row is worth a note. The error does not only say that the value is wrong. It also lists the allowed values and the closest matches. That helps a lot when an AI writes and fixes the script, because the model can read the error and correct the call.

For danmaku, the URL must contain a BV video ID, as the catalog parameter notes say. Async mode suits slow steps such as video detail. You do not hold a connection for 30 to 60 seconds.

You get a job_id and poll it. The subtitles row is the only case that succeeded but gave no useful data, and it was still charged. Before you fetch subtitles in bulk, filter by category and length from the search rows. To avoid double charges on retries, see our articles on idempotency keys and retries and refund reconciliation for failed calls.

The async call went through three states. The charge was made once, when the job was accepted.

When the other two routes are a better fit

A pay-per-call API is not the answer for every case. Here is where the other two routes are better.

The Open Platform is clearly better in three cases. The first is write access. To upload, edit or delete videos, publish articles or run live streams, you need the Open Platform. The data API only reads. The second is private data of an authorized account, such as 30-day growth, creator support income and dashboard numbers.

That data belongs to the account owner, and the Open Platform gives it to your app through consent. Other routes cannot get it and should not try. The third is live-room interaction. The live long connection pushes messages in real time, with better delay and completeness than any polling method, and the platform approves it. If you are a company in mainland China with creators under contract, the admission rules are not a barrier for you.

Open-source projects also have a place. If you only download a few videos that you can watch, for a class or a personal backup, a downloader is faster than any sign-up. You can read and change the code, and the data stays on your computer. Active general downloaders such as yt-dlp move fast, and someone often posts a fix within days.

Count two costs, though. One is upkeep: all the issues in Route 2 are from the last 30 days, and the Bilibili fix is still not merged. The other is risk: two projects stopped this year after lawyer letters, and scripts built on them have no maintainer.

A pay-per-call API fits the large middle group. You want ongoing public videos, hot comments, danmaku and subtitles from other creators. You do not need write access. You are not a mainland Chinese company or do not want the approval process. You have nobody to maintain signatures, and you want failed calls to be free and results that go straight into a table or database.

Its limits are real too. It cannot get the private data of an account. Comments are hot comments, not the full comment section. For a video with many danmaku, you get a sample, not the full set. Video detail takes 24 to 65 seconds per call.

The same Python pattern works for other platforms if you change the platform and action. Examples are the Douyin data API and the YouTube data API. For similar questions on Xiaohongshu, see Xiaohongshu API: official vs third-party. For Instagram, see scraping Instagram posts and comments with Python.

Compliance and limits

This section describes data methods and limits. It is not legal advice. All three routes face the same laws and the same user agreement. Articles 13 and 27 of China's Personal Information Protection Law cover personal information that a person made public or that is already lawfully public. They allow processing of it within a reasonable scope, unless the person clearly refuses.

Where the processing has a major effect on personal rights, consent is needed. A commenter's nickname, avatar and profile link are personal information. For research and course feedback, keep only the text, likes, reply count and time. Do not store nicknames or profile links. Danmaku rows have no sender field, so that side is cleaner from the start. Every response in our tests held content that public pages show: video data, hot comments, danmaku text and subtitles. None held private account data or the identity of a danmaku sender.

Article 13 of the Anti-Unfair Competition Law as revised in 2025 covers data that another business holds lawfully. It forbids a business to get or use that data by fraud, by force, or by getting around or breaking technical controls. The WBI signatures, bot checks and login sessions that open-source projects discuss are such technical controls. That is why Route 2 only states the facts and does not teach how to get around them.

The two Bilibili lawyer letters this year cite this law, the Civil Code and the Cybersecurity Law. A 2025 amendment decision changed the Cybersecurity Law, and the revised text took effect on January 1, 2026. The Network Data Security Management Regulations, in force since January 1, 2025, set general rules for network data processing. Large projects that keep data for a long time should check these rules too, and ask their own counsel when needed.

Universities that review research ethics often ask three questions about public online content. How do you store it, how long do you keep it and how do you remove identities? The field facts in this article answer part of that. Danmaku has no sender field. Comments include an author name and a profile link.

Stream addresses expire after about 2 hours. Subtitles are AI transcripts that the platform makes, marked ai-zh. Decide which columns you store before your first call. Put the retention period for raw JSON in your project plan, and delete the files when it ends.

The data itself also has limits that our tests confirm. Comments are only the hot ones, so you cannot measure the mood of a whole comment section. Danmaku is a sample and leans to the start of the video, so you cannot estimate the full danmaku curve. Subtitles are almost empty for videos without speech. Search results follow Bilibili's own ranking and are not complete, so you cannot use them to count all videos on a topic.

Frequently asked questions

Is there an official bilibili api python SDK?

No. The Open Platform gives signature samples in Go and in a C# repository. From Python you write the HMAC-SHA256 signature yourself from the guide, and Route 1 has a configuration example. You also need a mainland Chinese legal entity and a creator who gives consent.

Why does a bilibili api request get banned?

The website endpoints need a WBI signature, and some also need a login session. A missing signature, an old key or too many requests can lead to a refusal, often status 412. MediaCrawler pull request #1000, merged on November 5, fixed a WBI key read and a fallback request that had no login cookie. On the pay-per-call side, our 28 data requests got no 412.

One request hit the per-minute limit and got 429, and the retry 60 seconds later passed. Of the errors we made on purpose, no key returned 401 and a wrong sort value returned 422, with no charge.

Can I get Bilibili danmaku with an API?

The Open Platform has only the live-room connection, which needs the streamer's consent. We found no endpoint for danmaku on recorded videos. The pay-per-call bilibili/danmaku capability returns the time in the video and no sender field. In our test it cost about $0.0076 per 1,000 rows.

How do I get a bilibili api key?

For the Open Platform, you get a client_id and app_secret only after your mainland Chinese company joins and registers an app. For the pay-per-call API, you create a key in the console, as the steps below show.

Get started

1. Create an API key in the console. Store it in the EVERYINFRA_API_KEY environment variable, as the quickstart shows.
2. Read the free catalog at GET /api/v1/social/catalog?platform=bilibili. Check parameters, prices and available.
3. Install requests with pip. Copy the script from Route 3 and run it with your keyword.
4. Open the five JSON files in the output folder. Check billing.charged_usd for each step. Count the segments in subtitles, and treat danmaku as a sample.

References

1. Bilibili Open Platform, documentation home (in Chinese), read November 11, 2026, https://open.bilibili.com/doc
2. Bilibili Open Platform, platform introduction (in Chinese), read November 11, 2026, https://open.bilibili.com/doc/4
3. Bilibili Open Platform, management rules, in force July 29, 2022 (in Chinese), read November 11, 2026, https://open.bilibili.com/agreement/management-protocol
4. Bilibili Open Platform, developer service agreement (in Chinese), read November 11, 2026, https://open.bilibili.com/agreement/developer-service
5. Bilibili Open Platform, privacy policy (in Chinese), read November 11, 2026, https://open.bilibili.com/agreement/privacy-policy
6. Bilibili Open Platform, details of one video (in Chinese), read November 11, 2026, https://open.bilibili.com/doc/4/d9554788-dcef-f139-6217-b487d41c3826
7. Bilibili Open Platform, growth data across all videos (in Chinese), read November 11, 2026, https://open.bilibili.com/doc/4/708a4ce5-5a6e-d8ce-b2e8-ff8a26a83b05
8. Bilibili Open Platform, data for one video (in Chinese), read November 11, 2026, https://open.bilibili.com/doc/4/3f46ac2e-1318-3aa0-5548-0d9fd624d520
9. Bilibili Open Platform, OAuth 2.0 guide (in Chinese), read November 11, 2026, https://open.bilibili.com/doc/4/eaf0e2b5-bde9-b9a0-9be1-019bb455701c
10. Bilibili Open Platform, signature standard and status codes (in Chinese), read November 11, 2026, https://open.bilibili.com/doc/4/8673959e-f7bb-56e6-6e68-d225f971b81b
11. Bilibili Open Platform, basic public user information (in Chinese), read November 11, 2026, https://open.bilibili.com/doc/4/feb66f99-7d87-c206-00e7-d84164cd701c
12. GitHub, bilibili-openplatform/SignatureAlgorithm_DotnetDemo, read November 11, 2026, https://github.com/bilibili-openplatform/SignatureAlgorithm_DotnetDemo
13. Bilibili live open platform, long-connection protocol (in Chinese), read November 11, 2026, https://open-live.bilibili.com/document/657d8e34-f926-a133-16c0-300c1afc6e6b
14. Bilibili, user agreement, in force May 7, 2025 (in Chinese), read November 11, 2026, https://www.bilibili.com/protocal/licence.html
15. Bilibili, robots.txt, read November 11, 2026, 00:23 Singapore time, https://www.bilibili.com/robots.txt
16. GitHub, Nemo2011/bilibili-api README with the notice of July 6, 2026 (in Chinese), read November 11, 2026, https://github.com/Nemo2011/bilibili-api
17. PyPI, bilibili-api-python 17.4.2, June 19, 2026, https://pypi.org/project/bilibili-api-python/
18. GitHub, SocialSisterYi/bilibili-API-collect README on the lawyer letter of January 28, 2026 (in Chinese), read November 11, 2026, https://github.com/SocialSisterYi/bilibili-API-collect
19. GitHub, pskdje/bilibili-API-collect, read November 11, 2026, https://github.com/pskdje/bilibili-API-collect
20. GitHub, nilaoda/BBDown README, read November 11, 2026, https://github.com/nilaoda/BBDown
21. GitHub, Vespa314/bilibili-api, read November 11, 2026, https://github.com/Vespa314/bilibili-api
22. GitHub, xfgryujk/blivedm README, read November 11, 2026, https://github.com/xfgryujk/blivedm
23. GitHub, yt-dlp/yt-dlp, read November 11, 2026, https://github.com/yt-dlp/yt-dlp
24. GitHub, yt-dlp issue #17847, October 17, 2026, https://github.com/yt-dlp/yt-dlp/issues/17847
25. GitHub, yt-dlp issue #17879, October 21, 2026, https://github.com/yt-dlp/yt-dlp/issues/17879
26. GitHub, yt-dlp issue #17890, October 22, 2026, https://github.com/yt-dlp/yt-dlp/issues/17890
27. GitHub, yt-dlp issue #17894, October 22, 2026, https://github.com/yt-dlp/yt-dlp/issues/17894
28. GitHub, yt-dlp pull request #17898, October 22, 2026, https://github.com/yt-dlp/yt-dlp/pull/17898
29. GitHub, NanmiCoder/MediaCrawler README, read November 11, 2026, https://github.com/NanmiCoder/MediaCrawler
30. GitHub, MediaCrawler pull request #1000, opened November 4 and merged November 5, 2026, https://github.com/NanmiCoder/MediaCrawler/pull/1000
31. EveryInfra, data API catalog, read November 11, 2026, 00:13 Singapore time, https://api.everyinfra.com/api/v1/social/catalog
32. requests documentation, Advanced Usage: Session Objects, read November 11, 2026, https://requests.readthedocs.io/en/latest/user/advanced/#session-objects
33. PyPI, requests 2.34.2, May 14, 2026, https://pypi.org/project/requests/
34. Python documentation, bisect, read November 11, 2026, https://docs.python.org/3/library/bisect.html
35. Python documentation, collections.Counter, read November 11, 2026, https://docs.python.org/3/library/collections.html#collections.Counter
36. Python documentation, hmac, read November 11, 2026, https://docs.python.org/3/library/hmac.html
37. Cyberspace Administration of China, Personal Information Protection Law (in Chinese), August 20, 2021, https://www.cac.gov.cn/2021-08/20/c_1631050028355286.htm
38. China National Intellectual Property Administration, Anti-Unfair Competition Law, 2025 revision (in Chinese), posted May 20, 2026, https://www.cnipa.gov.cn/art/2026/5/20/art_104_206437.html
39. Ministry of Ecology and Environment, repost of State Council Decree No. 790, Network Data Security Management Regulations (in Chinese), October 3, 2024, https://www.mee.gov.cn/zcwj/gwywj/202410/t20241003_1087417.shtml
40. Cyberspace Administration of China, Cybersecurity Law, text in force from January 1, 2026 (in Chinese), December 29, 2025, https://www.cac.gov.cn/2025-12/29/c_1768735112911946.htm
41. Cyberspace Administration of China, decision to amend the Cybersecurity Law (in Chinese), October 29, 2025, https://www.cac.gov.cn/2025-10/29/c_1763461514768457.htm