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

> Three ways to get Weibo data in Python: the official open platform, a GitHub weibo scraper, or a pay-per-call API. One live 7-step chain cost $0.0051.

- Canonical page: https://everyinfra.com/en/blog/weibo-api-python
- Published: 2026-11-12T01:08:00+08:00 · Fact-checked: 2026-11-12T00:40:00+08:00

On November 11, 2026, between 00:14 and 00:37 Singapore time, we ran a full Weibo data chain four times with Python and the requests library. Each chain had seven steps: hot search list, topic search, post search, post detail, comments, comment replies and reposts. Every request in those four chains either returned data or was refunded. A full chain cost $0.005142 and took 19.37 to 33.94 seconds. We ran the chain three more times later that night and on November 12 to test retries.

The most useful result was not the price. It was the sample. In all four first runs, the post that our script picked as "most commented" did not contain the search keyword in its text. The same keyword can also return very different windows. A search for "flu" at 00:14 returned 12 posts from seven days. The same search at 00:46 returned 50 posts, all from the last 20 minutes.

We also checked the two other routes against their own primary documents. The Weibo Open Platform allows one authorized user in one app to make 100 requests per day. Its comment endpoint returns only the comments of the authorized user. Third parties must not store user data on their servers. The most popular weibo scraper projects on GitHub state in their README files that keyword search and reposts need a logged-in cookie. Their issue trackers from the last 60 days still report non-JSON responses and a limit of 500 results per search.

> **Key points**
>
> - Four 7-step chains, 28 requests: every charge matched the catalog price. Empty results and failures cost $0. One full chain cost $0.005142.
> - Cost per 1,000 rows from real counts: hot search about $0.011, post search about $0.039, comments about $0.043, reposts about $0.065, user timelines about $0.081.
> - Picking the most-commented post picked an off-topic post in all four first runs. Filter on the post text first, then sort.
> - The official platform allows 100 requests per authorized user per day and forbids server-side storage of user data. Data-analysis businesses must use a separate commercial data API under contract.
> - The hot search list comes from a formula and updates every minute. Use it as a record of what Weibo showed, not as a measure of public interest.

For the official route and the open-source route, we quote only the pages on open.weibo.com, the project README files and public issues. For the pay-per-call route, every number comes from our own calls. We kept the scripts and the raw JSON responses, so you can check each number again.

![Illustration of seven translucent trays in a diagonal line, joined by thin arrows. The first tray is teal and holds a list of bars with small flames, for the hot search list. The next trays hold a hashtag, a magnifying glass over a post, a post card, a column of comment bubbles, and one comment that splits into small bubbles. The last tray shows a circular arrow, for reposts.](https://everyinfra.com/articles/weibo-api-python/img-explain.webp)

The seven steps of the chain in this article, from the hot search list to reposts.

## The short answer: which weibo api route fits you

The three routes serve different people. The table puts the setup, the data scope and the main risk of each route side by side. Each item has a source or a test record later in this article.

| Item | Official Weibo Open Platform | Open-source weibo scraper on GitHub | Pay-per-call data API (EveryInfra in this test) |
| --- | --- | --- | --- |
| Setup | Create an app and pass review; weibo-cli needs a face check in the Weibo app | None | Sign up and create an API key |
| Whose data | Centered on the authorized user: comments of that user, timeline of that user | What a public page shows, depending on the cookie | Public hot search, topics, posts, comments, replies, reposts, user timelines |
| Keyword search | Topic search is an advanced endpoint with the newest 200 results; per-row commercial data needs a sales contact | README says keyword search needs a cookie; the web shows at most 50 pages | `weibo/search`, `weibo/topic_search` |
| Rate | 100 requests per authorized user per day; 15,000 per IP per hour | You set the delay; one project defaults to 8 to 15 seconds per page | Per-key rate limit; a 429 costs nothing |
| Storage | No server-side storage of user data by third parties | Your decision and your risk | Follow your own use case and the law that applies to you |
| Cost | Standard endpoints are free; weibo-cli credit packs start at RMB 69; no public price for commercial data | Free code; the cost is your time and accounts | $0.005142 for one 7-step chain in this test |

Here is our view. You may build a tool for your own Weibo account, to post, to reply to comments or to show the data of your own users. Then use the official platform. It is the only route with write access, and it is the most stable.

You may be a student who needs a few hundred posts from one public account for a thesis. Then an open-source script is enough. But the cookie expires after about three months, and the site can block you at any time. You may collect public posts by topic and by hot search every day, for news or public service research, without a cookie to maintain. Then a pay-per-call API needs the least work. The next sections give the evidence.

## Route 1: the official weibo api on the Weibo Open Platform

Many tutorials describe "the Weibo API" as an endpoint where you type a keyword and get every matching post on the site. The documentation on open.weibo.com says something different. Most read endpoints on the open platform are centered on an OAuth2 authorized user. Your app first asks a Weibo user to log in and give consent.

Your app then gets an access_token and reads data that this user can see, or data that this user made. The example in the official [access_token documentation](https://open.weibo.com/wiki/Oauth2/access_token) shows a token lifetime of 7,200 seconds, or two hours. After that, the user must authorize again.

All official pages are in Chinese. In this article we translate the parts that matter and link to the original pages.

### What you can still apply for

We opened the endpoint pages that developers ask about most. The [comment list endpoint 2/comments/show](https://open.weibo.com/wiki/2/comments/show) states that it returns only the comments of the authorized user, with 50 rows per page by default. So you cannot read all comments from strangers under a popular post. The [user timeline endpoint 2/statuses/user_timeline](https://open.weibo.com/wiki/2/statuses/user_timeline) accepts only the uid of the current authorized user. It returns at most 5 posts, or 10 with the official SDK.

The [topic search endpoint 2/search/topics](https://open.weibo.com/wiki/2/search/topics) is an advanced endpoint. It searches only posts with a hashtag topic, returns only the newest 200 results, and gives at most 50 rows per page. Among the standard endpoints, the [public timeline 2/statuses/public_timeline](https://open.weibo.com/wiki/2/statuses/public_timeline) returns new public posts that the platform selects. You cannot filter it by keyword.

Advanced endpoints need a separate application. The [advanced endpoint application page](https://open.weibo.com/wiki/%E9%AB%98%E7%BA%A7%E6%8E%A5%E5%8F%A3%E7%94%B3%E8%AF%B7) says that your app must pass review first. Weibo handles an application within 3 working days. Some older endpoints no longer accept applications. We did not submit an application for a real app. So we only quote the page here, and we make no claim about approval rates or wait times.

### Rate limits and storage: 100 requests a day, no server storage

The [API access frequency page](https://open.weibo.com/wiki/%E6%8E%A5%E5%8F%A3%E8%AE%BF%E9%97%AE%E9%A2%91%E6%AC%A1%E6%9D%83%E9%99%90) was last updated on May 15, 2025. It gives three examples. One authorized user in one app can make 100 requests per day to the open endpoints. One IP address can make 15,000 requests per hour. The posting endpoint allows 30 requests per hour per authorized user.

The same page has two sentences that matter more for research. First, the platform objects to robot programs on a server that collect user data when the user did not start the action. Second, the open platform forbids third parties to store user data on the server side, so a cache can stay only on the client. The page suggests a refresh interval of 3 to 5 minutes. If the open endpoints are not enough, the page tells developers to contact the commercial open platform.

![Screenshot of the Weibo Open Platform page on API access frequency, in Chinese. A teal box marks three lines. In translation, they say that one authorized user in one app can request the open endpoints 100 times per day, one IP address can make 15,000 requests per hour, and the posting endpoint allows 30 requests per hour per authorized user. A second box marks a sentence that says the platform forbids third parties to store user data on the server, so caches can only stay on the client.](https://everyinfra.com/articles/weibo-api-python/img-doc-weibo-ratelimit.webp)

Rate and storage limits on the open platform, captured on November 11, 2026. [Weibo Open Platform, API access frequency page](https://open.weibo.com/wiki/%E6%8E%A5%E5%8F%A3%E8%AE%BF%E9%97%AE%E9%A2%91%E6%AC%A1%E6%9D%83%E9%99%90)

The [developer agreement](https://open.weibo.com/wiki/%E5%BC%80%E5%8F%91%E8%80%85%E5%8D%8F%E8%AE%AE) gives more detail. Clause 2.7.7 says that data from the open platform can be used only in the app that connected to it. Clause 2.7.8 is about developers who collect or analyze data for third parties as a business. They must use the Weibo commercial data API and sign a commercial data service agreement.

Clause 2.5.15 says that you must delete all data when your service stops. Another clause forbids data requests for government public-opinion monitoring without the original letter of authorization. For a team that does public opinion or market research, these clauses mean that research on the standard open endpoints does not fit the agreement.

| Clause of the developer agreement | What it says (our translation) | What it means for a data project |
| --- | --- | --- |
| 2.7.7 | Data from the open platform is only for the app that connected | You cannot reuse it in a separate research database |
| 2.7.8 | Businesses that collect or analyze data for third parties must use the commercial data API under a signed agreement | Agencies and research vendors need the commercial contract |
| 2.5.15 | Delete all data when the service stops | Plan deletion before you collect |
| Monitoring clause | No data requests for government public-opinion monitoring without the original letter of authorization | A monitoring project needs written proof of its mandate |

### The commercial data API: billed per row, no public price

The home page of the [Weibo commercial data API](https://openapi.sc.weibo.com/) lists three billing methods. The first is a data quota billed per row, for keyword, user and check-in content, including original posts, reposts and comments. The second is billing per query. The third is billing per permission. The contact on the page is a sales email address.

We did not find a public price list, and we did not ask for a quote as a customer. So this article does not compare its price with the other routes. One thing is clear: it is for companies that sign a contract. The barrier is the contract, not the code.

### weibo-cli: the new entry point in 2026

In 2026 the open platform added a command-line tool. The [weibo-cli manual](https://open.weibo.com/cli/quickstart) says that you need Node 18 or later and an OAuth login. Developer verification needs a face check in the Weibo app. Each account can claim one free 7-day trial, which is open only to an allow list.

During the trial, read endpoints usually allow 5 calls each and write endpoints 3 calls each. After the trial you buy credit packs, which start at RMB 69 and are valid for 365 days. Write endpoints (POST) allow 60 calls per hour. You must label content that AI made when you publish it.

The npm package [@weibo-ai/weibo-cli](https://www.npmjs.com/package/@weibo-ai/weibo-cli) was created on May 25, 2026. Its latest version, 0.9.8, was published on September 22, 2026. A [Sina Finance repost of an IThome report](https://finance.sina.com.cn/tech/digi/2026-06-26/doc-inietsps5205508.shtml) says that the tool launched on June 22 with more than 70 endpoints and MCP support.

![Screenshot of the weibo-cli manual page, in Chinese. Teal boxes mark three passages. In translation, they say that read endpoints usually allow 5 calls each and write endpoints 3 calls each during the free trial, that paid credit packs start at RMB 69 and are valid for 365 days, and that write endpoints allow 60 POST calls per hour. The menu on the left shows entries for a skill gallery and for MCP.](https://everyinfra.com/articles/weibo-api-python/img-doc-weibo-cli.webp)

Trial limits and credit pack prices for weibo-cli, captured on November 11, 2026. [Weibo Open Platform, weibo-cli manual](https://open.weibo.com/cli/quickstart)

weibo-cli solves one problem: an authorized user who wants an AI assistant to work on their own Weibo account. A trial of 5 calls per endpoint is clearly not for bulk collection. It is also not a Python package. You can call it from Python with subprocess, but you still need the login, the face check and the credits.

| What you want to do | Official endpoint | Limit stated in the original page |
| --- | --- | --- |
| Read all comments under a popular post | 2/comments/show | Only the authorized user's comments; 50 per page by default |
| Read the history of a public account | 2/statuses/user_timeline | uid must be the authorized user; at most 5 posts (10 with the SDK) |
| Search posts by keyword | 2/search/topics (advanced) | Hashtag topics only, newest 200 results; needs an application |
| Collect keyword data in bulk | Commercial data API | Contract; billed per row or per query; no public price |
| Let an AI assistant run your own account | weibo-cli | Face check; 5 trial calls per endpoint; packs from RMB 69 |

## Route 2: open-source weibo scraper projects on GitHub

Search for "weibo scraper github" and you find a few Python projects that people have maintained for years. On November 11, 2026, at 00:23 Singapore time, we read their stars, last push dates and licenses from the GitHub API. We also read each README. The table shows only what the README files and the API responses say.

| Project | Stars | Last push | License | What the README says about login |
| --- | --- | --- | --- | --- |
| [dataabc/weibo-crawler](https://github.com/dataabc/weibo-crawler) | 4,694 | 2026-11-06 | Not stated | Cookie is optional; without it you get most posts; keyword search and reposts need it |
| [dataabc/weiboSpider](https://github.com/dataabc/weiboSpider) | 9,750 | 2026-02-04 | Not stated | Cookie required; it expires after about three months |
| [dataabc/weibo-search](https://github.com/dataabc/weibo-search) | 2,339 | 2026-06-05 | Not stated | Cookie required; one search shows at most 50 pages |
| [nghuyong/WeiboSpider](https://github.com/nghuyong/WeiboSpider) | 4,127 | 2026-06-30 | MIT | Replace the weibo.com cookie, then run |
| [NanmiCoder/MediaCrawler](https://github.com/NanmiCoder/MediaCrawler) | 70,803 | 2026-11-09 | Custom, no commercial use | Many platforms; logs in through a browser |
| [stay-leave/weibo-public-opinion-analysis](https://github.com/stay-leave/weibo-public-opinion-analysis) | 1,057 | 2026-10-24 | Not stated | Full public-opinion workflow; README says about 100,000 rows per day |

### The cookie: optional, required, or replaced every three months

The README of dataabc/weibo-crawler explains the cookie in detail. For a user with fewer than 2,000 posts, you get the profile and most posts without a cookie. For a user with more than 2,000 posts, you get most of the latest 2,000 posts. Its example is a user who then had 1,085 posts: without a cookie, the script got 1,026 of them, about 94.56%.

The same README says that keyword search must have a cookie, and that reposts need one too. The FAQ of the sister project weiboSpider warns that a cookie lasts about three months. After that, you must copy a new one. So any step that involves search or reposts needs a logged-in account on the open-source route.

None of the six README files has a separate section on the Weibo visitor system. They only explain how to copy the cookie from the browser developer tools. On speed, the weibo-crawler settings set a default delay of 8 to 15 seconds between post pages and 1 to 2 seconds between comment requests. The README also covers a block during a large job.

You can find the page where you stopped from the number of rows you have, and start again from that page.

### Issues from the last 60 days: non-JSON replies, a 500-result cap

Issues show the real state of an open-source project. Issue [#653 on weibo-crawler](https://github.com/dataabc/weibo-crawler/issues/653) was opened on September 26, 2026. The user says that the script worked for five months, but from mid-August it failed with "Expecting value" after a few posts on the first page. That error means the server no longer sent JSON. Back-off retries at 10, 20, 40, 80 and 160 seconds did not help, and a fresh cookie did not help either.

Issue [#590 on weibo-search](https://github.com/dataabc/weibo-search/issues/590) was opened on October 13, 2026. It says that every keyword returns no more than 500 results, and the user suspects the 50-page limit of the web page. This matches the weibo-search README, which says that results beyond 50 pages do not show. That is why the project tells you to split the time range and use its FURTHER_THRESHOLD setting to decide when to split again.

The projects are also active. weibo-crawler pull request [#658](https://github.com/dataabc/weibo-crawler/pull/658) was opened on November 4, 2026, and merged on November 5. It rebuilt the archive flow and added checks for comments and post status. [#659](https://github.com/dataabc/weibo-crawler/pull/659) was merged on November 6. MediaCrawler merged a fix, [#1000](https://github.com/NanmiCoder/MediaCrawler/pull/1000), on November 4.

Active work shows that the tools still run. It also shows that the site keeps changing, so the scripts must change with it.

| Item | Date | What it says |
| --- | --- | --- |
| weibo-crawler issue #653 | September 26, 2026 | Worked for five months; from mid-August, "Expecting value" (non-JSON) after the first page; new cookie and back-off did not help |
| weibo-search issue #590 | October 13, 2026 | No keyword returns more than 500 results |
| weibo-crawler pull request #658 | merged November 5, 2026 | Rebuilt the archive flow; added comment and status checks |
| weibo-crawler pull request #659 | merged November 6, 2026 | Second large change in two days |
| MediaCrawler pull request #1000 | November 4, 2026 | Fix merged |

### robots.txt, licenses and two court cases

The file [weibo.com/robots.txt](https://weibo.com/robots.txt) says Disallow: / for all crawlers that it does not name. It allows only the search engines that it names. The AI crawlers that it names can read only the sitemaps and a few paths. The file header also states ai-train=no. The mobile site [m.weibo.cn/robots.txt](https://m.weibo.cn/robots.txt) also says Disallow: / for all crawlers.

A robots rule is not a law by itself, but courts in China have treated it as part of a business's own choices. One example is the robots case between ByteDance and Weibo, in a [summary by a Shanghai Jiao Tong University law center](https://cclp.sjtu.edu.cn/Show.aspx?info_lb=672&info_id=5120&flag=648). On appeal, the Beijing High People's Court rejected all claims of ByteDance. The court found that Weibo's use of the robots protocol to limit certain crawlers was within its business autonomy. An earlier case, [Sina Weibo v.

Maimai](https://sciiip.gdufs.edu.cn/info/1028/1083.htm), set the "triple authorization" rule. Its case number is (2016) Jing 73 Min Zhong 588. Under that rule, open platform data needs the consent of the user and of the platform. Maimai had to pay RMB 2 million in damages.

Check the licenses too. Four projects in the table state no license. Under the default rules of GitHub, that means you have no license to copy or share their code. The MediaCrawler README says that the project is only for learning and reference, and it forbids commercial use. Before you use an open-source script for company work, deal with the license in the same way as the cookie.

## Route 3: a pay-per-call weibo api in Python

On the third route, you do not keep cookies, request signing or page parsing up to date yourself. Your Python code only sends HTTP requests and reads JSON. We used the EveryInfra endpoint `POST /api/v1/social` with the platform set to weibo, and we changed the action to call each capability. Before we started, we read the free catalog at `GET /api/v1/social/catalog?platform=weibo` to check the parameters, prices and `available` flag of each capability.

At 00:13 Singapore time on November 11, 2026, the catalog listed these prices. `weibo/trending` and `weibo/comments` cost $0.000556 per call. `weibo/search`, `weibo/topic_search`, `weibo/post_detail`, `weibo/comment_replies`, `weibo/reposts` and `weibo/user_posts` cost $0.000806 per call. The catalog showed `weibo/user_post_search`, which searches inside one user's posts, as available=false that day, so we did not use it. We read the catalog again on November 12, 2026, and the prices had not changed.

![Animated flow of seven boxes from left to right: weibo/trending ($0.000556, median 0.73 s), weibo/topic_search ($0.000806, 3.82 s), weibo/search ($0.000806, 8.13 s), weibo/post_detail ($0.000806, 1.31 s), weibo/comments ($0.000556, 1.41 s), weibo/comment_replies ($0.000806, 6.70 s) and weibo/reposts ($0.000806, 1.36 s). A teal dot moves from the hot search box through each step. The text under the boxes says that one full chain is 7 requests and $0.005142, with a median of 25.19 s over three full chains.](https://everyinfra.com/articles/weibo-api-python/fig-02-chain-flow.en.light.svg)

The script below is the final version that we used in our tests. It needs only requests. It reads the key only from an environment variable. It saves the request, the time and the full response of each step as JSON, so you can check each charge later.

It has two changes from our first version, and both came from the tests. First, when a 503 response says that it can be retried, the script waits for `retry_after` seconds and sends the request again. Second, it filters posts on their text before it sorts them by comment count. The next two sections explain why.

```text
"""Weibo chain: trending -> topic_search -> search -> post_detail -> comments -> comment_replies -> reposts.
pip install requests==2.32.3 ; export EVERYINFRA_API_KEY=... ; python weibo_chain.py 流感 run6   # 流感 = "flu" """
import json, os, sys, time
from pathlib import Path
import requests

API = "https://api.everyinfra.com/api/v1/social"
SESSION = requests.Session()
SESSION.headers["Authorization"] = "Bearer " + os.environ["EVERYINFRA_API_KEY"]  # key stays in the environment


def call(action, params, out_dir, name):
    body = {"platform": "weibo", "action": action, "params": params}
    for _ in range(4):
        t0 = time.time()
        r = SESSION.post(API, json=body, timeout=120)
        data = r.json()
        err = data.get("error") or {}
        # 429 (rate limit) and retryable 503 are not charged: wait as told, then send the same request again
        if r.status_code == 429 or (r.status_code == 503 and err.get("retryable")):
            time.sleep(int(err.get("retry_after") or 60))
            continue
        break
    rec = {"started_sgt": time.strftime("%H:%M:%S", time.localtime(t0)), "elapsed_s": round(time.time() - t0, 2),
           "http_status": r.status_code, "request": body, "response": data}
    out_dir.mkdir(parents=True, exist_ok=True)
    (out_dir / f"{name}.json").write_text(json.dumps(rec, ensure_ascii=False, indent=1))
    rows = data.get("results") or []
    print(name, r.status_code, rec["elapsed_s"], len(rows), (data.get("billing") or {}).get("charged_usd"), flush=True)
    return data, rows


def main(keyword, tag):
    out = Path(os.environ.get("OUT_DIR", ".")) / tag
    call("trending", {"limit": 50}, out, "1_trending")
    call("topic_search", {"keyword": keyword}, out, "2_topic_search")
    _, posts = call("search", {"keyword": keyword, "limit": 50}, out, "3_search")
    # keep only rows whose text really contains the keyword, then take the most-commented one
    on_topic = [p for p in posts if keyword in (p.get("text") or "")] or posts
    post = max(on_topic, key=lambda p: (int(p.get("comment_count") or 0), int(p.get("repost_count") or 0)))
    pid = str(post["id"])
    call("post_detail", {"url": pid}, out, "4_post_detail")
    _, comments = call("comments", {"url": pid, "limit": 50}, out, "5_comments")
    if comments:
        top = max(comments, key=lambda c: int(c.get("like_count") or 0))
        call("comment_replies", {"comment_id": str(top["id"]), "limit": 20}, out, "6_comment_replies")
    call("reposts", {"url": pid, "limit": 20}, out, "7_reposts")


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

Each step does one job. `weibo/trending` gets the hot search list. Each row has a rank, a title, a category, a heat score and a label such as hot, new or boiling. `weibo/topic_search` finds hashtag topics for a keyword, and each topic has a read count and a discussion count.

`weibo/search` finds posts by keyword. `weibo/post_detail` fills in the counts and the author of one post. `weibo/comments` gets top-level comments. `weibo/comment_replies` gets the replies under one comment.

`weibo/reposts` gets the list of reposts. To follow the post history of one author, add `weibo/user_posts`. It supports paging with `page_token`, and in each of our first four tests we read two pages.

Weibo search works best with Chinese keywords, because most posts are in Chinese. You can pass the keyword as a normal Python string. The requests library sends the body as UTF-8 JSON, so you do not need to encode it yourself.

## Live tests: four keywords, seven chain runs

We chose four keywords. "Flu" and "flu vaccine" stand for a public health use case. "Singles Day" (the November 11 shopping festival) was the hottest shopping topic on the site that night. "Chilean cherries" is a quiet keyword for imported fresh fruit, so we could compare a hot keyword with a quiet one.

The first four runs used the first version of the script, which picked the most-commented post directly and waited 60 seconds after a 429. The last three runs used the final version above. All times are Singapore time. Run 7 was on November 12; the other runs were on November 11, 2026.

| Run | Time | Keyword | Search rows (limit 50) | Comment count of picked post | Comments / replies / reposts returned | 7-step time | 7-step charge |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | 00:14–00:19 | flu | 12 | 4 | 2 / 0 (empty, refunded) / 3 | 25.19 s | $0.004336 |
| 2 | 00:19–00:21 | Singles Day | 17 | 36 | 24 / 1 / 14 | 33.94 s | $0.005142 |
| 3 | 00:31–00:33 | flu vaccine | 11 | 6 | 5 / 1 / 20 | 19.37 s | $0.005142 |
| 4 | 00:33–00:37 | Chilean cherries | 50 | 25 | 12 / 0 (empty, refunded) / two 503s, free | 32.87 s | $0.003530 |
| 5 | 00:46–00:47 | flu | 50 | not returned (503) | 2 / 1 / 503, free | — | $0.002724 |
| 6 | 00:47–00:55 | flu | 38 | 0 | 0 (empty, refunded) / not called / 503, free | — (about 8 min with retry waits) | $0.002168 |
| 7 (Nov 12) | 00:15–00:20 | flu | 15 | 2 | 1 / 503 (at capacity, refunded) / 503, free | — (about 5 min with retry waits) | $0.003530 |

The "7-step charge" column counts only the 7 requests of the chain. It does not include the separate `weibo/user_posts` calls ($0.000806 per page), which the pagination section counts. Every charge matched the catalog price: $0.000556 for hot search and comments, and $0.000806 for the other steps. When comment replies returned 0 rows, `billing.reason` was empty_result_refunded and the charge was $0. When a request failed with a 503, the reason was request_failed_refunded, and the charge was also $0.

The median time of the three full chains (runs 1 to 3) was 25.19 seconds. That missed the 20-second target we set before the tests. Two steps were slow: post search (3.95 to 13.95 seconds) and comment replies (5.91 to 7.23 seconds). The hot search step always took less than one second.

Rate-limit waits are not in these times. The first four runs hit six 429 responses. Each time, the script waited 60 seconds and the retry worked. A 429 costs nothing.

![Stacked horizontal bars for the time of each step in four 7-step chains. Test 1, flu: 25.19 s in total, with post search 8.1 s and comment replies 7.2 s. Test 2, Singles Day: 33.94 s, with post search 10.4 s, comments 10.7 s and replies 5.9 s. Test 3, flu vaccine: 19.37 s, with post search 4.0 s and replies 6.7 s. Test 4, Chilean cherries: 32.87 s, with post search 13.9 s and replies 7.0 s. The post search segment is teal.](https://everyinfra.com/articles/weibo-api-python/fig-08-latency-by-step-bar.en.light.svg)

Run 5 was an accident, but it gave us a useful sample. At 00:46 we started the new script with "flu" again. Topic search, post detail and reposts returned a 503 within 0.13 to 0.23 seconds. The error body said "service temporarily unavailable", retryable true, retry_after 60 seconds.

It also said that this was the first (or second) failure, that it was not charged, and that the third failure would say what to check. None of the three steps cost money, so the run cost only the four steps that worked. After that, we added the wait-and-retry rule for retryable 503 responses. Run 6 was the first run with that rule.

Runs 6 and 7 used the final script. In run 6, topic search returned a 503 three times in a row. The third error body said that there were 5 failures in 10 minutes for that capability and that none was charged. It suggested one test request with an example that it gave, to find out if the problem was the target or the service. In run 7, comment replies returned a 503 with the reason capacity_exhausted.

That means the capability had no free capacity on the service side at that moment. The error text said clearly that this was not the caller's rate limit, and the call was refunded. Across the seven runs, hot search, post search, comments and user timelines worked every time. Topic search worked 5 times out of 7, and post detail 6 times out of 7.

| Capability | Calls in runs 1–7 | HTTP 200 | Empty (refunded) | Failed (free) | Total charge |
| --- | --- | --- | --- | --- | --- |
| `weibo/trending` | 7 | 7 | 0 | 0 | $0.003892 |
| `weibo/topic_search` | 7 | 5 | 0 | 2 | $0.004030 |
| `weibo/search` | 7 | 7 | 0 | 0 | $0.005642 |
| `weibo/post_detail` | 7 | 6 | 0 | 1 | $0.004836 |
| `weibo/comments` | 7 | 7 | 1 | 0 | $0.003336 |
| `weibo/comment_replies` | 6 | 5 | 2 | 1 | $0.002418 |
| `weibo/reposts` | 8 | 3 | 0 | 5 | $0.002418 |
| `weibo/user_posts` | 8 | 8 | 0 | 0 | $0.006448 |

![Screenshot of two dark code cards. The left card is the weibo/topic_search request at 00:19:36 for the keyword Singles Day, with count 20. It shows the first two topics, Singles Day with 33,336,000 discussions and 13,980,000,000 reads, and a Weibo membership Singles Day topic with 990,000 discussions and 610,000,000 reads, then billing with charged_usd 0.000806 and a shortened next_page_token. The right card is the weibo/comment_replies request at 00:31:50 with count 1. It shows one reply with root_comment_id, reply_to_comment_id and an ip_location of Heilongjiang. The author name shows as hidden, and charged_usd is 0.000806.](https://everyinfra.com/articles/weibo-api-python/img-api-response.webp)

Two real responses. We kept the first two results, hid author names and removed balance fields. [EveryInfra API responses, November 11, 2026, 00:19 and 00:31 Singapore time](https://api.everyinfra.com/api/v1/social/catalog)

## The trap: the most-commented post is often not your post

The first script used a natural rule. It took the search result with the most comments, and it preferred posts with more than 20 comments. In four runs, this rule picked a post without the keyword every time. For "flu", it picked a fan-fiction post about an anime. That post was in the results because a hashtag or the long-text part matched, not the visible text.

For "flu vaccine", it picked a landscape photo from a photography account with 5.94 million followers. For "Singles Day", it picked a post about how people can only save money on food and clothes. That post is close to the shopping festival, but it does not name it. For "Chilean cherries", it picked a pre-sale card from an online shop.

We then counted every row of the four searches. The limit was 50 each time. The hot keywords "flu", "Singles Day" and "flu vaccine" returned only 12, 17 and 11 rows. Of those, 8, 12 and 6 rows had the keyword in the text: 26 of 40, or 65%.

The quiet keyword "Chilean cherries" returned the full 50 rows, but only 24 (48%) had the keyword in the text. Most of the others were the same group of shop cards and reposts with a hashtag. The rows without the keyword in their text had more comments. Large accounts are easier to find through a hashtag, a long text or a reposted original, and their posts get more comments anyway.

![Stacked horizontal bars for the rows of four weibo/search calls with limit 50. Test 1, flu: 8 rows with the keyword in the text, 4 rows without it, 38 empty slots. Test 2, Singles Day: 12, 5 and 33. Test 3, flu vaccine: 6, 5 and 39. Test 4, Chilean cherries: 24, 26 and 0. The part with the keyword is teal.](https://everyinfra.com/articles/weibo-api-python/fig-03-search-yield-bar.en.light.svg)

The fix is one line: filter on `keyword in text` first, then sort by comment count. Runs 6 and 7 used this line. The results show why it is necessary, and also why it is not enough. In run 7, the row with the most comments of 15 rows had 312 comments.

It was an advertisement for online Chinese classes for children abroad, posted on January 17, 2025, and its text did not contain "flu". The old rule would have picked it. With the filter, the script picked an ordinary post with 2 comments, by someone who worried about a sore throat and the flu.

In run 6, 37 of 38 rows had "flu" in the text. But all of them were from the 15 minutes between 00:36 and 00:51. The most-commented row had 1 comment. After the filter, the script picked a post that a quiz mini-game had shared automatically (the device field showed the name of the game).

It had 0 comments, and the comment call returned an empty list, which was refunded. A filter stops you from picking the wrong post, but it cannot create engagement. For a comment sample, wait until posts have had time to collect comments, or use topic search first to find topics with many discussions.

For research sampling, one line is still not enough. The code below splits the search results into two groups. The first group matches in the text. The second group matches only through a hashtag or a repost.

It counts each group. You can then decide whether the second group belongs in your sample. We suggest that you keep both groups but report their numbers separately. If you do not, one landscape photo from a large account can skew your "flu vaccine discussion" sample.

```text
import json, sys

def split_rows(path, keyword):
    rows = json.load(open(path))["response"]["results"]
    hit = [r for r in rows if keyword in (r.get("text") or "")]
    other = [r for r in rows if keyword not in (r.get("text") or "")]
    def summary(group):
        return {"rows": len(group),
                "comments": sum(int(r.get("comment_count") or 0) for r in group),
                "verified": sum(1 for r in group if r.get("author_verified")),
                "newest": max((r["posted_at"] for r in group), default=None)}
    return {"keyword_in_text": summary(hit), "keyword_elsewhere": summary(other)}

print(json.dumps(split_rows(sys.argv[1], sys.argv[2]), ensure_ascii=False, indent=1))
```

The second finding is about time. For the same keyword, "flu", the search at 00:14 returned 12 rows posted between November 3 and November 10. The search at 00:46 returned the full 50 rows. 49 of them had "flu" in the text, and all of them were posted in the last 20 minutes (00:27 to 00:46 Singapore time).

So `weibo/search` returns a window that changes from minute to minute. For a hot keyword, the window sometimes holds only the newest posts and sometimes mixes in older posts with more engagement. For research, a fixed sampling time each day matters more than getting 50 rows in one call.

## Pagination: which capabilities can page

The Weibo capabilities do not all page in the same way. Before you write a loop, check the `page_token` field in the catalog. The table shows the parameters in the catalog on November 11, 2026, and the rows per call that we got.

| Capability | Limit per call | Paging | Rows per call in our tests |
| --- | --- | --- | --- |
| `weibo/trending` | limit up to 200 | None; one call gets the list | 50 (we asked for 50) |
| `weibo/search` | limit 20 by default, up to 50 | No page_token | 11, 12, 15, 15, 17, 19, 38, 50, 50 |
| `weibo/topic_search` | 20 per page | page_token, valid for 24 hours | 18, 20, 19, 19, 18; page 2: 10 |
| `weibo/comments` | limit up to 50 | No page_token | 2, 24, 5, 12, 21, 2, 0, 1 |
| `weibo/comment_replies` | limit up to 20 | None | 0, 1, 1, 0, 1 |
| `weibo/reposts` | limit up to 20 | None | 3, 14, 20 |
| `weibo/user_posts` | 20 per page | page_token, valid for 24 hours; post_type can be all, image, original or video | 10 per page; both pages had 10 |

The catalog says that `weibo/user_posts` returns up to 20 rows per page. In our 8 calls, it returned 10 rows each time. The charge is per call, so we based the cost per 1,000 rows on 10 rows. For `topic_search`, pass the `next_page_token` back as it is to get the next page.

The second page returned 10 topics, and after that the token was empty, which means the end. `weibo/search` has no paging parameter. For the same keyword, limit 20 returned 15 rows, and limit 50 eight seconds later returned 19 rows. For a larger sample, use more keyword combinations or more sampling times.

## Fields: what each step returns, and what is often missing

Post rows come from search, post_detail, user_posts and reposts. They have 15 to 19 fields: id, url, text, posted_at, like_count, comment_count, repost_count and image_urls. They also have the author id, follower count, following count, verified flag, verification text, posting device and is_repost. `post_detail` adds is_long_text, which tells you if the text is a long post. Repost rows add original_post_id.

The catalog says that `post_detail` can return view_count (the read count), but none of our 4 detail calls in the first four runs returned it. In run 4, "Chilean cherries", the 50 search rows had no author follower count column. Only the detail call had it. So call post detail first if you want to filter by follower count.

Comment rows have only 10 fields: id, text, like_count, posted_at, the author id and name, the avatar, post_id, post_url and platform. They have no ip_location and no reply count. So you cannot tell from the comment list which comments have replies. You can only pick by likes. Reply rows add root_comment_id, reply_to_comment_id and ip_location.

In the replies we got, ip_location showed a province, such as "from Heilongjiang". One reply showed a bot name in that field instead. The reply came from an automated comment bot account that the platform runs. That bot wrote 2 of the 24 comments under the run 2 post, and it wrote the only reply under the most-liked comment. For sentiment or opinion analysis, tag such bot accounts by author first.

Counts also change. In run 2, the post showed 41 comments and 447 reposts in the search results. Ten seconds later, post detail showed 36 comments and 397 reposts. Fifteen minutes later, we read the comments of the same post again and got 21 rows, against 24 the first time.

We cannot tell if this came from deleted comments, folded comments or a counting delay. So we state it as a data limit: the counts and the comment list of one post can change within minutes. Your report must state the collection time.

| Row type | Fields | Has | Does not have |
| --- | --- | --- | --- |
| Post (search, user_posts) | 15–19 | text, time, likes, comments, reposts, images, author counts, device | view_count; author follower count is sometimes missing in search rows |
| Post detail | 17–18 | the same, plus is_long_text | view_count (in our calls) |
| Repost | post fields plus original_post_id | link to the original post | — |
| Comment | 10 | text, likes, time, author, post link | ip_location, reply count |
| Reply | 11 | root_comment_id, reply_to_comment_id, ip_location | reply count |

![Column chart of the comment count on four posts and the rows that weibo/comments returned. Test 1: 4 against 2 (50%). Test 2: 36 against 24 (67%). Test 3: 6 against 5 (83%). Test 4: 25 against 12 (48%). Grey columns are the counts and teal columns are the rows returned.](https://everyinfra.com/articles/weibo-api-python/fig-05-comment-coverage-bar.en.light.svg)

## Cost per 1,000 rows: hot search is cheapest, user timelines cost most

The unit price alone can mislead you, because the number of rows per call changes a lot. We added up the charges of all real calls and divided by the number of rows that came back. That gives the cost per 1,000 rows. Empty results were refunded, so they are not in the totals. The calculation uses only the raw JSON. Here is the script.

```text
import glob, json
from collections import defaultdict

agg = defaultdict(lambda: {"calls": 0, "rows": 0, "usd": 0.0})
for f in glob.glob("raw/run*/[1-9]_*.json"):
    d = json.load(open(f))
    resp, action = d["response"], d["request"]["action"]
    a = agg[action]
    a["calls"] += 1
    a["rows"] += len(resp.get("results") or [])
    a["usd"] += (resp.get("billing") or {}).get("charged_usd", 0.0)
for action, a in sorted(agg.items()):
    per_1000 = a["usd"] / a["rows"] * 1000 if a["rows"] else None
    print(f"{action:16} calls={a['calls']:2} rows={a['rows']:4} usd={a['usd']:.6f} per_1000={per_1000}")
```

These are the results from the first four runs and the extra tests. The hot search list costs about $0.0111 per 1,000 rows, because one call with 50 rows costs only $0.000556. Post search costs about $0.039, comments about $0.043, topic search about $0.047 and reposts about $0.065. User timelines cost about $0.081, because each page returned only 10 rows.

Post detail costs $0.806 per 1,000 posts. Comment replies returned only 3 rows in 6 calls, which is too small a sample for a cost per 1,000 rows. To put it another way, $1 buys 1,798 hot search snapshots, or about 23,000 comments, or detail for 1,240 posts.

![Horizontal bar chart of the cost per 1,000 rows, from real row counts and real charges. weibo/trending is $0.0111 and is the shortest bar, in teal. weibo/search is $0.0390, weibo/comments $0.0434, weibo/topic_search $0.0469, weibo/reposts $0.0654 and weibo/user_posts $0.0806.](https://everyinfra.com/articles/weibo-api-python/fig-04-cost-per-1000-bar.en.light.svg)

## Cross-domain example: a public-health timeline from the weibo hot search api

Flu season is a good time to test whether the hot search list can work as a public-health signal. Look at the [weekly flu report of the Chinese Center for Disease Control and Prevention](https://www.chinacdc.cn/jksj/jksj04_14249/202611/t20261105_1842732.html), with data to November 1, 2026. The flu test positive rate fell slightly in southern provinces and rose in northern provinces. It also lists 106 reported outbreaks of influenza-like illness across the country. In early November, city governments such as [Beijing](https://www.beijing.gov.cn/fuwu/bmfw/sy/jrts/202611/t20261104_4931879.html) and [Shanghai](https://www.shanghai.gov.cn/nw17239/20261106/de579962c67d46c6888397fc74bb9b0d.html) posted notices about flu vaccination. Our question was simple: in the same period, how many flu items could you see on the Weibo hot search list?

### Method: one snapshot every 20 minutes

We called `weibo/trending` (limit 50) from 00:14 to 03:22 Singapore time on November 11, 2026. Singapore time is the same as Beijing time. The test chains took 6 snapshots, and a background script took one more every 20 minutes. That gave 16 snapshots and 800 rows, for 16 × $0.000556 = $0.0089. We kept each raw JSON response. Then the code below builds a table of item × time with the rank of each item, and picks the public-health items by keyword.

```text
import glob, json, re
from collections import defaultdict

HEALTH = re.compile(r"流感|疫苗|疾控|病毒|感染|呼吸道|支原体|发热|医院|医保|卫健|健康|疫情|肺炎|诺如")  # flu, vaccine, CDC, virus ...
snaps = []
for f in glob.glob("raw/run*/1_trending.json") + glob.glob("raw/trending/*.json"):
    d = json.load(open(f))
    if d.get("http_status") == 200:
        t = (d.get("started_sgt") or f[-11:-5]).replace(":", "")[:4]
        snaps.append((t[:2] + ":" + t[2:], d["response"]["results"]))
snaps.sort()
ranks = defaultdict(dict)                      # title -> {time: rank}
for t, rows in snaps:
    for r in rows:
        ranks[r["title"]][t] = r["rank"]
health = {k: v for k, v in ranks.items() if HEALTH.search(k)}
print(len(snaps), "snapshots,", len(ranks), "distinct titles,", len(health), "health titles")
for k, v in health.items():
    print(k, [v.get(t) for t, _ in snaps])     # None = not on the list at that moment
```

![Line chart of the rank of 5 items across 16 hot search snapshots from 00:14 to 03:22. A current-affairs item about China's opening from the import expo to APEC, the thick teal line, stays at rank 3 in all 16 snapshots. A public-news item about a murder-case interrogation video stays between rank 6 and rank 9. An item about the school-age population peak drops from rank 6 to rank 29 at 01:42, reaches rank 49 at 03:02, and then leaves the list. Two health items are dashed lines: one about Alzheimer's disease enters at rank 45 at 01:42 and then stays at rank 36 to 38, and one about a 13-year-old girl with stomach cancer enters at rank 44 at 03:02.](https://everyinfra.com/articles/weibo-api-python/fig-06-trending-timeline-line.en.light.svg)

### What we saw

First, in more than three hours and 800 rows, no item was about flu or vaccines. Our keyword rule matched only one item, which entered the list at 03:02. It was a story about a 13-year-old girl with a year of stomach pain. Her parents ignored it, and then doctors found stomach cancer.

The platform's own "health and medical" category had 2 items. The other one entered at 01:42 and was about what Alzheimer's disease really looks like. Both items were below rank 36.

| Time (SGT) | Heat of rank 1 | Sum of top 50 heat | Items labeled new | Health and medical items |
| --- | --- | --- | --- | --- |
| 00:14 | 1,420,924 | 32,969,020 | 24 | 0 |
| 00:47 | 989,134 | 19,627,245 | 19 | 0 |
| 01:22 | 624,281 | 14,306,377 | 13 | 0 |
| 02:02 | 385,092 | 9,104,366 | 8 | 1 |
| 02:42 | 240,000 | 3,536,945 | 9 | 1 |
| 03:22 | 157,733 | 2,942,261 | 8 | 2 |

In the same period, `weibo/topic_search` for "flu" showed the #Flu# topic with 540 million reads and 490,000 discussions. A topic about flu-season protection for families had 78.43 million reads. The topics have large totals, but the hot search list did not show them. The list shows what is climbing right now, not how many people keep talking about a topic.

For flu-season research, use the read and discussion counts from topic search as the main measure. Add post search at fixed times. Both are better than the hot search list.

Second, heat scores drop a lot at night, so you cannot compare them across times. The Golden Rooster Awards winners list was at rank 1 in all 16 snapshots, but its heat score fell from 1.42 million to 158,000. The sum of the top 50 heat scores fell from 32.97 million to 2.94 million, a drop of 91%. Plot heat scores from different times on one line, and you mostly see the daily rhythm of users.

You do not see the rise and fall of the topic. A 2022 study of the hot search list by Cui and Kertész ([arXiv:2208.10176](https://arxiv.org/abs/2208.10176)) also discusses how the daily rhythm affects the popularity of items. Our method: compare ranks across times, or compare the relative heat inside one snapshot (the heat of an item divided by the heat of rank 1 at that time), and sample at the same times each day.

Third, the heat score does not fully decide the rank. Ranks 1, 3 and 4 had the same item in all 16 snapshots. The rank 3 item, about China's opening from the import expo to APEC, had a heat score between 1.13 million and 97,000. Its ratio to rank 1 changed from 0.43 to 0.95, but its rank never moved.

Three hours of data cannot show the cause, and we make no claim about it. For a researcher, one thing is certain. The rank comes from the rules of the list, so do not treat it as a simple function of the heat score.

Fourth, a 20-minute interval misses short-lived items. The 16 snapshots had 85 different items. Seven of them appeared only once, and 23 appeared every time.

| Platform category | Distinct items in 16 snapshots |
| --- | --- |
| Public news | 18 |
| Variety shows | 16 |
| Film | 13 |
| Celebrities | 7 |
| Esports | 6 |
| Finance | 4 |
| Health and medical | 2 |
| Other categories | 19 |

If you want to study how long a health message stays on the list, use an interval of 5 minutes or less. The cost grows in direct proportion to the number of snapshots, at the unit price above.

### Data limits

The [hot search rules page](https://m.s.weibo.com/vtopic/datadescription?tab=rank) says that Weibo calculates heat as real-time heat × field attention × reach across groups × quality. It says that the list updates every minute, that it shows the top 50, and that some items carry a commercial advertisement label. The labels in our 800 rows were only new, hot, boiling and blank, so we saw no paid item. For long-term collection, still tag paid items separately.

Treat the list as a record of what the platform showed at one moment. It is useful for agenda and exposure research. It does not represent a population, and you cannot use it to estimate how many people are sick.

A 2023 study in JMIR ([e49300](https://doi.org/10.2196/49300)) looked at public feeling about influenza A. It used all related Weibo posts from November 2022 to March 2023, not the hot search list. That is the safer design. This article makes no claim about how common any disease is, how well a vaccine works, or what a policy should be.

## Three scenarios and their monthly bills

We put the unit prices and the rows per call from our tests into three real use cases. The API fees are low in all three. The first is a public-health research group that builds a flu-season hot search timeline. It takes a hot search snapshot every 10 minutes (4,320 per month). Each day it reads 2 topic pages and runs one post search for each of 5 keywords.

It also reads detail, comments and reposts for 3 posts. The second is a newsroom China desk that follows a 72-hour breaking story. It takes a snapshot every 5 minutes, searches 10 keywords every hour, and reads detail, comments, replies and reposts for 60 posts. The third is a Chilean cherry exporter that watches the Chinese market and searches 6 keywords every day for 4 weeks.

| Scenario | Requests | Hot search snapshots | Search and topic search | Posts, comments, reposts, timelines | Total |
| --- | --- | --- | --- | --- | --- |
| Flu-season timeline (30 days) | 5,040 | $2.40 | $0.36 | $0.20 | $2.96 |
| Breaking-news desk (72 hours) | 1,854 | $0.48 | $0.60 | $0.18 | $1.26 |
| Chilean cherry exporter (4 weeks) | 624 | $0.06 | $0.15 | $0.22 | $0.44 |

![Stacked horizontal bars for the API fees of three scenarios. Flu-season timeline for 30 days: $2.96 in total, of which hot search snapshots are $2.40, in teal. Breaking-news desk for 72 hours: $1.26, with $0.48 for hot search and $0.60 for search. Chilean cherry exporter for 4 weeks: $0.44 in total.](https://everyinfra.com/articles/weibo-api-python/fig-07-scenario-cost-bar.en.light.svg)

In the timeline scenario, 81% of the money goes to hot search snapshots, so the snapshot interval is the first setting to decide. The open platform suggests a refresh every 3 to 5 minutes, and the hot search rules say that the list updates every minute. In our experience, one snapshot every 10 minutes is enough for research to see an item enter, climb and leave the list. If you double the frequency, you double the cost. These numbers are API fees only. They do not include storage, analysis or staff time.

## Errors and charges: when you pay nothing

At about 00:30 we ran a few error tests on purpose, and none of them cost money. A request without a key returned 401. The API checks the key before it checks parameters, so a caller without a key cannot probe the parameter structure. `weibo/user_posts` with post_type set to originals returned 422.

The error message listed the allowed values all, image, original and video, and suggested that you probably meant original. The paused `weibo/user_post_search` returned 503 unavailable, with no charge. In the live tests, every 429, every retryable 503 and every empty result cost $0.

| Test | HTTP status | What the response said | Charge |
| --- | --- | --- | --- |
| No API key | 401 | The key is required; nothing was charged | $0 |
| `weibo/user_posts` with post_type originals | 422 | Allowed values all, image, original, video; did you mean original | $0 |
| `weibo/user_post_search` (paused) | 503 | unavailable | $0 |
| Rate limit during live runs | 429 | Wait and retry | $0 |
| Capacity full (run 7) | 503 | capacity_exhausted; not your rate limit; retry after 25 s | $0 |

This matters if you write automation. Retries cost nothing, so your script can safely retry after `retry_after`. But if the same request succeeds twice, you pay twice. So retry only on clear failure states.

Do not resend a successful response, except after a timeout where you did not get a response. To match charges and refunds in your own books, read [failure refund reconciliation](/en/build/failure-refund-reconciliation). For retries, read [idempotency keys for AI agent retries](/en/blog/api-idempotency-key-ai-agent-retry).

## When the other two routes fit better

A pay-per-call API is not the best answer for everyone. Some jobs need the official platform. Examples are posting for users, replying to comments, pinning posts, and showing the followers of your own users in your app. No third-party API should do that for you.

Your organization may collect data at large scale and sell analysis to others. Then clause 2.7.8 of the developer agreement tells you to use the commercial data API and sign a contract. That route gives a contract and a data scope that a per-call API cannot give.

An open-source script also fits some cases. You may need all the history of one public account for a thesis, a few thousand posts. You may also be happy to spend an afternoon on the cookie and the delays. Or you may need a field that a project already parses, such as the Live Photo videos and archive check reports of weibo-crawler.

Then the extra cost of running a script is close to zero. But you may take a hot search snapshot every 10 minutes and run dozens of keywords each day. You may not want one account cookie to be a single point of failure. Then a per-call API is easier.

| Your job | Best route | Why |
| --- | --- | --- |
| Post, reply or show your own users' data in your app | Official open platform | Only route with write access and user consent |
| Sell analysis of Weibo data to clients at scale | Commercial data API | Clause 2.7.8 asks for a signed agreement |
| One-time download of one public account for a thesis | Open-source script | Near-zero extra cost if you accept the cookie work |
| Daily hot search, topic and post collection for news or research | Pay-per-call API | No cookie to maintain; failures and empty results are free |

## Further reading

For sample bias, read [sample integrity in social media research](/en/blog/social-media-research-sample-integrity). For AI-written scrapers, read our [GLM-5.3 and Claude Code test](/en/blog/glm-5-3-claude-code-zhihu-weibo-scripts). For Douyin, read [Douyin API in Python: three routes, tested](/en/blog/douyin-api-python). For health signals, read [social signal monitoring for health misinformation](/en/blog/health-misinformation-social-signal-monitoring).

## Compliance and limits

Whichever route you use, some legal limits are the same. China's [Personal Information Protection Law](https://www.cac.gov.cn/2021-08/20/c_1631050028355286.htm) lists the legal bases for processing personal information in Article 13. Article 27 allows you to process personal information that is already lawfully public, within a reasonable scope. Two cases are excluded: the person clearly refuses, or the processing has a major effect on the rights of the person. User names, locations and the text of comments are personal information.

Also see Article 13 of the [Anti-Unfair Competition Law as revised in 2025](https://www.cnipa.gov.cn/art/2026/5/20/art_104_206437.html). You must not get data that others hold lawfully by means that break good faith. Breaking or avoiding technical controls is one such means. The [Network Data Security Management Regulations](https://www.mee.gov.cn/zcwj/gwywj/202410/t20241003_1087417.shtml), in force since January 1, 2025, give more detailed security duties for network data handlers. If you work outside China, the data protection law of your own country can also apply to what you store and publish.

Our own practice in this article was as follows. We collected only public content. We did not log in to any account, and we did not touch private messages or posts that only followers can see. We hid the names of comment authors in this article. In a research report, quote only totals or paraphrased views from comments.

Do not quote original text that someone can trace back to a person. This article does not teach any method to get around the limits of the platform. We quoted the cookie and speed notes of the open-source projects to show the upkeep cost of that route. We do not tell you to use it.

## Frequently asked questions

### Is there a weibo api python example that I can run?

Yes. The script in the "Route 3" section runs as it is. Install requests, put your key in the environment variable `EVERYINFRA_API_KEY`, and run `python weibo_chain.py "<keyword>" run1`. The script calls the 7 capabilities in order and saves the raw response of each step as JSON.

If you want an official Python example from the open platform, the documentation on open.weibo.com mostly describes HTTP endpoints. You must complete OAuth to get an access_token first, and the authorized user limits what you can read.

### How do I get a weibo api key?

On the official platform, you get an App Key and an App Secret when you create an app on open.weibo.com. Each call also needs an access_token from user consent. For weibo-cli, you need a face check in the Weibo app, and the trial is open only to an allow list. For a pay-per-call API, you create the key in the console.

Whichever key you have, do not write it in code or commit it to a repository. The scripts in this article read the key only from an environment variable. If a key leaks, revoke it in the console and create a new one.

### Is there a weibo search api?

On the official platform, keyword search exists only as the advanced endpoint 2/search/topics. It searches hashtag topics only, returns the newest 200 results, and needs an application. Per-row keyword data is part of the commercial data API under contract. With a pay-per-call API, `weibo/search` searches posts by keyword (up to 50 rows per call, no paging) and `weibo/topic_search` searches hashtag topics with paging.

### Is there a free weibo hot search api?

The [endpoint list on open.weibo.com](https://open.weibo.com/wiki/%E5%BE%AE%E5%8D%9AAPI) has four groups: OAuth 2.0, posts, comments and users. It has no hot search group. The hot search page itself is public in a browser. With a pay-per-call API, one `weibo/trending` call with 50 rows costs $0.000556, so a snapshot every 10 minutes for 30 days costs about $2.40. Each row has rank, title, category, hot_value, label (new, hot, boiling and others), is_hot, is_new and a link to the topic.

### How do I get replies to Weibo comments in Python?

First get top-level comments with `weibo/comments`. Then pass the id of one comment to `weibo/comment_replies`. Comment rows have no reply count, so you cannot tell which comments have replies. In our 6 calls, 2 returned an empty list (refunded) and 1 returned a 503 at capacity (refunded).

In practice, start with the most-liked comments. Reply rows include root_comment_id, reply_to_comment_id and ip_location.

## Get started

1. Create an API key in the console and put it in the environment variable `EVERYINFRA_API_KEY`. The steps are in the [quickstart](/en/docs#quickstart).
1. Read the catalog once for free at `GET /api/v1/social/catalog?platform=weibo` and check the parameters, prices and `available` flags. You can also see prices on the [pricing page](/en/pricing) and in the [data market](/en/market). Each Weibo capability is described on the [Weibo data API](/en/weibo-api) page.
1. Run `pip install requests`, copy the script from the "Route 3" section, and run `python weibo_chain.py "your keyword" run1`.
1. Open the JSON files in the run1 folder and check `billing.charged_usd` for each step. To follow an author's history, call `weibo/user_posts` and pass `next_page_token` back as it is.
1. If you want an AI assistant to call these capabilities directly, connect the [MCP server](/en/mcp-server). The tools and prices are the same as the HTTP API.

Parameter pages for each capability: [weibo/search](/en/weibo-api/search), [weibo/trending](/en/weibo-api/trending), [weibo/topic_search](/en/weibo-api/topic_search), [weibo/post_detail](/en/weibo-api/post_detail), [weibo/comments](/en/weibo-api/comments), [weibo/comment_replies](/en/weibo-api/comment_replies), [weibo/reposts](/en/weibo-api/reposts) and [weibo/user_posts](/en/weibo-api/user_posts). For similar platforms, compare the [Douyin data API](/en/douyin-api), the [Bilibili data API](/en/bilibili-api) and the [Xiaohongshu data API](/en/xiaohongshu-api).

## References

1. Weibo Open Platform, API access frequency limits (in Chinese), updated May 15, 2025, read November 11, 2026, https://open.weibo.com/wiki/%E6%8E%A5%E5%8F%A3%E8%AE%BF%E9%97%AE%E9%A2%91%E6%AC%A1%E6%9D%83%E9%99%90
1. Weibo Open Platform, developer agreement (in Chinese), read November 11, 2026, https://open.weibo.com/wiki/%E5%BC%80%E5%8F%91%E8%80%85%E5%8D%8F%E8%AE%AE
1. Weibo Open Platform, advanced endpoint application (in Chinese), read November 11, 2026, https://open.weibo.com/wiki/%E9%AB%98%E7%BA%A7%E6%8E%A5%E5%8F%A3%E7%94%B3%E8%AF%B7
1. Weibo Open Platform, 2/comments/show (in Chinese), read November 11, 2026, https://open.weibo.com/wiki/2/comments/show
1. Weibo Open Platform, 2/statuses/user_timeline (in Chinese), read November 11, 2026, https://open.weibo.com/wiki/2/statuses/user_timeline
1. Weibo Open Platform, 2/search/topics (in Chinese), read November 11, 2026, https://open.weibo.com/wiki/2/search/topics
1. Weibo Open Platform, 2/statuses/public_timeline (in Chinese), read November 11, 2026, https://open.weibo.com/wiki/2/statuses/public_timeline
1. Weibo Open Platform, Oauth2/access_token (in Chinese), read November 11, 2026, https://open.weibo.com/wiki/Oauth2/access_token
1. Weibo Open Platform, authorization overview (in Chinese), read November 11, 2026, https://open.weibo.com/wiki/%E6%8E%88%E6%9D%83%E6%9C%BA%E5%88%B6%E8%AF%B4%E6%98%8E
1. Weibo Open Platform, Weibo API endpoint list (in Chinese), read November 11, 2026, https://open.weibo.com/wiki/%E5%BE%AE%E5%8D%9AAPI
1. Weibo Open Platform, Scope (in Chinese), read November 11, 2026, https://open.weibo.com/wiki/Scope
1. Weibo Open Platform, error codes (in Chinese), read November 11, 2026, https://open.weibo.com/wiki/Error_code
1. Weibo Open Platform, weibo-cli manual (in Chinese), read November 11, 2026, https://open.weibo.com/cli/quickstart
1. Weibo Open Platform, weibo-cli command list (in Chinese), read November 11, 2026, https://open.weibo.com/cli/api/cli/commands
1. Weibo commercial data API, home page (in Chinese), read November 11, 2026, https://openapi.sc.weibo.com/
1. npm, @weibo-ai/weibo-cli, version 0.9.8, September 22, 2026, https://www.npmjs.com/package/@weibo-ai/weibo-cli
1. Sina Finance, repost of an IThome report on the launch of weibo-cli (in Chinese), June 26, 2026, https://finance.sina.com.cn/tech/digi/2026-06-26/doc-inietsps5205508.shtml
1. Weibo hot search, rules and data description (in Chinese), read November 12, 2026, https://m.s.weibo.com/vtopic/datadescription?tab=rank
1. Weibo hot search, older rules page (in Chinese), read November 11, 2026, https://m.s.weibo.com/hot/description
1. Weibo, robots.txt, read November 11, 2026, https://weibo.com/robots.txt
1. Weibo mobile site, robots.txt, read November 11, 2026, https://m.weibo.cn/robots.txt
1. GitHub, dataabc/weibo-crawler README, read November 11, 2026, https://github.com/dataabc/weibo-crawler
1. GitHub, dataabc/weiboSpider README, read November 11, 2026, https://github.com/dataabc/weiboSpider
1. GitHub, dataabc/weibo-search README, read November 11, 2026, https://github.com/dataabc/weibo-search
1. GitHub, nghuyong/WeiboSpider README, read November 11, 2026, https://github.com/nghuyong/WeiboSpider
1. GitHub, NanmiCoder/MediaCrawler README, read November 11, 2026, https://github.com/NanmiCoder/MediaCrawler
1. GitHub, stay-leave/weibo-public-opinion-analysis README, read November 11, 2026, https://github.com/stay-leave/weibo-public-opinion-analysis
1. GitHub, weibo-crawler issue #653, September 26, 2026, https://github.com/dataabc/weibo-crawler/issues/653
1. GitHub, weibo-crawler issue #652, September 17, 2026, https://github.com/dataabc/weibo-crawler/issues/652
1. GitHub, weibo-crawler pull request #658, merged November 5, 2026, https://github.com/dataabc/weibo-crawler/pull/658
1. GitHub, weibo-crawler pull request #659, merged November 6, 2026, https://github.com/dataabc/weibo-crawler/pull/659
1. GitHub, weibo-search issue #590, October 13, 2026, https://github.com/dataabc/weibo-search/issues/590
1. GitHub, MediaCrawler pull request #1000, November 4, 2026, https://github.com/NanmiCoder/MediaCrawler/pull/1000
1. EveryInfra, data API catalog, read November 11, 2026, 00:13 Singapore time, https://api.everyinfra.com/api/v1/social/catalog
1. requests documentation, Advanced Usage: Session Objects, read November 11, 2026, https://requests.readthedocs.io/en/latest/user/advanced/#session-objects
1. PyPI, requests, read November 11, 2026, https://pypi.org/project/requests/
1. Cyberspace Administration of China, Personal Information Protection Law of the People's Republic of China (in Chinese), August 20, 2021, https://www.cac.gov.cn/2021-08/20/c_1631050028355286.htm
1. 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
1. 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
1. Competition Law and Policy Research Center, Shanghai Jiao Tong University, ByteDance v. Weibo robots case on appeal (in Chinese), October 21, 2021, https://cclp.sjtu.edu.cn/Show.aspx?info_lb=672&info_id=5120&flag=648
1. Intellectual Property Institute, Guangdong University of Foreign Studies, Sina Weibo v. Maimai unfair competition case, (2016) Jing 73 Min Zhong 588 (in Chinese), read November 11, 2026, https://sciiip.gdufs.edu.cn/info/1028/1083.htm
1. Chinese Center for Disease Control and Prevention, weekly flu surveillance summary to November 1, 2026 (in Chinese), November 5, 2026, https://www.chinacdc.cn/jksj/jksj04_14249/202611/t20261105_1842732.html
1. Beijing Municipal Government, why you need a flu vaccine again this year (in Chinese), November 4, 2026, https://www.beijing.gov.cn/fuwu/bmfw/sy/jrts/202611/t20261104_4931879.html
1. Shanghai Municipal Government, free flu vaccine bookings for union members in Putuo (in Chinese), November 6, 2026, https://www.shanghai.gov.cn/nw17239/20261106/de579962c67d46c6888397fc74bb9b0d.html
1. Cui, H. and Kertész, J., Attention dynamics on the Chinese social media Sina Weibo during the COVID-19 pandemic, EPJ Data Science, 2021, https://doi.org/10.1140/epjds/s13688-021-00263-0
1. Cui, H. and Kertész, J., Competition for popularity and interventions on a Chinese microblogging site, arXiv:2208.10176, version 2, November 30, 2022, https://arxiv.org/abs/2208.10176
1. PubMed, abstract of Cui and Kertész 2021, read November 12, 2026, https://pubmed.ncbi.nlm.nih.gov/33552838/
1. Journal of Medical Internet Research, public sentiment toward influenza A on Weibo (e49300), 2023, https://doi.org/10.2196/49300