Blog/Developer Tools/

Weibo Public Data API | SandBase

Read public Weibo hot search, posts, and user profiles with one REST API. No Weibo OAuth app, no SDK — one SandBase key, built for agent workflows.

By Sophie Lin
Dark cinematic render of Weibo hot-search, post, and profile data flowing through one API conduit into an agent core

Weibo is where Chinese public opinion, celebrity news, and trending topics surface first, which makes its hot-search board, post streams, and profile data valuable for social listening, market research, and agent workflows. Getting at it programmatically usually means reverse-engineering a mobile app, rotating cookies, and rebuilding a scraper every time the site changes.

The SandBase Weibo public data API removes that setup tax. It reads public Weibo hot search, search results, posts, and user profiles through plain REST endpoints — one SandBase API key, no Weibo login and no SDK. The endpoint API reference is the source of truth for each parameter and for the response envelope; the business-payload field names shown below are an illustrative shape, not a guaranteed schema, so confirm them against a live response for the endpoint you call.

This is not Sina Weibo’s official open platform. Use Weibo’s official APIs when you need authenticated member actions or a licensed data agreement. Use SandBase when your workflow needs public, read-only data for research and monitoring. Ready to try it? Get a SandBase API key and browse the Weibo endpoints.

Key takeaway

  • One API reads public Weibo hot search, search results, posts, comments, and user profiles.
  • The Model API endpoints in this guide are called with POST /v1/api/weibo/<path> — pass only that endpoint’s params, no SDK, one SANDBASE_API_KEY.
  • Endpoints key off natural identifiers: a uid for users, a status_id/mid/id for a post, or a query/keyword for search.
  • It returns public, read-only data only. There is no posting, no login on your side, and no private or follower-only data; authenticate with a SandBase API key.

Which Weibo API do you need?

Your needChooseWhy
Post, act as a member, or use account-authorized dataWeibo’s official platformMember and account operations run through Weibo directly.
Read public hot search, posts, or profilesSandBase Weibo public-data APIPlain REST, one SandBase key, structured JSON for read-only workflows.
Private or follower-only dataNeither public workflowThat data is out of scope for this public-data guide.

What you can get from the Weibo API

The catalog spans several surfaces (an app surface, a web surface, and a newer web-v2 surface). Grouped by job:

  • Hot search & trends — the realtime hot-search board and trend rankings.
  • Search — realtime search, topic search, and advanced search by keyword.
  • Posts — status detail, comments, reposts, and likes for a post.
  • Users — public profile info, timelines, videos, and articles by uid.

Check each endpoint’s live API reference for the exact surface and parameters before you build; availability differs by endpoint.

SandBase Weibo API page: description, capability tags, and the endpoint list The Weibo API page on SandBase — a tagged overview and the endpoint list, each with its path.

What Weibo provides vs. what SandBase adds

Public data comes from Weibo. SandBase does not own or operate Weibo; it provides a uniform API layer for eligible public-data workflows. Each capability becomes one stable endpoint, auth collapses to a single key, and responses come back as predictable JSON — so an agent can chain “read the hot-search board → search a topic → read the author’s profile” along one convention instead of maintaining a scraper.

Quick start: your first call

SandBase exposes more than one API surface. The catalog may show GET paths under /apis/v1/...; this guide uses the vendor-qualified Model API path on each endpoint’s API reference. Do not swap the HTTP method or URL — follow the reference for the endpoint you choose.

Read the realtime hot-search board:

import os
import requests

resp = requests.post(
    "https://api.sandbase.ai/v1/api/weibo/web-v2/hot-search",
    headers={
        "Authorization": f"Bearer {os.environ['SANDBASE_API_KEY']}",
        "Content-Type": "application/json",
    },
    json={},
)
resp.raise_for_status()
body = resp.json()
if body.get("status") != "completed":
    error = body.get("error", {})
    raise RuntimeError(error.get("message", "Weibo request did not complete"))

# The reference guarantees the envelope (id/status/model/outputs[0].data);
# the business-payload keys below are endpoint-specific — read them defensively
# and confirm the exact paths against a live response.
data = body["outputs"][0]["data"]
board = data.get("realtime", []) if isinstance(data, dict) else []
for item in board[:5]:
    print(item.get("rank"), item.get("word"), item.get("num"))
curl -X POST https://api.sandbase.ai/v1/api/weibo/web-v2/hot-search \
  -H "Authorization: Bearer $SANDBASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{}'

Every response uses the same envelope: an id, a status, the model name, and an outputs array whose single item carries the payload under data. That envelope is what the endpoint reference guarantees; the operation-specific fields inside data are documented per endpoint, and some references show data empty where no safe example is confirmed. Branch on status before reading outputs[0].data, and check each endpoint’s reference for its run mode. The block below is an illustrative response shape — treat the field names and values as an example, not a guaranteed schema, and confirm them against a live response, since payloads vary and change over time:

{
  "id": "cb805c67-4817-4926-9639-24a15e694cc9",
  "status": "completed",
  "model": "weibo/web-v2/hot-search",
  "outputs": [
    {
      "data": {
        "realtime": [
          { "rank": 0, "word": "…", "note": "…", "num": 1172365 }
        ]
      }
    }
  ]
}

A failed or timeout run carries error and never outputs, so branch on status first. Response shapes differ by endpoint — inspect one real response and map the exact path per endpoint.

SandBase API reference for a Weibo endpoint, showing the vendor-qualified URL and the response schema The endpoint API reference is the source of truth for each parameter name and response path.

Capability map

Capability clusterRepresentative endpointTypical use
Hot searchweibo/web-v2/hot-searchTrending-topic monitoring
Realtime searchweibo/web-v2/realtime-searchTopic and keyword discovery
User profileweibo/web-v2/user-basic-infoPublic account signals by uid
Post detailweibo/app/status-detailRead a single post by status_id
Post commentsweibo/app/status-commentsEngagement and sentiment inputs

Paging differs by endpoint — several endpoints accept a request parameter such as a page or cursor value. Read each endpoint’s schema.

SandBase Weibo endpoint list showing hot-search, search, user, and post endpoints with their paths A slice of the Weibo endpoint list across the app, web, and web-v2 surfaces.

Chaining calls in an agent workflow

Because every endpoint shares the same auth and the same response envelope, an agent can walk from a trend to an author without special-casing each surface. A common social-listening pattern looks like this:

  1. Read the board. Call weibo/web-v2/hot-search to get the realtime hot-search list, then pick the topics you care about.
  2. Search the topic. Call weibo/web-v2/realtime-search with a query to pull matching posts.
  3. Profile the author. Call weibo/web-v2/user-basic-info with a uid to attach account context like screen name and follower counts.

Each step returns the same { id, status, model, outputs } shape, so your agent branches on status once and reuses the same JSON-reading code across every step.

Common use cases

Weibo hot-search API for trend monitoring

Poll weibo/web-v2/hot-search on a schedule to track the realtime board — each item carries a ranked keyword and a popularity number. Input: none. Output: a ranked list of trending topics. Endpoint: hot-search. For a full workflow, see how to monitor Weibo hot search.

Weibo search API for topic discovery

Run weibo/web-v2/realtime-search with a query to surface posts around a topic. Input: a query. Output: matching posts. Endpoint: realtime-search.

Weibo profile API for account research

Read a public profile with weibo/web-v2/user-basic-info for fields like screen name and follower counts. Input: a uid. Output: a structured profile record. Endpoint: user-basic-info.

Why run this at the API layer

You could point a headless browser at Weibo and parse the HTML, but that path is fragile: the markup changes, mobile and web render differently, and you end up maintaining selectors instead of shipping features. Reading through one uniform API means your code depends on named JSON fields and a single response envelope rather than a page layout. Auth is one key instead of rotating cookies, and because every endpoint returns the same { id, status, model, outputs } shape, retries, logging, and error handling live in one helper you write once and reuse everywhere.

That uniformity is what makes the workflow composable for an agent. Swap the hot-search topic for any keyword, swap one uid for another, and the code path is identical. Add a fourth read — a post’s comments, say — and it slots in behind the same status-checking helper. The practical payoff is that your time goes to what the data means for your research or monitoring, not to keeping a scraper alive against a moving target. When you need more than single reads, check the live listing for the endpoint that fits and confirm its parameters before wiring it in.

Limitations and boundaries

  • Public, read-only data only. No posting, following, or private/follower-only data.
  • Rate and volume. Treat responses as best-effort reads; as a client-side resilience measure, retry with backoff on transient errors such as HTTP 429.
  • Parameters and shapes follow the upstream surface. Identifiers vary (uid, status_id/mid/id, query/keyword); paging is a per-endpoint request parameter. Inspect a real response and read the schema first.
  • Verify endpoints against the live reference. Availability and fields can change; confirm before building on a specific endpoint.
  • This is not an official Weibo partnership. SandBase provides uniform access to public data; respect Weibo’s terms and applicable rules for your use case.

FAQ

Do I need a Weibo developer app or login? No. You authenticate to SandBase with your SANDBASE_API_KEY. These read endpoints do not require a Weibo account or OAuth on your side.

What identifies a user or post? Natural identifiers: a uid for users and a status_id/mid/id for a post. Search takes a query or keyword.

How does pagination work? It depends on the endpoint — several accept a per-endpoint page or cursor request parameter. Read each endpoint’s schema.

Can I read private or follower-only data? No. The API returns public data only. Private accounts and follower-only content are out of scope.

Start with the hot-search board

Create a SandBase API key, call hot-search, and inspect the returned schema before you expand to search, posts, or profiles. When you are ready: