Blog/Developer Tools/

Zhihu Public Data API | SandBase

Read public Zhihu questions, answers, articles, hot list, and profiles with one REST API. No Zhihu login, no SDK — one SandBase key, built for agents.

By Sophie Lin
Dark cinematic render of Zhihu question, answer, and profile data flowing through one API conduit into an agent core

Zhihu is China’s largest Q&A and knowledge community — long-form answers, expert columns, a hot list that tracks what the country is debating, and profiles full of domain signal. That maps directly onto knowledge mining, trend research, and expert discovery. Getting at it programmatically usually means reverse-engineering the site, managing cookies, and rebuilding a scraper whenever the markup shifts.

The SandBase Zhihu public data API removes that setup tax. It reads public Zhihu questions, answers, articles, the hot list, search, and user profiles through plain REST endpoints — one SandBase API key, no Zhihu login and no SDK. The endpoint reference guarantees the response envelope (id, status, model, and outputs[0].data); the business fields shown below are illustrative structure, not a guaranteed schema, so confirm them against a live response.

This is not Zhihu’s official open platform. Use Zhihu’s official channels 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 Zhihu endpoints.

Key takeaway

  • One API reads public Zhihu questions, answers, articles, the hot list, search, and profiles.
  • The Model API endpoints in this guide are called with POST /v1/api/zhihu/<path> — pass only that endpoint’s params, no SDK, one SANDBASE_API_KEY.
  • Endpoints key off natural identifiers: a question_id/answer_id/article_id, a user_url_token for a person, or a keyword for search.
  • It returns public, read-only data only. There is no posting, no login on your side, and no private data; authenticate with a SandBase API key.

Which Zhihu API do you need?

Your needChooseWhy
Post, act as a member, or use account-authorized dataZhihu’s official channelsMember and account operations run through Zhihu directly.
Read public questions, answers, articles, or profilesSandBase Zhihu public-data APIPlain REST, one SandBase key, structured JSON for read-only workflows.
Private or account-only dataNeither public workflowThat data is out of scope for this public-data guide.

What you can get from the Zhihu API

The catalog is organized on a web surface. Grouped by job:

  • Hot list & discovery — the trending hot list, hot recommendations, and search suggestions.
  • Search — article, question, video, column, and user search by keyword.
  • Q&A — question detail, its answers, and answer detail.
  • Articles & columns — column article detail, a column’s articles, and comments.
  • Users — public profile info, answers, articles, and pins by user_url_token.

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

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

What Zhihu provides vs. what SandBase adds

Public data comes from Zhihu. SandBase does not own or operate Zhihu; 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 list → open a question → profile the answerer” 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 hot list:

import os
import requests

resp = requests.post(
    "https://api.sandbase.ai/v1/api/zhihu/web/hot-list",
    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", "Zhihu request did not complete"))

# Only the envelope (id/status/model/outputs[0].data) is guaranteed; the nested
# business fields below are illustrative, so read them defensively with .get().
outputs = body.get("outputs") or [{}]
data = outputs[0].get("data", {})
for item in data.get("data", [])[:5]:
    target = item.get("target", {})
    print(target.get("title"), item.get("detail_text"))
curl -X POST https://api.sandbase.ai/v1/api/zhihu/web/hot-list \
  -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. Branch on status before reading outputs[0].data, and check each endpoint’s reference for its run mode. Zhihu list endpoints often nest their items under a data array, and each hot-list item wraps the question under a target object. The block below is an illustrative response shape — the nested business fields are example structure, not a guaranteed schema, so treat the field names and values as examples and confirm them against a live response, since payloads vary and change over time:

{
  "id": "0437c98c-2fc0-4b23-9e40-c986f4512883",
  "status": "completed",
  "model": "zhihu/web/hot-list",
  "outputs": [
    {
      "data": {
        "data": [
          {
            "detail_text": "…",
            "target": { "title": "…", "answer_count": 560, "follower_count": 1701 }
          }
        ]
      }
    }
  ]
}

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

SandBase API reference for a Zhihu 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 listzhihu/web/hot-listTrending-question monitoring
Article searchzhihu/web/article-search-v3Keyword content discovery
Question detailzhihu/web/question-detailRead a question by question_id
Question answerszhihu/web/question-answersPull the answers under a question
User profilezhihu/web/user-infoPublic expert signals by user_url_token

Paging differs by endpoint — several accept a request parameter such as an offset or limit. Read each endpoint’s schema.

SandBase Zhihu endpoint list showing hot-list, search, question, and user endpoints with their paths A slice of the Zhihu endpoint list on the web surface.

Chaining calls in an agent workflow

Because every endpoint shares the same auth and the same response envelope, an agent can walk from a trending question to its expert answerers without special-casing each surface. A common knowledge-research pattern looks like this:

  1. Read the hot list. Call zhihu/web/hot-list to get trending questions, each with a title and a popularity number.
  2. Open the question. Call zhihu/web/question-detail with a question_id, then zhihu/web/question-answers to pull the answers.
  3. Profile the expert. Call zhihu/web/user-info with a user_url_token to attach account context like name, follower count, and answer count.

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

Zhihu hot-list API for trend monitoring

Poll zhihu/web/hot-list on a schedule to track trending questions — each item carries a question title and a popularity number. Input: none. Output: a ranked list of trending questions. Endpoint: hot-list. For a full workflow, see how to mine Zhihu Q&A.

Zhihu search API for content discovery

Run zhihu/web/article-search-v3 with a keyword to survey articles around a topic. Input: a keyword. Output: matching articles. Endpoint: article-search-v3.

Zhihu profile API for expert discovery

Read a public profile with zhihu/web/user-info for fields like name, follower count, and answer count. Input: a user_url_token. Output: a structured profile record. Endpoint: user-info. For a full workflow, see how to do Zhihu expert discovery.

Why run this at the API layer

You could point a headless browser at Zhihu and parse the HTML, but that path is fragile: the markup changes, and you maintain 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 one hot-list question for another, swap one user_url_token for another, and the code path is identical. Add a fourth read — an answer’s detail, 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, 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/account-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 (question_id/answer_id/article_id, user_url_token, keyword); list payloads often nest under a data array; 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 Zhihu partnership. SandBase provides uniform access to public data; respect Zhihu’s terms and applicable rules for your use case.

FAQ

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

What identifies a question, answer, or user? Natural identifiers: a question_id, answer_id, or article_id for content, and a user_url_token for a person. Search takes a keyword.

How does pagination work? It depends on the endpoint — several accept an offset or limit request parameter. Read each endpoint’s schema.

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

Start with the hot list

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