Weibo Scraper — Hot Search, Posts, Comments & Creator Feeds
Pricing
from $35.00 / 1,000 item scrapeds
Sina Weibo (微博) scraper API, no login: keyword search, trending posts, hot-search board (微博热搜), comments, user profiles and post details, plus Black Cat (黑猫投诉) consumer complaints. Creator timelines (user_posts) need your cookie. Nine modes for social listening and China market research.
Pick ONE per run; no login except user_posts. search: posts for searchQuery, newest first (Latin brand names also search the Chinese name, e.g. Nike + 耐克). hot_search: trending board. hot_search_delta: board tagged new/rising/dropped. hot_timeline: posts Weibo pushes. post_comments: postIds, or samples hot posts. post_details: postIds. user_profile: userIds. user_posts: userIds + cookieString. complaints: Black Cat. Comments as rows: includeComments:true.
Search query in Chinese or English. Chinese keywords yield better results. Examples: 人工智能, 新能源汽车, iPhone
When on, a Latin brand name (e.g. 'Nike') also searches its Chinese name ('耐克'); the names take turns page by page and results are merged and deduped, so both share 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.
Search mode only. Optional — leave both date fields empty and the Actor behaves exactly as before. Earliest post date to return, as ISO 2026-09-01 (= 00:00:00 that day) or 2026-09-01T08:00:00. Dates are Beijing time (UTC+08:00) unless you write an offset — the same zone every delivered row's createdAtIso carries, so the calendar days you ask for are the days you can group by. Write 2026-09-01T00:00:00Z if you want UTC; an offset you write is always honoured. Weibo's search API has no lower-bound parameter — only an end time — so the Actor starts at Search date window — end and pages backwards until the posts it receives are older than this start date. Posts outside the window are dropped before delivery, so you are never charged for them. The run's status message reports the window in both zones and the oldest and newest post actually delivered, and says plainly when Weibo stopped before reaching this date (page limits, run time, or your charge limit) — a window is a sample of the period, never a guaranteed complete archive of it. An unparseable date, or a start at or after the end, fails the run with an explanatory message and charges nothing, rather than silently scraping a different period.
Search mode only. Optional. Latest post date to return, as ISO 2026-09-03 (= 23:59:59 that day, so a plain date range covers whole days) or 2026-09-03T18:00:00. Dates are Beijing time (UTC+08:00) unless you write an offset, matching every row's createdAtIso. This is the point Weibo starts paging back from (the one date control Weibo's search honours). Leave it empty to start from now. Posts newer than this are dropped before delivery and not charged. Works with maxResults and your run charge limit, which still cap the run. In deltaMode the dates still filter the rows, but the deeper history walk stays off (as it always is in deltaMode), so a delta run only checks Weibo's first result window against your dates — the status message says so. These two fields apply to search mode only; in any other mode the run tells you in its status message that they did not filter it.
Weibo user IDs (numeric) or profile URLs (weibo.com/u/ or weibo.com/). user_profile returns one profile row per ID — screen name, followers, following, post count, verification, bio, avatar, account creation date — with no login, charged per profile delivered; an ID Weibo does not resolve (deleted, banned or not a user) is not charged, and duplicates are fetched once. The run status names up to 10 IDs per reason; the full list of IDs not delivered, and why, is saved in the run's key-value store as PROFILE_REPORT. Custom addresses such as weibo.com/name are not resolved: use the numeric ID. user_posts: NOTE (measured 2026-08-28): Weibo now serves user timelines only to logged-in sessions — anonymous requests get an empty timeline. For user_posts, add your cookieString below (log in at weibo.com, F12 > Network, copy the Cookie header). The prefill shows the ID format. All other modes work with no login.
Weibo post IDs or post URLs, for post_comments and post_details. Accepted forms: the numeric ID (5346708137705813), the short code Weibo shows in post links (RjB5HwkDj), https://weibo.com/<uid>/<id or code>, https://m.weibo.cn/detail/<id> and https://m.weibo.cn/status/<id or code>. post_details returns one row per post — its current text, reposts, comments and likes, author, date, images and video — with no login, charged per post delivered; the same post pasted twice in any two forms is fetched, and charged, once. A post Weibo does not show (deleted, hidden or never existed) gives no row and is not charged; the run status names up to 10 per reason, and the full list of posts not delivered, and why, is saved in the run's key-value store as POST_DETAILS_REPORT.
complaints mode only. Companies on Black Cat (黑猫投诉, tousu.sina.com.cn — Sina's consumer-complaint platform) whose complaints you want, one row per complaint, with no login. Black Cat ranks each list by recent activity (a complaint filed weeks ago that just got a reply sits next to today's), not by filing date. Paste the company page URL (https://tousu.sina.com.cn/company/view/?couid=2092643773) or just the number after couid=. Lists are read in the order given and share maxResults; duplicates are read once. Black Cat shows anonymous visitors the first 500 complaints (50 pages) of each list — the run says so when a company has more. An ID Black Cat rejects or returns nothing for produces no row and is not charged; the status names it, and the key-value store record COMPLAINTS_REPORT lists every company not delivered in full. Leave empty for Black Cat's public latest-complaints feed across all companies (what China is complaining about right now).
Maximum results to return (applies per user in user_posts mode; user_profile ignores it and returns one row per user ID; in complaints mode it caps the complaints of the whole run, shared across the company IDs in order; in post_details mode it caps the posts of the run, one row per post). Typical patterns: 20-50 for a quick lookup, 100-300 for daily brand / sentiment monitoring, 500 for a full keyword sweep or AI-training pull. Higher values automatically walk more result pages. See the Pricing tab for per-result cost.
In search, user posts and hot timeline modes, also pull the comment thread of every post found and return each comment as its own row (tagged mode: post_comment, linked by postId). Comments are where the opinion is — the post is the prompt, the replies are the sentiment. No login or cookie required. Best paired with hot timeline: measured 2026-08-05, 5 trending posts returned 89 rows with maxComments 20 and 114 with 50 (~18-23x), because those posts actually carry threads — a broad keyword search mostly returns posts with no replies. In search, the newest posts rarely have replies yet: set searchDateTo 2 or more days back (Beijing time) and the same keyword returns older posts, which have had time to collect them. Posts with no thread are skipped automatically, so you are never billed for an empty round-trip. Tip for volume: a narrow, high-engagement query returns far bigger threads than a broad one — a generic keyword mostly returns posts with zero comments. This multiplies rows and cost — 100 posts × 50 comments is ~5,100 rows instead of 100 — so cap it with Max comments per post. Off by default.
Weibo's result lists send only the first ~150 characters of a long post (about half of search results). With this on, each cut-off post is fetched in full at no extra charge — same rows, same price. Turn it off only if you need the fastest possible run.
Adds one extra row per location (Chinese provinces; overseas countries flagged isOverseas), computed from the location Weibo already attaches to each post (发布于 广东). Each rollup row carries province, provinceEn, postCount, sharePct, promotedCount and, when sentiment is on, sentimentMean — so you can see whether a story is national or contained to one province, and which regions are driving it. No extra requests and no extra scraping time: it is computed from data the run already fetched. Rollup rows bill as ordinary results. Honest sampling: if fewer than 50 posts in the run carry a location, no province rows are emitted and none are charged; between 50 and 200 they ship with lowConfidence: true. Every row states its own sampleSize. Works with search, hot timeline and user posts. Off by default.
Weibo mixes paid promotion into keyword results, and those posts used to arrive indistinguishable from public opinion. Every row now carries isPromoted, and this decides what to do with it. organic_only excludes promoted posts, so a brand or sentiment study is not diluted by advertising — and because the filter runs before billing, you are not charged for the rows it removes, which means your bill goes down. promo_only flips it into a China paid-social monitor: which advertisers are buying against your keyword. all is the default and changes nothing. Note on counts: filtering happens after fetching, so asking for 100 posts with organic_only returns fewer than 100 — raise maxResults if you need a fixed number back. The promoted share varies a lot by query and hour (measured 0 of 53 on one search, 1 of 10 on one hot timeline), so no fixed percentage is claimed.
Comments per post: used in post_comments mode AND for every post when includeComments is on; with followUpComments, also per re-read thread. Each comment is its own billed row: up to maxComments per post read, besides the post rows. followUpComments (new comments on earlier posts), includeAuthorProfiles (author rows), geoRollup (location rows) and user_posts' account profiles can add billed rows on top. To cap the bill, set your run's charge limit.
Off by default. In search, hot_timeline and user_posts, adds at most one row per distinct post author (mode author_profile, user_profile fields; join authorId = userId), filling their posts' null authorFollowers. Each row is charged like a post ($0.035): 100 posts by 40 authors add at most 40 rows ($1.40), by 60 at most 50 ($1.75), the per-run cap. Fetched one every 2 s, up to ~3 min per run, within your charge limit. Failed profile: no row, no charge. deltaMode: new posts' authors only.
Tag each post/comment (and complaint, in complaints mode — scored on its title and summary) with lexicon-based Chinese sentiment — polarity + a -1.0…+1.0 score. Optional add-on — for Chinese text it loads a model, so enable with run memory set to 512 MB or more.
Off by default. When on, a run in search, user posts or hot timeline returns only rows that no earlier run with the same Delta state key delivered: posts are deduped by post ID, comment rows (includeComments) by their own comment ID, and rows an earlier run delivered are skipped and not charged. In search mode the deeper history walk is off, so a delta run reads only Weibo's first result window. (Hot Search Delta mode has its own built-in delta and ignores this toggle.) 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. In complaints mode it works per company list (or the public feed), by complaint number: a run returns only complaints no earlier run with the same Delta state key delivered, and reads each list to its end or to Black Cat's 500-complaint depth, because complaints already delivered can sit above new ones (they are skipped, not charged).
Names an independent tracking stream for the delta features (Delta mode in search/user_posts/hot_timeline/complaints, and Hot Search Delta). Keep the default for a single scheduled monitor; use distinct keys (e.g. 'nike-weekly', 'hourly') to run several independent delta streams without collision. State persists across runs, so each scheduled run is compared with the previous one.
Off by default. Only for search mode with Delta mode on. A delta search reads each post minutes after it is published, usually before anyone has replied, and the post then drops out of the newest results, so its replies never reach the monitor. With this on, the posts each delta run delivers are remembered with their posting time (in the Delta state key's record), and a later delta run re-reads each one's comment thread once: on the first run at least 24 hours after it was posted, before it is 7 days old, newest posts first. Only comments never delivered under this Delta state key come back, as ordinary comment rows (mode: post_comment, linked by postId) marked isFollowUp: true, up to Max comments per post per post, from at most 6 pages of each thread (about 120 new top-level comments). Cost: each comment row is one result, charged like a post ($0.035); a thread with no new comments adds nothing. At most 300 threads, 400 comment requests and about 4 minutes of re-reading per run, 2 s apart, and never more rows than your run's charge limit can pay for; posts not reached keep their place for the next run. The run's own rows are delivered after the re-reads, so a run takes up to ~4 minutes longer: keep the schedule interval longer than a run lasts. It starts with the posts delivered from the first run with this on. Does not run with adFilter = promo_only (comment rows carry no promotion label).
