Blog/Developer Tools/

Xigua Video Public Data API | SandBase

Read public Xigua Video search, users, videos, and comments with one REST API. No Xigua login, no SDK — one SandBase key, built for agent workflows.

By Sophie Lin
Dark cinematic render of Xigua Video search, user, and comment data flowing through one API conduit into an agent core

Xigua Video (西瓜视频) is ByteDance’s long-form video platform in China — video search, creator channels, and comment threads that map onto content research, creator analytics, 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 Xigua public data API removes that setup tax. It reads public Xigua video search, user profiles, videos, and comments through plain REST endpoints — one SandBase API key, no Xigua 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 Xigua’s official open platform. Use Xigua’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 Xigua endpoints.

Key takeaway

  • One API reads public Xigua video search, user profiles, video detail, and comments.
  • The Model API endpoints in this guide are called with POST /v1/api/xigua/<path> — pass only that endpoint’s params, no SDK, one SANDBASE_API_KEY.
  • Endpoints key off natural identifiers: a keyword for search and a user_id for a creator.
  • 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 Xigua API do you need?

Your needChooseWhy
Post, act as a member, or use account-authorized dataXigua’s official channelsMember and account operations run through Xigua directly.
Read public search, users, videos, or commentsSandBase Xigua 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 Xigua API

The catalog is organized on an app-v2 surface. Grouped by job:

  • Search — video search by keyword.
  • Users — public user info and a user’s post list.
  • Videos — a single video, video-v2, and its play URL.
  • Comments — a video’s comment list.

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

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

What Xigua provides vs. what SandBase adds

Public data comes from Xigua. SandBase does not own or operate Xigua; 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 “search a keyword → read a user → read a video’s comments” 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.

Search videos by keyword:

import os
import requests

resp = requests.post(
    "https://api.sandbase.ai/v1/api/xigua/app-v2/search-video",
    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", "Xigua request did not complete"))

# Xigua wraps its result with an upstream err_code; check it, then read
# the business payload defensively and confirm paths against a live response.
payload = body["outputs"][0]["data"]
if payload.get("err_code") != 0:
    raise RuntimeError("upstream error")
results = payload.get("results", [])
print(payload.get("count"), "results, has_more:", payload.get("has_more"))
curl -X POST https://api.sandbase.ai/v1/api/xigua/app-v2/search-video \
  -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. Xigua then reports its own status with an upstream err_code (0 means success), and search returns results alongside count, offset, and has_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": "82a63727-ed14-49b3-936f-0f94db26589c",
  "status": "completed",
  "model": "xigua/app-v2/search-video",
  "outputs": [
    {
      "data": {
        "err_code": 0,
        "count": 10,
        "offset": 10,
        "has_more": true,
        "results": [ { "id": "…", "data": {} } ]
      }
    }
  ]
}

Response shapes differ by endpoint, and each result item nests its own structured payload — inspect one real response and map the exact path per endpoint.

SandBase API reference for a Xigua 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
Searchxigua/app-v2/search-videoKeyword video discovery
User infoxigua/app-v2/user-infoPublic creator signals by user_id
User postsxigua/app-v2/user-post-listA creator’s video list
Video detailxigua/app-v2/one-video-v2Read a single video
Commentsxigua/app-v2/video-comment-listEngagement and sentiment inputs

Paging differs by endpoint — search returns an offset and a has_more flag; pass the offset back on the next request. Read each endpoint’s schema.

SandBase Xigua endpoint list showing search, user, video, and comment endpoints with their paths A slice of the Xigua endpoint list on the app-v2 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 search to a video’s comments without special-casing each surface. A common content-research pattern looks like this:

  1. Search the keyword. Call xigua/app-v2/search-video with a keyword, then page with the returned offset and has_more.
  2. Read the creator. Call xigua/app-v2/user-info with a user_id surfaced from search, then xigua/app-v2/user-post-list for their videos.
  3. Read the comments. Call xigua/app-v2/video-comment-list for a video’s engagement inputs.

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

Common use cases

Xigua search API for video discovery

Run xigua/app-v2/search-video with a keyword to survey videos around a topic, then page with offset/has_more. Input: a keyword. Output: a results list plus paging fields. Endpoint: search-video.

Xigua user API for creator research

Read a public creator with xigua/app-v2/user-info by user_id, then xigua/app-v2/user-post-list for their videos. Input: a user_id. Output: a user record and post list. Endpoints: user-info, user-post-list.

Xigua comments API for engagement signals

Read xigua/app-v2/video-comment-list for a video’s comment thread. Input: a video identifier. Output: a comment list. Endpoint: video-comment-list.

Why run this at the API layer

You could point a headless browser at Xigua 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 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 keyword for another, swap one user_id for the next, and the code path is identical, down to the same err_code check. Add a fourth read — a video’s play URL, say — and it slots in behind the same 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. A keyword drives search; a user_id identifies a creator; the upstream reports err_code (0 means success); each result item nests its own structured payload; paging uses offset/has_more. 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 Xigua partnership. SandBase provides uniform access to public data; respect Xigua’s terms and applicable rules for your use case.

FAQ

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

What identifies a search or a creator? A keyword drives search, and a user_id identifies a creator. You can surface a user_id from a search result.

Why is there an err_code in the payload? Xigua reports its own status with an upstream err_code (0 means success). Check it before reading the business fields, and read each result item’s nested payload defensively.

How does pagination work? Search returns an offset and a has_more flag; pass the offset back on the next request to fetch the next page. 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.

Create a SandBase API key, call search-video, and inspect the returned schema before you expand to users, videos, or comments. When you are ready: