Bilibili Scraper — Videos, Comments, Danmaku & Creator Uploads
Pricing
from $20.00 / 1,000 item scrapeds
Scrape Bilibili (哔哩哔哩), China social media for video: search, video details, comment threads, Chinese influencer uploads and creator profiles (followers, likes), the popular board — plus danmaku (弹幕), the scrolling on-video reactions no other platform has, no cookie needed.
What to scrape from Bilibili
Search query — works in Chinese (人工智能) and English (AI tutorial). Used in 'search' mode.
When on, a Latin brand name (e.g. 'Nike') also searches its Chinese name ('耐克') and results are merged — so you get full native recall even when searching in English. Capped at maxResults (no extra cost). Add your own variants via Search aliases below.
Extra term variants to also search and merge with your query — e.g. add '耐克' for Nike, or alternate spellings. Useful for brands not in the built-in dictionary.
How to sort search results. Used in 'search' mode.
Filter search results by video duration. Used in 'search' mode.
Only videos published on or after this date (or moment). Leave empty for no filter. Used in 'search' mode. Accepted formats: 2026-04-15 (read as 00:00 UTC that day), 2026/04/15, 20260415, 2026-04-15 10:30 or 2026-04-15 10:30:00, and ISO 8601 date-times with or without a zone, e.g. 2026-04-15T10:30:00Z or 2026-04-15T18:30:00+08:00. A time without a zone is read as UTC — add +08:00 for Beijing time. A value the Actor cannot read (e.g. 15-04-2026 or -7d) is NOT applied: the run searches without it and says so in the run status.
Only videos published on or before this date (or moment). Leave empty for no filter. Used in 'search' mode. Same formats as 'Published after': 2026-04-15, 2026/04/15, 20260415, 2026-04-15 10:30 or 2026-04-15 10:30:00, and ISO 8601 date-times with or without a zone, e.g. 2026-04-15T10:30:00Z or 2026-04-15T18:30:00+08:00; a time without a zone is read as UTC. A bare date means 00:00 UTC at the START of that day, so 2026-04-15 leaves out videos published later on the 15th — use 2026-04-15T23:59:59Z to include the whole day. A value the Actor cannot read (e.g. 15-04-2026 or -7d) is NOT applied: the run searches without it and says so in the run status.
Turn a one-off pull into a recurring monitor: when on, each run returns only videos not seen in previous runs (deduped by video ID across runs, per Delta state key). Pair it with an Apify Schedule for a hands-off daily/weekly 'what's new' feed — you pay only for genuinely new videos. Works in 'search' mode (new videos for your keyword) and 'popular' mode (new videos trending now that weren't before). Tip: in search mode set Sort order to 'Newest first' for monitoring. Know the trade before you switch it on: a full run returns the whole current result set and bills for it; a delta run returns only what has appeared since the last run. On fast-moving boards (trending, hot search, popular) that is still a healthy batch every run. On a narrow keyword or a single creator it can be a handful of rows, or none on a quiet day — which is the feature working, not a broken run. Pick delta when you want to be told what is NEW; leave it off when you want the data itself.
Names the saved 'already-seen' state so independent monitors don't collide. Use a distinct key per query/category you track (e.g. 'nike-weekly', 'game-trending'). Only used when Delta mode is on.
Bilibili video URLs or BV IDs. Used in 'video_detail' and 'video_comments' modes. Example: https://www.bilibili.com/video/BV1xx411c7mD or BV1xx411c7mD
Bilibili user numeric IDs (mid). Used in 'user_profile' and 'user_videos' modes. Find a user's mid in their profile URL: space.bilibili.com/{mid} — pasting that link works too; a channel name does not. In 'user_profile' mode each creator returns ONE row — followers, following, video count, total likes, level, verification and bio — from one request per creator, no search involved; maxResults caps how many profiles a run returns, and an id Bilibili has no profile for is named in the run status and not charged. Schedule it daily or weekly to track follower growth. How 'user_videos' mode works, so the row count is not a surprise: Bilibili's direct space listing is behind risk control that rejects plain HTTP requests, so the Actor searches the creator's channel name and keeps the videos whose mid matches. It reads that search by date first, where the matches are the creator's newest uploads. When other people's videos crowd it (a famous name is on many fans' clips), the rest come from the relevance-ranked search, which favours the creator's best-known videos and can skip recent uploads — the run status says when that happened. Delivered newest first; for a well-known creator expect about 20 videos, not a complete upload list. For a wider sweep use 'search' mode with the creator's name.
Filter popular videos by category. Used in 'popular' mode.
Maximum number of results to scrape. Typical patterns: 20-50 for a quick lookup, 100-300 for daily creator / category monitoring, 500 for a full keyword sweep or content-analytics pull. Higher values automatically walk more result pages. See the Pricing tab for per-result cost.
In search, user videos and popular modes, also pull the comment thread of every video found and return each comment as its own row (type: comment, with likeCount, replyCount and author). Comments are where the audience opinion is — the video is the prompt, the replies are the sentiment. No login or cookie needed. Cap it with Max comments per video, and note that this multiplies the rows a run returns, and therefore what it costs: 100 videos × 20 comments is ~2,100 rows instead of 100. Off by default.
Each top-level comment can carry a thread of replies. Turn this on and every reply becomes its own row, tagged with rootRpid and isThreadReply so you can rebuild the conversation. The flag reads the replies Bilibili inlines in the same response AND pages any further ones the root declares in replyCount, one request per thread, stopping as soon as your maxComments is met. How much it adds depends on the video: a popular root measured on 2026-09-16 declared 30 replies and returned 10 on its first page, while quiet roots declare none — and then no extra request is made and no rows are added. Caveats: replies bill as ordinary comment rows, and videos with comments closed return none at all. Off by default.
Danmaku (弹幕) is Bilibili's on-video scrolling commentary — comment text bound to a specific second of the video, which no other platform has. With this on, each video also returns one type: danmaku row with danmakuFetched, danmakuUniqueSenders, danmakuPerMinute, the peak minute and its count, first/last timestamps, and an evenly-spread text sample across the whole video. What it is for: second-by-second audience reaction on an ad or a launch, and creator vetting — danmaku-per-minute beats view count as an engagement signal because a danmaku costs the viewer effort. What is counted: Bilibili serves the danmaku it keeps in the video's pool, and that pool is capped, so on busy videos danmakuFetched is lower than the video's own total. The row says so: danmakuTotal is the video's own danmaku count (single-part videos; null on multi-part uploads) and danmakuPoolCapped is true when fewer were fetched than that total. Cost is predictable: this adds ONE row per video, not one per danmaku. Off by default. Billing: each danmaku row is its own danmaku-profile event at $0.05 — 2.5x a normal $0.02 row — because it fetches and reduces the danmaku Bilibili keeps in the video's pool (capped; 3,600 of 4,542 on one measured video). Profiling 200 videos costs $10. Off by default.
How many danmaku texts to include in the sample, spread evenly across the video timeline (not the first N, which would all come from the opening seconds). The sample rides inside the single danmaku row, so raising it does not add billable rows. Set 0 for metrics only (no sample texts).
Maximum number of comments to scrape per video. Used in 'video_comments' mode.
How to sort comments. Used in 'video_comments' mode.
