Bilibili Scraper - Chinese Video Intelligence

The most-used Bilibili scraper on Apify (Apify public stats) · ~900 unique videos per keyword with no cookie (measured: 914).

Extract Chinese Gen-Z and millennial consumer sentiment, video engagement, and danmaku reaction data from Bilibili (哔哩哔哩) — China's YouTube with 300M+ monthly active users producing a dense youth-culture signal. Built for AI training corpora, Chinese consumer equity research (gaming/anime/EV/streaming), brand monitoring agencies, and academic NLP teams. No login, no API key, no VPN.

Pure HTTP — fast and cheap. No browser, no proxy.

💡 Tracking a brand, not just scraping one platform? Pair this with two recurring monitors that watch the whole picture for you: Chinese Brand Monitor — Weibo + RedNote + Bilibili + Douban + Xueqiu mentions in one scheduled, deduped, sentiment-tagged feed — and AI Brand Visibility Monitor — how the AI engines (DeepSeek, Qwen, Kimi, GLM + ChatGPT/Gemini/Claude) answer about your brand.

How to scrape Bilibili in 3 easy steps

1. Go to the Bilibili Scraper page on Apify and click "Try for free"
2. Configure your input — choose a mode (search, video_detail, video_comments, user_videos, user_profile, or popular), enter your keywords, video URLs or creator ids, and set the number of results
3. Click "Run", wait for the scraper to finish, then download your data in JSON, CSV, or Excel format

No coding required. No API key. Works with Apify's free plan.

Need more than the first ~1,000 videos for a keyword? Bilibili caps one search query at ~1,000 results. When a keyword reaches that cap and your maxResults asks for more (it accepts up to 5,000), search keeps going (with deltaMode off, the default): it re-asks the same keyword for date windows, newest first, until it has the rows you asked for or something stops it — and the run card names what did. Following creators rather than keywords? user_profile returns one row per creator: followers, following, video count, total likes, level, verification and bio. → User profiles

🆕 Chinese Brand Monitor — Cross-platform brand mention aggregator (Weibo + RedNote + Bilibili + Douban + Xueqiu in one normalized feed, sentiment + dedup, $0.06/mention). Pairs perfectly with this Actor: this Bilibili scraper gives you deep video metrics, comments, and danmaku; the brand monitor gives you cross-platform consumer sentiment on the same brands across 5 platforms in one call.

Chinese Digital Intelligence Suite by Zhorex: Bilibili (video) + Weibo (microblog) + RedNote/Xiaohongshu (lifestyle) + RedNote Shop (e-commerce) + Douban (long-form reviews) + Xueqiu (stock-discussion sentiment) + JD.com (e-commerce product detail).

Who buys this scraper

Buyer profile	Use case	Typical spend
AI / LLM training data teams	Chinese video comments + danmaku as conversational training data for SFT/RLHF, plus Gen-Z slang corpus for sentiment classifiers	$200-1,000/mo
Hedge fund / equity research desks	Bilibili reaction sentiment on consumer brands (Pop Mart, BYD, Anta, gaming/anime IPs) — Gen-Z leading indicator	$100-400/mo
Brand monitoring agencies	Track Western brand mentions, viral reactions, and creator partnerships in Chinese youth-culture content	$200-600/mo
Gaming / entertainment industry	Monitor Chinese reception of game launches, anime adaptations, streaming releases	$300-800/mo
Influencer / KOL agencies	Find Bilibili creators by niche, vet engagement (favorites/likes; coins via video_detail), track audience growth (user_profile on a schedule: followers, videos, total likes, verification per creator)	$50-200/mo
Academic NLP / sociology researchers	Chinese youth-language corpus, danmaku behavior studies, Gen-Z cultural research	$30-150/mo

🆕 Get the comments, not just the videos. Turn on includeComments and every video found in search / user_videos / popular also returns its comment thread — one row per comment (type: comment) with likeCount, replyCount and author. The video is the prompt; the replies are the audience. No login or cookie needed.

Every comment is a billed row, and each video returns up to maxComments of them: a 3-video search is 3 rows with it off, against 3 + up to 60 rows (up to $1.26) at maxComments: 20. It multiplies rows and cost — 100 videos × 20 comments is ~2,100 rows instead of 100 — so it is off by default and capped by maxComments.

📈 maxResults now goes to 5,000 per run (was 500), and maxComments to 1,000. Defaults are unchanged, so nothing about your existing runs or bill changes unless you raise them yourself.

🆕 Danmaku profiles — the metric Bilibili has and YouTube does not

Danmaku (弹幕) is Bilibili's scrolling on-video commentary: comment text bound to a specific second of the video. A normal comment tells you what someone thought about a video; a danmaku tells you what they thought at 04:32 — which is what makes second-by-second audience reaction measurable at all.

Turn on includeDanmaku and every video also returns one type: danmaku row:

Field	What it tells you
danmakuFetched	how many danmaku Bilibili keeps in the video's pool — capped (one measured video: 3,600 kept of 4,542); see danmakuTotal and danmakuPoolCapped
danmakuTotal	the video's own danmaku count as Bilibili reports it — single-part videos only, null on multi-part uploads (there the count covers every part, the pool only the first)
danmakuPoolCapped	true when fewer danmaku were fetched than danmakuTotal, so the metrics below describe the kept pool, not every danmaku ever sent (null when there is no total to compare)
danmakuUniqueSenders	how many distinct people wrote them — reach, not just volume
danmakuPerMinute	reaction rate over the fetched pool — on capped videos (danmakuPoolCapped: true) it understates long, busy videos
danmakuPeakMinute + danmakuPeakMinuteCount	which minute the audience reacted to — the answer a brand wants about its ad or launch
danmakuFirstAt / danmakuLastAt	whether engagement holds to the end or dies after the intro
danmakuRateBasisSecs	the duration the rate was computed over, so you can audit it
danmakuSample	danmaku texts spread evenly across the timeline (not the first N, which would all be from the opening seconds)

Two real videos from one search, so you can see the spread:

3,600 danmaku · 1,664 unique senders · 203.51/min · peak at minute 0 (506)
  189 danmaku ·                         13.14/min · peak at minute 0 (115)

Same topic, same query — and a 15x difference in reaction rate. That gap is the whole point for creator vetting: view counts would not have told you which of those two videos an audience actually engaged with.

No login, no cookie, no browser. Uses Bilibili's public danmaku track.

Price: $0.05 per danmaku profile — one video, one priced row. It is only charged when you switch includeDanmaku on, which is off by default.

Why one row and not thousands. A video's danmaku pool holds thousands of danmaku (3,600 on one measured video). Billing per danmaku would invoice tens of dollars for one video, so instead you get the aggregate signal plus a sample inside a single row — and danmakuSampleSize (default 25, max 500) rides inside that row without adding billable rows. At $0.05, profiling 200 videos costs $10.

Fan-out limit: a run profiles at most 200 videos (it costs two requests per video). If your run returns more, the log and the run card say exactly how many were left unprofiled — split the run or lower maxResults to cover the rest. In a deltaMode search or popular monitor the videos left unprofiled are saved as seen and later runs skip them, so run it more often instead. Nothing is silently truncated. Worth knowing since the deep search below: a search run can now return up to maxResults (5,000) videos rather than stopping near 1,000, so the 200 that get a danmaku profile are a much smaller slice of it than they used to be. includeComments has no such cap — it fans out over every video the run returned, so at that volume it is your run's charge limit, not a fan-out ceiling, that decides how far it gets, and the run card says when that limit stopped delivery.

Need one row per danmaku for corpus building? Open an Issue titled "danmaku firehose" — it is built and waiting on its own per-row price.

User profiles (KOL / creator monitoring)

user_profile mode returns one row per creator — followers, following, number of videos, total likes, level, verification and bio — for a list of creator ids. It is one request per creator to Bilibili's public profile card, the one user_videos already reads: no login, no cookie, no search, so a creator's row does not depend on how crowded their name is.

{
    "mode": "user_profile",
    "userIds": ["546195", "https://space.bilibili.com/456664753", "UID:25876945"],
    "maxResults": 100
}

userIds takes the same forms as in user_videos: the number, the space.bilibili.com/<mid> link, or UID:<mid>; duplicates are fetched once, in your order. maxResults caps how many profiles a run returns, so set it to at least the length of your list — the run card says how many creators were left out by it, if any.

Example row — 老番茄, a snapshot taken on 24 Sep 2026 (the numbers move every day):

{
    "type": "user",
    "mid": 546195,
    "name": "老番茄",
    "face": "http://i0.hdslb.com/bfs/face/...",
    "sign": "新浪微博：_老番茄_",
    "level": 6,
    "fans": 20792055,
    "friend": 6,
    "attention": 6,
    "isOfficial": true,
    "officialDesc": "2025百大UP主、2025年度商业影响力奖UP主、2022年度联合创作奖UP主",
    "archiveCount": 677,
    "likeCount": 194953629,
    "profileUrl": "https://space.bilibili.com/546195",
    "followers": 20792055,
    "following": 6,
    "videoCount": 677,
    "totalLikes": 194953629,
    "officialTitle": "2025百大UP主、2025年度商业影响力奖UP主、2022年度联合创作奖UP主",
    "officialRole": 1,
    "scrapedAt": "2026-09-24T07:00:45+00:00"
}

• The row carries every field of the user_videos profile row under the same names (fans, attention, archiveCount, likeCount…), plus followers, following, videoCount and totalLikes — the same four numbers under plain names — and officialTitle / officialRole.
• isOfficial is true for both kinds of Bilibili verification, a person's and an organisation's. officialRole is Bilibili's own verification-role code, passed through as served: 老番茄 is 1 (an individual creator), 央视新闻 (mid 456664753) is 5 (a media organisation), both measured on 24 Sep 2026. officialTitle is the verification text shown on the profile, empty when the creator is not verified.
• A number Bilibili does not report is null, never a made-up 0.
• An id Bilibili has no profile for returns no row and is not charged; the run card names it. So is any entry that is not a creator id at all.
• If Bilibili's risk control starts refusing the requests (including HTTP 429, "too many requests"), the run stops there, delivers and bills only the profiles it fetched, and the run card says how many creators were not fetched so you can re-run for them.
• A request that fails for any other reason — a network error, an HTTP error such as 503, an unreadable answer — is not reported as a missing profile: the run card names those creators with what Bilibili answered, so you know to re-run for them rather than to check the id. No row, no charge.

Track follower growth: save the input as a Task and attach an Apify Schedule — daily or weekly. Every run is a fresh snapshot of each creator (deltaMode does not apply to this mode and is ignored), so joining the rows by mid across runs gives you each creator's follower, video and like curves. The Creator profiles view of the dataset shows these columns.

Price: $0.02 per creator profile delivered — the normal item-scraped row price. 100 creators checked once a week is $2 a week.

What is Bilibili?

Bilibili is a major Chinese video platform, known for anime, gaming, tech content, and education. Unlike YouTube, Bilibili features danmaku (弹幕) — real-time scrolling comments that overlay the video. With 300M+ monthly active users, it's where Chinese Gen Z and millennials consume and create content.

Bilibili-specific data points this actor captures:

• Danmaku count (弹幕) — live scrolling comments overlaid on videos
• Coin count (投币) — Bilibili's tipping system where users "throw coins" at creators (in video_detail and popular; the search endpoint does not return it)
• Favorite count (收藏) — equivalent to "save" on other platforms
• Standard metrics: views, likes, replies; shares in video_detail and popular

Bilibili API alternative

There is no official public Bilibili API available for international developers. Bilibili's developer platform requires Chinese phone verification and is rate-limited. This Bilibili Scraper is an alternative — it handles all the complexity for you, returns structured data, and requires zero authentication. Extract videos, comments, full danmaku profiles (reaction rate, peak minute, timeline samples), and creator analytics with a single Actor call.

What can this actor do?

Mode	Description	Input needed
search	Search videos by keyword (Chinese or English) — supports deltaMode for a "new videos only" recurring keyword monitor	Search query
video_detail	Full video info with all engagement metrics	Video URLs or BVIDs
video_comments	Comments with author info and likes	Video URLs or BVIDs
user_videos	A creator's recent videos, found by searching their channel name and keeping the videos whose mid matches — Bilibili gates the direct space listing behind its risk control, which refuses plain HTTP requests from any egress (re-verified 2026-08-20 across three residential exits). That search is read by date first, and what matches there are the creator's newest uploads — measured 2026-09-24: 极客湾Geekerwan's 10 newest (31 Aug to 23 Sep) on the first page, 央视新闻's 9 uploads of that day on the first two. When other people's videos crowd it, as they do for a famous name (老番茄, mid 546195: 0 of the first 20 by date are his), the rest come from the relevance-ranked search, which favours the creator's best-known videos and can skip recent uploads (老番茄: 18 of the first 20 are his, dated 2019 to 2026; about 20 over the first three pages). Everything is delivered newest first, deduplicated, and the run status names each creator whose videos came from that fallback or who came up short, and why. Not a complete upload list: at most 10 search pages are read per creator. Use search with the creator name if you need to go wider	User IDs (mid), or their space.bilibili.com/<mid> links
user_profile	One row per creator: followers, following, video count, total likes, level, verification and bio — one profile request per creator, no search. Schedule it to track follower growth. See User profiles	User IDs (mid), or their space.bilibili.com/<mid> links
popular	Trending/popular videos, filterable by category — supports deltaMode for a "newly trending only" recurring feed	Optional category filter

🆕 Auto-localize brand search (on by default). Bilibili indexes by Chinese text, so 耐克 returns more videos than Nike. With autoLocalize on, searching a common Latin brand name automatically also searches its Chinese name and merges + dedupes the results — full native recall even when you search in English, capped at maxResults (no extra cost). For brands outside the built-in dictionary, add the Chinese term via searchAliases. (Few results for an English keyword usually means the language, not an error.)

🆕 Sentiment scoring (optional): set sentimentAnalysis: true to tag each item with Chinese sentiment — polarity (positive/neutral/negative) + a −1.0…+1.0 score. Scores comment text and video titles/descriptions; ideal in video_comments mode for Gen-Z reaction analysis. Loads a model, so run with memory ≥512 MB when enabled.

Bilibili categories

Animation (动画), Music (音乐), Dance (舞蹈), Gaming (游戏), Knowledge (知识), Tech (科技), Sports (运动), Cars (汽车), Life (生活), Food (美食), Animal (动物圈), Fashion (时尚), Entertainment (娱乐)

Use cases by buyer

• Chinese AI training corpus — extract video comments + danmaku + creator descriptions as conversational training data for Chinese LLMs and youth-language sentiment classifiers
• Equity research alt-data — Bilibili reaction sentiment on Chinese consumer brands as Gen-Z leading indicator (Pop Mart, BYD, Anta, gaming/anime/EV-stock signal)
• Gaming / anime brand monitoring — Track Chinese reception of game launches and anime adaptations in a large Chinese fan community
• Content research — Analyze trending topics in Chinese youth culture and Gen Z interests
• Creator analytics — Evaluate Bilibili KOLs by engagement metrics (favorites/likes; coins via video_detail) for partnerships and sponsorships
• Ad placement research — Understand which categories and content types perform best
• Academic research — Study Chinese digital culture, danmaku behavior, and youth language trends
• Market intelligence — Monitor product launches, brand mentions, and competitor content in China

Scrape Bilibili with Python, JavaScript, or no code

You can use the Bilibili Scraper directly from the Apify Console (no code), or integrate it into your own scripts with Python or JavaScript.

Python

from apify_client import ApifyClient

client = ApifyClient("YOUR_API_TOKEN")
run = client.actor("zhorex/bilibili-scraper").call(run_input={
    "mode": "search",
    "searchQuery": "人工智能教程",
    "maxResults": 50
})
for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(item)

JavaScript

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: 'YOUR_API_TOKEN' });
const run = await client.actor('zhorex/bilibili-scraper').call({
    mode: 'search',
    searchQuery: '人工智能教程',
    maxResults: 50,
});
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => console.log(item));

Using the raw REST API (Postman / curl)

⚠️ The run endpoint is asynchronous — its response is the run object (IDs + status), NOT your scraped data. If you POST to /acts/.../runs you get back something like { "data": { "status": "READY", "defaultDatasetId": "…" } } with no results in it — that's expected, the run hasn't finished yet. The records land in the run's dataset, not in that response. (The containerUrl link is the live container; once a run finishes it just shows "run has already finished with status SUCCEEDED" — that means success, it is not where the data lives.)

Easiest — one call that waits for the run and returns the records directly:

curl -X POST "https://api.apify.com/v2/acts/zhorex~bilibili-scraper/run-sync-get-dataset-items?token=YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"mode":"search","searchQuery":"人工智能教程","maxResults":50}'

The response body is the JSON array of records — no second call needed.

Or async — start the run, then fetch the dataset once it finishes:

# 1) start the run — note the "defaultDatasetId" in the response
curl -X POST "https://api.apify.com/v2/acts/zhorex~bilibili-scraper/runs?token=YOUR_API_TOKEN" \
  -H "Content-Type: application/json" -d '{"mode":"search","searchQuery":"人工智能教程","maxResults":50}'

# 2) when the run status is SUCCEEDED, fetch the records from its dataset
curl "https://api.apify.com/v2/datasets/DEFAULT_DATASET_ID/items?token=YOUR_API_TOKEN"

💡 In the Apify Console you can also open any run and click the Output / Storage → Dataset tab to view and download the same data as JSON / CSV / Excel.

Comment threads — includeReplies

A comment run returns up to maxComments top-level comments per video, in Bilibili's own popular order (20 per page, paged). Each root also carries its replies — and those are what includeReplies turns into rows.

Each of those root comments arrives carrying some of its own replies in the same response. Turn on includeReplies and every reply becomes its own row, tagged with rootRpid and isThreadReply so you can rebuild the conversation.

Where the replies come from. Each root arrives carrying any replies Bilibili chose to inline, and declares its true total in replyCount. The flag reads the inline ones and pages the rest, one request per root thread, until your maxComments is met.

How much it adds. It depends on the video: popular roots carry real threads (one measured root declared 30 replies and 10 came back on the first page), quiet ones declare none, and then the flag makes no extra request and adds no rows. Earlier builds looked empty here for a different reason — the comment request carried visitor cookies, which made Bilibili answer with only ~3 roots; that is fixed since build 1.3.86 (2026-09-16).

Two things worth knowing before you turn it on: replies bill as ordinary comment rows, so your bill grows with them — cap it with maxComments; and some videos have comments closed, so they return none at all (1 of the 3 videos in the run measured on 2026-09-16). Off by default.

Follow-up comments on earlier videos — followUpComments (off by default, charged per row)

For a scheduled search monitor with deltaMode and includeComments on. A delta run reads each video's comments once, when it first finds the video — usually hours after upload, while the thread is still growing (in a brand search saved on 26 Sep 2026, videos 6-24 h old had 3.7 comments on average, median 1) — and never again, because the video is "seen" from then on.

With followUpComments: true, the videos each delta run delivers are remembered — in a record of their own beside the deltaStateKey's list of seen videos, which is left as it was — with the time of the newest comment delivered for each, and a later delta run re-reads each comment thread once: on the first run at least 24 hours after the video was published and 12 hours after it was delivered, before it is 7 days old, newest videos first.

• What comes back: only comments posted after the newest comment already delivered for that video (all of them if none was), as ordinary comment rows (type: comment, linked by videoBvid) marked isFollowUp: true, up to maxComments per video, ordered like your other comment rows (sortComments), with includeReplies adding the replies Bilibili inlines in the same response. "Newer" is by posting time, not comment id: Bilibili numbers comments from more than one range at once, so a newer comment can carry a lower id.
• What it costs: each comment row is one result, charged like a video ($0.02); a thread with no new comments adds nothing. Never more rows than the run's charge limit can pay for.
• Limits per run: at most 200 threads, 300 comment requests and about 4 minutes of re-reading, one thread at a time, reading at most 5 pages of each thread (100 top-level comments). Videos not reached keep their place for the next run, and the status message counts them. If Bilibili's risk control refuses a request, the re-reads stop for that run without retrying. A run takes up to ~4 minutes longer, so keep the schedule interval longer than a run lasts.
• What it does not do: comments older than the newest one delivered for a video (those past maxComments when the video was first read) are not fetched, and it starts with the videos delivered from the first run with this on. Each video gets one re-read: a thread cut short by a run limit or the charge limit is finished on a later run (only comments not yet delivered, and never more than maxComments for the video in all); a re-read that fails is tried on later runs and the video leaves the queue after its second failed run; and if a run stops part-way through its re-reads (timeout, abort, restart), the videos it was re-reading are not re-read again, so no comment is delivered or charged twice. In any other mode, or without deltaMode or includeComments, it does nothing and the status message says so.

Input examples

Search videos

{
    "mode": "search",
    "searchQuery": "人工智能教程",
    "maxResults": 50
}

Brand search with auto-localize — searches Nike and 耐克 automatically (plus any searchAliases), merged and deduped, capped at maxResults:

{
    "mode": "search",
    "searchQuery": "Nike",
    "searchAliases": ["AJ"],
    "maxResults": 100
}

Search videos with filters (v1.1+)

Sort by newest, views, danmaku, favorites, or comments. Filter by duration and publish date range.

{
    "mode": "search",
    "searchQuery": "AI",
    "sortOrder": "pubdate",
    "durationFilter": "medium",
    "pubtimeBegin": "2026-01-01",
    "pubtimeEnd": "2026-04-15",
    "maxResults": 100
}

Sort orders:

• totalrank — Relevance (default)
• click — Most views first
• pubdate — Newest first
• dm — Most danmaku
• stow — Most favorites
• scores — Most comments

Duration filters: any, short (<10min), medium (10-30min), long (30-60min), verylong (>60min)

Date filters: pubtimeBegin / pubtimeEnd accept YYYY-MM-DD, YYYY/MM/DD, YYYYMMDD, YYYY-MM-DD HH:MM[:SS] and ISO 8601 date-times such as 2026-04-15T10:30:00Z or 2026-04-15T18:30:00+08:00. No zone means UTC, and a bare date is 00:00 UTC that day — so "pubtimeEnd": "2026-04-15" stops at the start of the 15th; use 2026-04-15T23:59:59Z to include it. A value the Actor cannot read (15-04-2026, -7d) is not applied, and the run status says so. The run status also names a date before 1970 (a mistyped year such as 1026-04-15) and a pubtimeBegin that is not earlier than pubtimeEnd. A result Bilibili returns without a publish date is not delivered or charged when you set either date, because it cannot be checked against them.

Video details

{
    "mode": "video_detail",
    "videoUrls": [
        "https://www.bilibili.com/video/BV1bmTb6EEs8",
        "BV1xx411c7mD"
    ]
}

Video comments

{
    "mode": "video_comments",
    "videoUrls": ["https://www.bilibili.com/video/BV1bmTb6EEs8"],
    "maxComments": 50,
    "sortComments": "hot"
}

Sort options:

• hot — top/most-liked comments first (default)
• time — newest comments first
• likes — sorted by like count descending

User/creator videos

{
    "mode": "user_videos",
    "userIds": ["546195", "1340190821"],
    "maxResults": 30
}

Find a user's mid in their profile URL: space.bilibili.com/{mid} — pasting the link itself works too (a channel name does not, and the run status names any entry it could not read as a mid). Multiple users are processed in parallel (up to 3 concurrent). Each user's dataset output starts with a user profile item followed by their video items.

Popular/trending videos

{
    "mode": "popular",
    "category": "game",
    "maxResults": 20
}

Trending-delta feed (new in v1.3.42) — add deltaMode and each scheduled run returns only videos newly trending since the last run (per category + deltaStateKey):

{
    "mode": "popular",
    "category": "all",
    "deltaMode": true,
    "deltaStateKey": "trending-daily",
    "maxResults": 50
}

⏰ Set up daily monitoring in 2 minutes

Most of this Actor's value is in recurring runs, not one-off pulls. A daily (or hourly) schedule turns a single query into a continuously-updated Gen-Z video / creator-reaction feed — and that's where pay-per-result compounds: you wake up to fresh data every morning instead of re-running by hand.

1. Choose between the full result set and new videos only. With deltaMode off (the default), each run returns the full current result set for your input. With deltaMode: true + a distinct deltaStateKey (e.g. "nike-weekly"), in search or popular mode, each run returns only videos that no earlier run with that key returned (deduped by video ID; popular keeps a separate state per category) — on a fast-moving board that is still a batch every run, on a narrow keyword it can be a handful of rows or none. If you use it in search, also set sortOrder: "pubdate" (Newest first). Each deltaStateKey remembers up to 200,000 video IDs. A remembered video that shows up on a result page a later run reads counts as seen again, so the IDs forgotten first are the ones that have been off those pages the longest: a video is delivered again only if it reappears after 200,000 other videos have been delivered or seen since it last showed up on a page a run read (at 2,500 new videos a day, more than two months). A run stops reading a keyword after a few pages in a row with nothing new, so once the memory is full a video still ranking below that point can come back as new. Give each scheduled task its own deltaStateKey: two runs on one key at the same time can each deliver a video the other also found.
2. Run it once and check the output looks right. (With deltaMode on, the first run returns everything and sets the baseline; every run after it returns only what's new.)
3. Apify Console → Schedules → Create → pick this Actor and your saved input, then set a cron — e.g. 0 8 * * * = daily at 8am, or 0 * * * * = hourly. (Shortcut: open any finished run and click Schedule to pre-fill the input.) Enable email-on-failed-run so you're alerted if anything breaks.

Each scheduled run saves its results in its own dataset. For one continuously growing history, connect an integration or webhook (e.g. Google Sheets or your warehouse) or export each run.

📈 Good for tracking a brand or creator and their new videos + reactions over time — watch how sentiment, danmaku, and engagement on a topic shift day over day.

🧠 Need this at AI-training-corpus scale?

If you're pulling Bilibili video comments, danmaku, and creator descriptions to train or fine-tune Chinese-language models, the Chinese AI Training Corpus Engine assembles all 5 Chinese platforms — Weibo, Bilibili, Xueqiu, Douban, and RedNote — into AI-ready documents in one run: deduplicated, quality-scored, PII-scrubbed, and provenance-stamped (source URL, license hint, content hash) for EU AI Act documentation. From $0.025/doc, and rejects and duplicates are never charged.

📦 Want the full China feed? — China Monitoring Packages

Bilibili is one platform. If you're monitoring a brand across Chinese social, three pre-configured bundles combine this Actor with the Chinese Brand Monitor (Weibo + RedNote + Bilibili + Douban + Xueqiu in one normalized feed), the AI Brand Visibility Monitor and the Xueqiu Scraper into set-and-forget recurring monitors — entirely self-serve on your own Apify account:

• Brand Starter (~$110/mo) — 1 brand, daily 5-platform mention delta + weekly AI-answer visibility.
• Competitive Intel (~$440/mo) — you + 3 competitors, daily share-of-voice, viral-breakout flags, weekly AI gap table.
• Fund Signal Desk (~$635/mo) — 10 tickers, daily sentiment-velocity feed + hourly Xueqiu quotes.

For context: enterprise listening suites are sold on annual contracts; these are pay-per-event only, no contract. Each package is just saved Tasks + Schedules: copy the preset, Save as task, attach a schedule, done. Questions: the Issues tab (text support).

Output example

Video output

{
    "type": "video",
    "bvid": "BV1YXDfBUETP",
    "aid": 116379604749273,
    "title": "Example Video Title",
    "description": "Video description...",
    "url": "https://www.bilibili.com/video/BV1YXDfBUETP",
    "thumbnailUrl": "https://i0.hdslb.com/bfs/...",
    "duration": 167,
    "durationFormatted": "2:47",
    "viewCount": 1570113,
    "likeCount": 182455,
    "coinCount": 110535,
    "favoriteCount": 63471,
    "shareCount": 45918,
    "danmakuCount": 7466,
    "replyCount": 17276,
    "authorName": "Creator Name",
    "authorMid": 1340190821,
    "publishDate": "2026-04-08T12:00:00+00:00",
    "publishTimestamp": 1775822400,
    "category": "单机游戏",
    "tags": ["anime", "action", "review"],
    "scrapedAt": "2026-04-10T10:00:00+00:00"
}

coinCount and shareCount come from video_detail and popular; the search endpoint does not return them, so they are null in search and user_videos (never a made-up 0).

category is Bilibili's zone name exactly as the source spells it (Chinese, e.g. 单机游戏): from the search results in search and user_videos, and from the trending feed in popular (empty if the feed leaves it blank). In video_detail it is an empty string: Bilibili's video-detail endpoint currently returns the zone name blank and only a numeric zone id (checked 2026-09-21), and the Actor does not guess a name from the id.

In video_detail mode, tags are populated from Bilibili's tag endpoint. In search and user_videos modes, tags come from the search response (comma-separated list). In popular mode, tags is always an empty list (the popular endpoint doesn't include tag data).

Comment output

{
    "type": "comment",
    "commentId": 295779210449,
    "text": "Comment text in Chinese...",
    "likeCount": 10010,
    "replyCount": 42,
    "createdAt": "2026-04-08T10:00:00+00:00",
    "createdTimestamp": 1775822400,
    "authorName": "Username",
    "authorMid": 12345678,
    "authorAvatar": "https://i0.hdslb.com/bfs/face/...",
    "authorLevel": 6,
    "videoBvid": "BV1YXDfBUETP",
    "scrapedAt": "2026-04-10T10:00:00+00:00"
}

Sentiment field (optional)

With sentimentAnalysis: true, each item gains a sentiment object (scored from comment text, or video title + description):

{
    "polarity": "negative",
    "score": -0.36,
    "method": "snownlp"
}

polarity ∈ positive / neutral / negative · score ∈ −1.0…+1.0 (higher = more positive) · method is snownlp for Chinese text, or keyword for the English-only fallback.

User profile output (user_videos mode)

When you use user_videos mode, the dataset contains one user profile item per creator followed by their video items. Only videos whose authorMid is that creator's mid are returned. The profile row bills as one item, and only when at least one of that creator's videos is delivered — a creator with no videos found gets the profile row free:

{
    "type": "user",
    "mid": 546195,
    "name": "老番茄",
    "face": "https://i0.hdslb.com/bfs/face/...",
    "sign": "User bio / signature",
    "level": 6,
    "fans": 20189060,
    "friend": 5,
    "attention": 5,
    "isOfficial": false,
    "officialDesc": "",
    "archiveCount": 652,
    "likeCount": 0,
    "profileUrl": "https://space.bilibili.com/546195",
    "scrapedAt": "2026-04-10T10:00:00+00:00"
}

Pricing

This actor uses Apify's pay-per-event pricing:

Event	Price	What it is
1 item scraped	$0.020	A video, a comment, a creator record (in user_videos, billed only when at least one of the creator's videos is delivered), a creator profile in user_profile
1,000 items	$20.00
1 danmaku profile	$0.050	One video's danmaku pool (as Bilibili keeps it, capped) as a reaction profile — count fetched vs the video's total, unique senders, per-minute rate, peak minute, timeline sample. Only charged with includeDanmaku on (off by default).

A danmaku profile costs more than an item because it is not one: it is the video's danmaku pool — thousands of danmaku — fetched, parsed and reduced to the numbers you act on, delivered as a single row instead of thousands. Profiling 200 videos costs $10.

Typical costs (small-scale):

• 40 trending videos snapshot: ~$0.80
• 30 video details with full metadata: ~$0.60
• User profile + 20 videos: ~$0.42 (21 billed rows)
• 100 creator profiles (user_profile): $2.00

B2B / bulk-scale examples:

• AI training corpus (10,000 video comments on a topic): ~$200
• Daily brand sentiment monitor (500 items/day for a month): ~$300/month
• Gen-Z product launch reception study (2,000 videos + 10,000 comments): ~$240
• Multi-creator KOL database (100 creators + their recent videos): ~$120

Technical details

• No browser needed — uses Bilibili's public HTTP APIs
• No proxy needed — Bilibili is accessible globally (some licensed content may be geo-restricted)
• No API key needed — all endpoints are public
• 1024 MB default memory — plain HTTP, no browser
• Chinese text preserved — all content returned as-is in original language
• Concurrent fetching — optimized for speed:
  • video_detail: up to 5 videos fetched in parallel, each with detail + tags fetched concurrently
  • video_comments: up to 3 videos processed in parallel
  • user_videos: up to 3 users processed in parallel
  • user_profile: up to 3 profile requests at a time, with a short pause between batches
• Consistent schema — every documented field is present on every row; counters a mode's source does not provide are null, never a made-up 0 (coinCount / shareCount are null in search and user_videos).

Performance

Indicative run times on Apify (not re-measured; default 1024 MB, no proxy):

Mode	Input	Duration	Throughput
search	max=30	~5-6s	~5 items/s
search	max=50	~7-8s	~7 items/s
popular	max=40	~5s	~8 items/s
video_detail	10 BVIDs	~5s	~2 items/s (incl. tag enrichment)
video_comments	2 videos	~4s	—
user_videos	3 users, max=15	~4s	~4 items/s

Limitations

• Search depth: Bilibili caps one query at ~1,000 results (its own payload says numResults: 1000, numPages: 50), so a keyword sweep stops there. When a query hits that ceiling and your maxResults asks for more, the run re-asks the same keyword for date windows, each one a separate query with its own ~1,000-result cap: it takes the videos published on or before a date newest first, and moves that date down to the oldest video each window returned, until you have the rows you asked for or one of the guards below stops it. Where it starts depends on your sortOrder: with pubdate the first pass is already newest-first, so the walk continues from the oldest video it returned; with any other sort the first pass is a relevance sample spread across the whole history, so its oldest row says nothing about what has been covered and the walk starts at the top instead — your pubtimeEnd, or today — and sweeps down, skipping what you already have. Videos you already have are never returned or charged twice. The run card says how many windows it used and the real published-date span you got. Three honest limits: each window is itself capped at ~1,000 videos and the next one picks up exactly where it ended, so the dates the run did reach are covered continuously, but it stops at whichever guard comes first — your maxResults, the run's charge limit, its timeout, or this Actor's ceiling of windows per keyword — which on a very large corpus means the sweep is cut off at the bottom, and the run card says which guard cut it; when a window comes back with Bilibili's usual top results instead of the dates asked for (measured 2026-09-23: the endpoint silently drops a date bound sent on its own, either side, so every request this Actor sends carries both — and still checks the dates it gets back), the run stops there and says so rather than pretending the source ran out; and the walk steps back by published date one second at a time, so the one thing it cannot descend past is a block of videos sharing a single second that is larger than what one query returns — the run card calls that out as "the videos stopped getting older", and setting pubtimeEnd just below that date restarts the sweep underneath it.
• Comments: up to 20 root comments per page, paged up to your maxComments, with like counts — measured on Apify's own runners on 2026-09-16 (2 of 3 videos returned 20 each; the third had comments closed). Until build 1.3.86 this looked like a datacenter throttle: the request carried visitor cookies and Bilibili answered with ~3 comments. Deep pagination into the thousands still needs a logged-in session, which this Actor does not use.

Changelog

2026-10-13

• followUpComments re-read rows are delivered only while the run's charge limit can pay for them, as the option's description says. A delta run with no new video and a $0.10 limit could deliver 10 re-read comment rows and bill 5; it now delivers and bills 5, and the video it stopped in and the videos it did not re-read keep their place for a later run. Runs with the option off or with no charge limit, and runs that end with part of their limit unspent, deliver and bill what they did before.
• Run card (text only; rows and charges unchanged). A deltaMode run whose charge limit was reached by its comments, danmaku profiles or re-reads, after its new videos were delivered, no longer says the limit held back videos that later runs may never reach: it says the limit held back no video (and, when its result pages had already stopped early to finish inside the run's timeout, says that too). A deltaMode search or popular run with more than 200 new videos and includeDanmaku now always says on the run card how many got no danmaku profile (the usual delta card left that to the log), and that later runs skip them. A one-off search with the default sort and no filters, for a keyword with fewer results than both maxResults and the ~1,000 one Bilibili query returns, is told Bilibili returned everything it has, instead of that the run reached that ~1,000-video ceiling. The maxComments description no longer gives a bound on a run's rows that danmaku profiles, creator rows and re-read rows go past.

2026-10-06

• Search keeps working if Bilibili refuses its usual search route. A result page Bilibili refuses with HTTP 412 or its risk-control codes (-412 / -352) is asked again of the signed route Bilibili's own website uses, which returns the same results (measured from a home line and from Apify's network on 2026-10-06). Runs where the usual route answers make exactly the same requests as before. If a run gets no search page at all from either route and delivers no video, it now fails with a status saying it was a block, instead of ending green with 0 rows, so a schedule's failure alerts see it; nothing is charged for videos. Pages refused on both routes in a run that did deliver rows are named on the run card.

2026-10-02

• New opt-in followUpComments (search + deltaMode + includeComments, off by default and not in the prefill): a later delta run re-reads, once, the comment threads of videos earlier runs delivered (24 h to 7 days after publication, at least 12 h after delivery) and delivers only comments posted after the newest one already delivered for each video, as comment rows marked isFollowUp: true, billed as the existing per-result event ($0.02). At most 200 threads, 300 requests and ~4 minutes per run; stops on a risk-control refusal without retrying. See Follow-up comments. No price change, no new charge event. With it off, every mode makes the same requests and returns, charges, logs and saves exactly what it did before (checked offline, mode by mode). dataset_schema.json gains one field, isFollowUp (boolean, nullable).

2026-09-30

• Review ask: neutral wording ("Reviews, good or bad, help other users decide"), in the log and on the run card of every one-off run whatever it returned; it used to need 10+ rows and skip truncated runs. Never on a deltaMode run. Requests, rows and charges are unchanged.

2026-09-28

• A user_videos run close to its timeout stops requesting search pages and finishes. This mode had no such guard, and billed once, after the last creator, so a run stopped by the platform timeout ended with its rows in the dataset and none of them billed. It now uses the same margin as search and popular (30 s before the timeout, 5% of a longer timeout, at most 2 minutes, plus the slowest request so far): creators in progress deliver the videos found so far, creators not started yet are not requested, and the run status names both. Each creator is now billed right after its rows are delivered instead of once at the end. A run that finishes before that point makes the same requests and returns and bills the same rows as before.

2026-09-26

• deltaMode no longer delivers and bills again videos it already delivered. Its memory held the last 20,000 delivered video IDs and dropped the oldest first, including videos Bilibili was still returning. A monitor over many keywords has more distinct videos in its results than that at once (25 keywords × ~1,000 results each), so those videos came back as new and were billed a second time. Reproduced offline with 25 keywords, maxResults 2,500 and a daily run: 25% to 52% of the videos billed over 33 days had been billed before. The memory now holds 200,000 IDs, and a remembered video that shows up again on a result page a run reads is kept as recently seen, so the IDs dropped first are those that stopped appearing there. Same simulation: none re-billed while the memory has room. Once it is full, a video that stayed off the result pages the monitor reads can still come back: with the memory forced down to 30,000 so that it filled inside the simulation, 2% to 13% of the videos billed after that point were repeats. At 1,000 to 2,500 new videos a day the real memory fills in 80 to 200 days. States saved by earlier builds are read as they are. A monitor that was receiving repeats now receives, and pays for, fewer rows.
• Two deltaMode runs on the same deltaStateKey no longer erase each other's memory. Each run read the memory when it started and, when it finished, wrote back that copy plus its own videos, so when two runs overlapped (several scheduled tasks on the default key, say) the one that finished last erased the other's videos, and the next run on that other input delivered and billed them again. The memory is now read again just before it is saved, and what the other run saved is kept.
• A search or popular run close to its timeout stops requesting pages and finishes. Video rows are billed when paging ends, and a deltaMode run saves what it has seen after that, so a run stopped by the platform timeout mid-paging kept its rows in the dataset unbilled and, in deltaMode, saved nothing: the next run delivered the same videos again. Paging now stops 30 s before the timeout (5% of a longer timeout, at most 2 minutes), plus the time of the slowest page so far. The rows are billed, the delta state is saved, and the run status says the run stopped early and how many videos it returned. With includeDanmaku, no danmaku profile is requested once paging has stopped this way, and each video's profile is only started while the run is more than 12% of its timeout (30 s to 2 minutes) from the end; the status says how many videos got a profile. Until now a run could reach its timeout inside that phase, which makes up to 400 requests, and be stopped by the platform with no status. A run that finishes before that point makes the same requests and returns the same rows as before.
• Comments and danmaku profiles are no longer requested once the run's charge limit is spent. Both phases kept fetching the remaining videos and then discarded the rows. The danmaku phase also stops once it holds as many profiles as the limit can still pay for. Rows and charges are unchanged.
• The run status only says what happened. It no longer says the delivered rows were billed when a charge failed, or saved as seen when the deltaMode memory could not be saved; a failed save is now on the status, since the next run may deliver those videos again.

2026-09-25

• popular with a category now returns the videos Bilibili files under that category. The category is picked out of the global trending board (Bilibili's own per-category ranking answers error -352), and the match read only each video's sub-zone name, so a video in the requested main zone whose sub-zone name held none of the category's keywords was dropped. Measured on the first 200 videos of the board on 2026-09-25: knowledge returned 8 of its 16 (社会观察, 时政解读 and 应试教育 were missing), animal 0 of 2 (both 猫, so the run ended with 0 rows), music 12 of 14, sports 5 of 6, tech 1 of 2, game 43 of 44, animation 22 of 23 and life 19 of 23. The main zone name is now matched as well, and nothing the old match kept is dropped. Videos still come in the board's order, so a run that stops at its maxResults can now include a recovered video in place of a later one; each extra video is a normal row. category: "all" and the categories that lost nothing on that board (car, food, fashion, entertainment) return exactly what they did.
• A category run that finds nothing says what the board held: "none of the 200 videos on Bilibili's trending board this run belongs to it", instead of blaming Bilibili's risk control and saying the category had no trending videos. The sentence now reaches the run status; it used to be replaced there by "try a broader query".
• includeDanmaku in video_comments mode does nothing (danmaku profiles are made for the video rows a run returns, and this mode returns comments). The run log and status now say so and name the mode that does it, video_detail. No request, row or charge changed.

2026-09-24

• Docs only. The banner at the top of this page now covers searching past Bilibili's ~1,000-per-query cap and user_profile; the daily-monitoring steps and the popular example describe what deltaMode does (the full result set vs new videos only) instead of recommending it; the log of a one-off popular run ends on the category / maxResults tip. No default, request, row, charge or deltaMode behaviour changed.

• pubtimeBegin / pubtimeEnd accept date-times, and a date the Actor cannot read is no longer dropped in silence. Anything other than YYYY-MM-DD — 2026-04-15T10:00:00Z from an API or AI-agent caller, 2026/04/15, 20260415 — used to be read as "no date": the window was switched off and the whole unfiltered search was delivered and charged, with nothing on the run card. Those formats, plus YYYY-MM-DD HH:MM[:SS] with or without a Z / +08:00 zone (no zone = UTC), are now applied. A value that still is not a date (15-04-2026, -7d) does not fail the run: the log and the run status name the field and the value and say the limit was not applied. YYYY-MM-DD inputs send exactly the same requests and return exactly the same rows and charges as before. Also on the run status now, with the requests, rows and charges unchanged: a date before 1970 (a mistyped year such as 1026-04-15 used to switch the window off in silence) and a window whose start is not before its end (which used to end on "try a broader query"). Offset minutes above 59 (+08:99) are reported as unreadable instead of being read as the next hour. A result with no publish date is no longer delivered, or charged, inside a date window you set, and where it is delivered its publishDate / publishTimestamp are null instead of "" / 0.

• New user_profile mode for creator / KOL monitoring: one row per creator with followers, following, video count, total likes, level, verification and bio, from Bilibili's public profile card (no login). An id Bilibili has no profile for returns no row and is not charged; the run card names it. $0.02 per profile — see User profiles.

• user_videos finds a well-known creator's videos again. It searches the creator's channel name and keeps the videos uploaded by that mid, and that search was ordered newest-first — for a big creator the newest videos mentioning the name are other people's clips, reactions and stream re-uploads. Measured on 老番茄 (mid 546195, the example in this README): the first 20 results by date held 0 of his videos, so the run returned only his profile row. The date-ordered search is still read first, because for a creator whose name is theirs alone its matches are exactly their newest uploads; when it is crowded out, the relevance-ranked search now fills the rest (18 of its first 20 are his), delivered newest first. Same input, measured live on 2026-09-24 from a local run: 10 of his videos + his profile (11 rows) instead of 1 row, in 2 search requests. In the same run 极客湾Geekerwan (mid 25876945) got what he got before: his 10 newest uploads, 31 Aug to 23 Sep, from 1 search request. By relevance alone he has 6 videos on its first page and none on its second, and 央视新闻 (mid 456664753) has 19 on its first page, every one from 2019-2022, where by date the first two pages hold 9 of that day's uploads (search pages measured the same day) — so relevance is only the fallback, and when a creator's videos come from it the run status says so: it favours their best-known videos and can skip recent uploads.

• The run status says when a creator yields no videos, and why — no matching video in the search for the name, an empty search, or an id with no profile — instead of "Done!" plus a tip about the comments of videos that were never returned. A creator who came up short of what you asked for is named with the reason too, and the maxResults note in this mode no longer suggests raising it towards 5,000.

• userIds accepts a creator's profile link. https://space.bilibili.com/546195 (or the mobile m.bilibili.com/space/546195, or UID:546195 as the profile page prints it) is read as mid 546195; it used to be skipped as invalid, and the run then blamed Bilibili's risk control and said to re-run later. An entry that is not a creator id at all — a channel name, a video link — is now named in the run status as not a numeric mid, with where to find the number, instead.

2026-09-23

• A date filter with only one side set now actually reaches Bilibili. Setting just pubtimeBegin, or just pubtimeEnd, used to send that one bound to the search endpoint, which drops it silently (HTTP 200, nothing in the payload admitting it) and answers with an unfiltered search. The only thing keeping your dates honest was this Actor filtering the pages itself afterwards — and a page emptied that way counts as an empty page, so three in a row ended the whole pull. Measured offline on a 2,000-video corpus, asking for 40 rows: pubtimeBegin alone returned 1 row in 4 requests and pubtimeEnd alone 0 rows in 3, where the same request with both dates returned 40 in 2. A single bound is now paired before it is sent — a floor at Bilibili's first upload, or a ceiling at now — so all three cases return the same 40 rows in the same 2 requests. Rows outside the dates you set are still never delivered or charged; only the request changed. Runs that set both dates, or neither, are untouched.

• search can now go past Bilibili's ~1,000-result cap. One query is capped at 50 pages of 20; when a keyword reaches that ceiling and you asked for more rows, the run re-asks the same keyword for date windows instead of stopping — each window a fresh query with its own ~1,000-result cap, swept newest-first downwards — from your pubtimeEnd (or today) under the default relevance sort, or from the oldest video the first pass returned when you set sortOrder=pubdate, because only then does that oldest row mean "everything above this is already yours". Guards: it never returns more than maxResults, never fetches rows your run's charge limit cannot bill, leaves part of that limit for the comments / danmaku you switched on, keeps enough time to finish them cleanly, stops when Bilibili does not apply the dates asked for or has nothing new, and caps the windows per keyword. Whatever stopped it is named on the run card, and the card only claims the run went deeper when the windows actually returned videos the first pass had not. deltaMode is unchanged — a monitor still returns only what is new, and says in the log when a one-off run would have gone deeper. Runs that never reach the ceiling make exactly the same requests and return exactly the same rows as before.

2026-09-21

• authorFace is filled in search and user_videos. The search results carry the uploader's avatar, but those two modes always returned an empty string.
• sortComments: time keeps the creator's pinned comment in date order. It used to be put first and take one of your maxComments slots even when it was months old, pushing out one of the newest comments. It now sits where its date puts it, so it is only returned when it is among the newest comments you asked for. hot and likes are unchanged.
• Run status: the "stopped at your maxResults limit" and "you asked for N and got M" notes now count video rows only. Comment, danmaku and creator-profile rows used to be counted too, so a keyword that ran out of videos could be reported as hitting your limit.
• category in video_detail is documented as empty: Bilibili's detail endpoint now returns the zone name blank.

2026-09-16

• Comments: popular comments instead of ~3 recent ones. sortComments: hot (the default) and likes used to request Bilibili's newest-first comment stream and re-sort it locally — and that stream serves an anonymous caller about 3 recent comments per video. They now request Bilibili's own popular-comments ranking and page through it, up to your maxComments. Measured from a European residential line on a video with 2,393 replies: 3 comments before, 20 per page after, with further pages available. Measured on Apify itself on 2026-09-16 (build 1.3.86): the same 3-video search went from 9 billed rows to 43 — 20 comments each on the two videos that allow comments. The root cause was not the datacenter IP: the comment request carried the visitor cookies Bilibili hands out on its homepage, and with them it answers with ~3 comments; without them, 20 per page. time (newest first) is unchanged. If you run includeComments on a Schedule, expect more comment rows per video — and a proportionally larger bill; cap it with maxComments.
• includeReplies now pages reply threads. The reply-page request always came back empty, so only the replies Bilibili inlines were ever returned.
• Comment rows are billed per video, as each video finishes, instead of once after the last one. Paging comments takes minutes on a large input, and a run killed by its timeout (or stopped by you) used to end with every comment row already delivered and none of it billed. Comment collection now also stops early when the run is about to reach its timeout, so it ends with a status that says so instead of a failed run — lower maxComments, split the videos across runs, or raise the run's timeout if you see it.
• user_videos: the creator profile row is now billed as one item (the item-scraped event always listed "creator profile"), only when the dataset received it and at least one of that creator's videos was delivered. User profile + 20 videos = 21 rows, ~$0.42.
• user_videos no longer returns other people's videos. When the first search page had no video by the creator, the run fell back to the unfiltered search results; now only videos whose authorMid matches are returned, and crowded pages are paged through (up to 3 in a row) instead of ending the listing.
• deltaMode + charge limit: videos not delivered because the run hit its charge limit are no longer saved as seen, and the run stops requesting pages once the limit is spent. In popular, later runs can still deliver the ones still on the board; a later search run reads each term from the top and stops it after 3 pages in a row with nothing new, so it may never reach them — raise 'Max total charge' so scheduled runs are not cut short (this sentence corrected on 2026-10-13). The seen-list trim now drops the oldest ids first.
• Danmaku profiles gain danmakuTotal and danmakuPoolCapped; danmakuSampleSize: 0 now returns metrics with no sample texts (it used to become 25).
• HTML entities (>, &) in search / user_videos titles and descriptions are decoded; the Overview table shows Favorites instead of the Coins column that search runs leave empty.

FAQ

Is there a Bilibili API?

There is no official public Bilibili API for international developers. Bilibili's developer platform requires Chinese phone verification and rate-limits hard. This Bilibili Scraper is an alternative — giving you structured data without any authentication.

How much does it cost to scrape Bilibili?

The Bilibili Scraper costs $0.020 per item scraped ($20 per 1,000 results), plus an optional $0.050 per danmaku reaction profile if you enable includeDanmaku. You can start with Apify's free plan, which includes $5 of monthly credits — enough for 250 Bilibili videos, comments, or data points.

Can I scrape Bilibili in Python?

Yes. Install the Apify Python client (pip install apify-client), then use the ApifyClient to call the zhorex/bilibili-scraper actor with your desired input. See the Python code example above.

Is scraping Bilibili legal?

This scraper only accesses publicly available data through Bilibili's public HTTP endpoints — the same data any visitor can see without logging in. It does not bypass any authentication or access private data. Always review your local laws and Bilibili's terms of service.

What does this Bilibili scraper cover?

It supports 6 modes (search, video details, comments, user videos, creator profiles, popular/trending), captures Bilibili-specific metrics like danmaku and coin counts, and runs without a browser, proxy, or API key.

Integrations & data export

The Bilibili Scraper integrates with your existing workflow tools:

• Google Sheets — Send scraped Bilibili data directly to a spreadsheet
• Zapier / Make / n8n — Automate workflows triggered by new Bilibili data
• REST API — Call the actor programmatically and retrieve results via Apify's REST API
• Webhooks — Get notified when a scraping run finishes and process data in real time
• Data formats — Download results in JSON, CSV, Excel, XML, or RSS

Chinese Digital Intelligence Suite

Build complete China market intelligence with our suite of scrapers:

Platform	Users	What it covers
🆕 Chinese Brand Monitor	All 5	Cross-platform brand mention aggregator — Weibo + RedNote + Bilibili + Douban + Xueqiu in one normalized API call, sentiment-tagged, cross-platform deduped. $0.06/mention.
🆕 Chinese AI Training Corpus Engine	All 5	AI-training-ready Chinese corpus builder — Weibo + Bilibili + Xueqiu + Douban + RedNote into deduplicated, quality-scored, PII-scrubbed documents with per-document provenance for EU AI Act documentation. From $0.025/doc; rejects/duplicates never charged.
Bilibili (this actor)	300M+ MAU	Video content, danmaku, creator analytics
Weibo	580M+ MAU	Microblog, hot search, real-time public opinion
RedNote/Xiaohongshu	300M+ MAU	Lifestyle, consumer reviews, KOL data
RedNote Shop	300M+ MAU	RedShop e-commerce: products, vendors, prices, SKUs
Douban	200M+ MAU	Long-form reviews (movies/books/music), group discussions
Xueqiu	20M+ MAU	Chinese stock-discussion sentiment, cashtag indexing
JD.com	600M+ MAU	JD product detail extraction

Built by Zhorex, who maintains a suite of Chinese-platform scrapers. AI training data buyers and equity research desks typically use 2-4 single-platform scrapers + the Brand Monitor aggregator for cross-platform Chinese consumer signal.

More scrapers by Zhorex

Video & Entertainment

• Kick.com Streamer & Channel Analytics — Kick.com profiles, live streams, clips, and categories
• Twitch Streamer & Channel Analytics — Twitch profiles, live streams, clips, and VODs
• YouTube Shorts Scraper Pro — YouTube Shorts videos, creators, trends
• Letterboxd Scraper — Films, reviews, profiles & lists

Price & Availability Monitors

Put them on a Schedule and each run returns only the cells that MOVED, so a quiet day costs almost nothing.

• 🆕 Hostelworld Rate & Availability Monitor — forward-dated accommodation rates, promo stack, organic ranking position, per-date commission split
• 🆕 Resy Availability & Scarcity Monitor — restaurant slots by date and party size, prime-window (18:30-20:59) scarcity, sold-out and reopened transitions
• 🆕 DE/AT Pharmacy Price & Stock Monitor — OTC prices, RRP breaches, stock status
• 🆕 UK Tyre Price & Fitment Monitor — tyre prices by size and postcode
• 🆕 UK PPE Shelf Monitor — 14K+ SKUs, price moves, new listings and delistings

Markets & Alt-Data

• TradingView Multi-Market Scraper — Stocks, crypto, forex, indices
• Hyperliquid Pro Scraper — DeFi top traders, vaults, perpetual markets

B2B Reviews

• G2 Reviews Scraper — B2B software reviews and ratings
• Capterra Reviews Scraper — Software product reviews and ratings
• Booking.com Reviews Scraper — Hotel reviews and ratings

Other Tools

• Perplexity AI Scraper — AI-powered search results
• Tech Stack Detector — Detect technologies used by websites
• Telegram Channel Scraper — Public Telegram channel messages
• Phone Number Validator — Validate and format phone numbers

---

Reviews

Reviews, good or bad, help other users decide: leave one on the reviews page.

Found a bug? Open an issue.