Blog/Developer Tools/

Pipixia Public Data API | SandBase

Read public Pipixia hot boards, search, users, and posts with one REST API. No Pipixia login, no SDK — one SandBase key, built for agent workflows.

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

Pipixia (皮皮虾) is a Chinese humor and short-video community where trending jokes, “god comments,” and viral clips surface fast — a hot board, keyword search, and post streams that map onto trend research, meme monitoring, and content analytics. Getting at it programmatically usually means reverse-engineering the app, juggling tokens, and rebuilding a scraper each time the app changes.

The SandBase Pipixia public data API removes that setup tax. It reads Pipixia’s public hot boards, search results, users, and posts through plain REST endpoints — one SandBase API key, no Pipixia 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 calls 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 Pipixia’s official open platform. Use Pipixia’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 Pipixia endpoints.

Key takeaway

  • One API reads Pipixia’s public hot boards, keyword search, user profiles, and posts.
  • The Model API endpoints in this guide are called with POST /v1/api/pipixia/<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 (as a string) for a user.
  • 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 Pipixia API do you need?

Your needChooseWhy
Post, act as a member, or use account-authorized dataPipixia’s official channelsMember and account operations run through Pipixia directly.
Read public hot boards, search, users, or postsSandBase Pipixia 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 Pipixia API

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

  • Hot boards — the hot-search board list and a board’s detail.
  • Search — keyword search across posts and users.
  • Users — public user info, their post list, and follower/following lists.
  • Posts & topics — post detail, post statistics, and hashtag detail.

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

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

What Pipixia provides vs. what SandBase adds

Public data comes from Pipixia. SandBase does not own or operate Pipixia; 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 board → search a keyword → read a user” 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-search board list:

import os
import requests

resp = requests.post(
    "https://api.sandbase.ai/v1/api/pipixia/app/hot-search-board-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", "Pipixia request did not complete"))

# Pipixia wraps its result in an upstream { status_code, data, message } object;
# check status_code == 0, then read the business payload defensively.
payload = body["outputs"][0]["data"]
if payload.get("status_code") != 0:
    raise RuntimeError(payload.get("message", "upstream error"))
boards = payload.get("data", {}).get("boards", [])
print(len(boards), "boards")
curl -X POST https://api.sandbase.ai/v1/api/pipixia/app/hot-search-board-list \
  -H "Authorization: Bearer $SANDBASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{}'

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. Pipixia then wraps its own result in an upstream { status_code, data, message } object, so check status_code == 0 before reading the inner data. The block below is a trimmed real response from my hot-board 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": "b9982b0f-5c6b-4114-bc89-59a77fad8429",
  "status": "completed",
  "model": "pipixia/app/hot-search-board-list",
  "outputs": [
    {
      "data": {
        "status_code": 0,
        "message": "success",
        "data": {
          "boards": [
            { "board_items": [ { "item_info": "今日神评点赞", "today_digg_num": "4375" } ] }
          ]
        }
      }
    }
  ]
}

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

SandBase API reference for a Pipixia 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 boardpipixia/app/hot-search-board-listTrending-topic monitoring
Board detailpipixia/app/hot-search-board-detailRead a board’s items
Searchpipixia/app/searchKeyword content discovery
Userpipixia/app/user-infoPublic user signals by user_id
Post detailpipixia/app/post-detailRead a single post

Paging differs by endpoint — several endpoints return a has_more flag and accept a per-endpoint cursor or offset request parameter. Read each endpoint’s schema.

SandBase Pipixia endpoint list showing hot-board, search, user, and post endpoints with their paths A slice of the Pipixia endpoint list on the app 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 trend to a post without special-casing each surface. A common content-research pattern looks like this:

  1. Read the board. Call pipixia/app/hot-search-board-list to get trending boards, then pick the topics you care about.
  2. Search the keyword. Call pipixia/app/search with a keyword to pull matching posts and users, paging with the returned has_more flag.
  3. Read the user. Call pipixia/app/user-info with a user_id (a string) surfaced from search, then pipixia/app/user-post-list for their posts.

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

Common use cases

Pipixia hot-board API for trend monitoring

Poll pipixia/app/hot-search-board-list on a schedule to track trending boards — each board carries a list of items with engagement counters. Input: none. Output: boards with items. Endpoint: hot-search-board-list.

Pipixia search API for content discovery

Run pipixia/app/search with a keyword to survey posts and users around a topic, then page with has_more. Input: a keyword. Output: matching results. Endpoint: search.

Pipixia user API for creator research

Read a public user with pipixia/app/user-info by user_id, then pipixia/app/user-post-list for their posts. Input: a user_id (a string). Output: a user record and post list. Endpoints: user-info, user-post-list.

Why run this at the API layer

You could point a headless browser at Pipixia 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 the hot-board topic for any keyword, swap one user_id for another, and the code path is identical, down to the same status_code check. Add a fourth read — a post’s detail, 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 is a string; the upstream wraps results in { status_code, data, message } (check status_code == 0); paging is a per-endpoint has_more/cursor. 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 Pipixia partnership. SandBase provides uniform access to public data; respect Pipixia’s terms and applicable rules for your use case.

FAQ

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

What identifies a user or a search? A keyword drives search, and a user_id (passed as a string) identifies a user. You can surface a user_id from a search result.

Why is there a status_code inside data? Pipixia wraps its result in an upstream { status_code, data, message } object. Check status_code == 0 before reading the inner data, then read the business fields defensively.

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 board

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