Blog/Developer Tools/

WeChat Search Public Data API | SandBase

Query WeChat Search (搜一搜) for public results and videos with one REST API. No WeChat login, no SDK — one SandBase key, built for agent workflows.

By Sophie Lin
Dark cinematic render of WeChat Search result and video data flowing through one API conduit into an agent core

WeChat Search (微信搜一搜) is the search box inside China’s dominant messaging super-app — a window into public results and videos across WeChat’s content surfaces. That maps onto topic research, content monitoring, and trend detection. Getting at it programmatically usually means reverse-engineering the app, juggling tokens, and rebuilding a scraper each time the app changes.

The SandBase WeChat Search public data API removes that setup tax. It queries WeChat Search for public results and videos through plain REST endpoints — one SandBase API key, no WeChat 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 below come from a search call I ran (tested on 2026-09-27, UTC) and are shown as one observed shape — confirm them against a live response, since payloads change over time.

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

Key takeaway

  • Two endpoints: wechat-search/v2/search for general results and wechat-search/v2/search-videos for videos.
  • The Model API endpoints in this guide are called with POST /v1/api/wechat-search/<path> — pass only that endpoint’s params, no SDK, one SANDBASE_API_KEY.
  • Both take a keyword; results come back alongside paging fields like offset, cursor, continue_flag, and no_more.
  • It returns public, read-only data only. There is no posting, no platform login on your side, and no private data; authenticate with a SandBase API key.

Which WeChat Search API do you need?

Your needChooseWhy
Post, act as a member, or use account-authorized dataWeChat’s official channelsMember and account operations run through WeChat directly.
Query public search results or videos by keywordSandBase WeChat Search public-data APIPlain REST, one SandBase key, structured JSON for read-only workflows.
Private chats or account-only dataNeither public workflowThat data is out of scope for this public-data guide.

What you can get from the WeChat Search API

The catalog is organized on a v2 surface with two search endpoints:

  • General search — search returns public results for a keyword, grouped into categories, with paging fields.
  • Video search — search-videos returns public videos for a keyword, with the same paging convention.

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

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

What WeChat provides vs. what SandBase adds

Public data comes from WeChat. SandBase does not own or operate WeChat; 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 run a keyword search and page through results 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.

Run a keyword search:

import os
import requests

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

# The reference guarantees the envelope; business fields vary, so read
# defensively and confirm the exact paths against a live response.
data = body["outputs"][0]["data"]
print(data.get("keyword"), "| offset:", data.get("offset"), "| more:", data.get("continue_flag"))
categories = data.get("categories", [])
print(len(categories), "categories")
curl -X POST https://api.sandbase.ai/v1/api/wechat-search/v2/search \
  -H "Authorization: Bearer $SANDBASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"keyword": "人工智能"}'

Responses use a consistent envelope: an id, a status, the model name, and — on a completed run — an outputs array whose single item carries the payload under data. A failed or timeout run instead carries error and no outputs, so branch on status before reading outputs[0].data. For search, the payload carries the keyword, a results object, a categories list, and paging fields (offset, cursor, continue_flag, no_more). The block below is a trimmed real response from my search call (tested on 2026-09-27, UTC) — the values move over time, so treat the field names as observed and confirm them against a live response:

{
  "id": "677def62-bd58-48fb-bb31-ec694c49f80f",
  "status": "completed",
  "model": "wechat-search/v2/search",
  "outputs": [
    {
      "data": {
        "keyword": "人工智能",
        "offset": 18,
        "continue_flag": 1,
        "no_more": null,
        "categories": [],
        "results": {}
      }
    }
  ]
}

Response shapes differ by endpoint — inspect one real response and map the exact path per endpoint.

SandBase API reference for a WeChat Search 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
General searchwechat-search/v2/searchKeyword discovery across public surfaces
Video searchwechat-search/v2/search-videosKeyword video discovery

Paging is a per-endpoint request convention — the response returns an offset/cursor and a continue_flag/no_more signal; pass the offset or cursor back on the next request. Read each endpoint’s schema.

SandBase WeChat Search endpoint list showing the search and video-search endpoints with their paths The two WeChat Search endpoints on the v2 surface.

Chaining calls in an agent workflow

Because both endpoints share the same auth and the same response envelope, an agent can run a search and a video search along one convention. A common research pattern looks like this:

  1. Search the keyword. Call wechat-search/v2/search with a keyword to get grouped results, then page with the returned offset/cursor while continue_flag indicates more.
  2. Search videos. Call wechat-search/v2/search-videos with the same keyword for public videos, paging the same way.
  3. Store and diff. Persist each page keyed by result id, and diff across runs to detect what’s new.

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

Common use cases

WeChat Search API for topic research

Run wechat-search/v2/search with a keyword to survey public results grouped by category, then page with offset/continue_flag. Input: a keyword. Output: grouped results plus paging fields. Endpoint: search.

WeChat Search API for video discovery

Run wechat-search/v2/search-videos with a keyword to surface public videos around a topic. Input: a keyword. Output: video results plus paging fields. Endpoint: search-videos.

WeChat Search API for monitoring

Poll a keyword on a schedule and diff results across runs to track how a topic’s coverage changes. Input: a keyword. Output: successive result pages you compare over time. Endpoints: search, search-videos.

Why run this at the API layer

You could point a headless browser at WeChat Search and parse the app’s payloads, but that path is fragile: the app changes, tokens rotate, and you maintain a scraper instead of shipping features. Reading through one uniform API means your code depends on named JSON fields and a single response envelope rather than an app internal. Auth is one key, and because both endpoints return the same { id, status, model, outputs } shape, retries, logging, and error handling live in one helper you write once and reuse across both.

That uniformity is what makes the workflow composable for an agent. Swap one keyword for another, switch from search to search-videos, and the code path is identical. The practical payoff is that your time goes to what the results mean for your research, not to keeping a scraper alive against a moving target. When you need more than these two 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. Both endpoints take a keyword; paging uses offset/cursor with a continue_flag/no_more signal. 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 WeChat partnership. SandBase provides uniform access to public data; respect WeChat’s terms and applicable rules for your use case.

FAQ

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

What do the two endpoints take? Both search and search-videos take a keyword. The general search groups results into categories; the video search returns videos.

How does pagination work? The response returns an offset/cursor and a continue_flag/no_more signal; pass the offset or cursor back on the next request while continue_flag indicates more pages. Read each endpoint’s schema.

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

Create a SandBase API key, call search with a keyword, and inspect the returned schema before you page or move to video search. When you are ready: