Blog/Developer Tools/

Xiaohongshu (RED) Public Data API | SandBase

Search public Xiaohongshu (RED) notes, products, users, and images with one REST API. No RED login, no SDK — one SandBase key, built for agents.

By Sophie Lin
Dark cinematic render of Xiaohongshu note, product, and user search data flowing through one API conduit into an agent core

Xiaohongshu (RED) is China’s lifestyle and shopping discovery engine — product reviews, beauty and travel notes, creator recommendations, and a search box that shapes what millions buy. That maps directly onto consumer research, product monitoring, and influencer discovery. Getting at it programmatically usually means reverse-engineering the app, managing tokens, and rebuilding a scraper whenever the app changes.

The SandBase Xiaohongshu public data API removes that setup tax. It searches public RED notes, products, users, and images through plain REST endpoints — one SandBase API key, no RED login and no SDK. The field names and JSON shapes below are illustrative examples to show the general structure; confirm the exact parameters and response fields against each endpoint’s live API reference and a real response.

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

Key takeaway

  • One API searches public RED notes, products, users, and images, and reads product detail.
  • The Model API endpoints in this guide are called with POST /v1/api/xiaohongshu/<path> — pass only that endpoint’s params, no SDK, one SANDBASE_API_KEY.
  • Search-notes and search-products/search-users take a keyword; product-detail, product-reviews, and product-recommendations take a sku_id. Paging is a per-endpoint request parameter — most search endpoints take a page (1-based); check each endpoint’s reference.
  • 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 Xiaohongshu API do you need?

Your needChooseWhy
Post, act as a member, or use account-authorized dataRED’s official channelsMember and account operations run through RED directly.
Search public notes, products, users, or read product detailSandBase Xiaohongshu 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 Xiaohongshu API

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

  • Search — notes, products, users, images, and groups by keyword.
  • Products — product detail, reviews, and recommendations by sku_id.
  • Notes & topics — note comments and topic feeds.
  • Creators — creator inspiration and hot-inspiration feeds.

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

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

What Xiaohongshu provides vs. what SandBase adds

Public data comes from Xiaohongshu. SandBase does not own or operate RED; 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 → open a product → pull its reviews” 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 public notes by keyword:

import os
import requests

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

payload = body["outputs"][0]["data"]
# Field paths are illustrative — confirm the exact keys against a live response.
inner = payload.get("data") or {}
items = inner.get("items", [])
print(len(items), "notes on this page")
# To page, pass this endpoint's paging request params on the next call
# (search-notes: page starting at 1, plus search_id / search_session_id).
curl -X POST https://api.sandbase.ai/v1/api/xiaohongshu/app-v2/search-notes \
  -H "Authorization: Bearer $SANDBASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"keyword": "护肤", "page": 1}'

Every response uses the same SandBase envelope: an id, a status, the model name, and an outputs array whose single item carries the payload under data. Only this envelope is guaranteed; the business fields nested inside data are set by the upstream surface, so the endpoint reference and a real response are the source of truth. 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 only — the nested field names and values are examples, not a guaranteed schema, so confirm them against a live response, since payloads vary and change over time:

{
  "id": "9ca6d841-5dbd-42f8-9fea-a02bfe56b07e",
  "status": "completed",
  "model": "xiaohongshu/app-v2/search-notes",
  "outputs": [
    {
      "data": {
        "…": "illustrative response shape — confirm the nested fields against a live response"
      }
    }
  ]
}

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 Xiaohongshu 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
Note searchxiaohongshu/app-v2/search-notesKeyword content discovery
Product searchxiaohongshu/app-v2/search-productsShopping and catalog research
User searchxiaohongshu/app-v2/search-usersCreator discovery
Product detailxiaohongshu/app-v2/product-detailRead a product by sku_id
Product reviewsxiaohongshu/app-v2/product-reviewsReview and sentiment inputs

Paging is a per-endpoint request parameter, not a value you round-trip: search-notes takes page (1-based) plus search_id and search_session_id; search-products and search-users take page (1-based) plus search_id; product-reviews takes page (0-based); product-recommendations takes cursor_score. Read each endpoint’s schema for its exact paging params.

SandBase Xiaohongshu endpoint list showing note, product, user, and search endpoints with their paths A slice of the Xiaohongshu 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 keyword to a product’s reviews without special-casing each surface. A common consumer-research pattern looks like this:

  1. Search the keyword. Call xiaohongshu/app-v2/search-notes or search-products with a keyword, then page by incrementing that endpoint’s page request parameter (search-notes starts at 1).
  2. Open the product. Call xiaohongshu/app-v2/product-detail with a sku_id for its structured detail.
  3. Read the reviews. Call xiaohongshu/app-v2/product-reviews with the same sku_id for review and sentiment inputs.

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

Xiaohongshu note search API for content discovery

Run xiaohongshu/app-v2/search-notes with a keyword to survey notes around a topic, then page by incrementing the page request parameter (starting at 1). Input: a keyword. Output: matching notes. Endpoint: search-notes.

Xiaohongshu product API for shopping research

Search with xiaohongshu/app-v2/search-products, then read a product with product-detail by sku_id. Input: a keyword, then a sku_id. Output: product results and detail. Endpoints: search-products, product-detail. For a full workflow, see how to do Xiaohongshu product research.

Xiaohongshu user search API for creator discovery

Run xiaohongshu/app-v2/search-users with a keyword to find creators around a niche. Input: a keyword. Output: matching users. Endpoint: search-users.

Why run this at the API layer

You could point a headless browser at Xiaohongshu 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 sku_id for another, and the code path is identical. Add a fourth read — a product’s recommendations, 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. search-products takes a keyword; product-detail, product-reviews, and product-recommendations take a sku_id. Only the SandBase envelope is guaranteed — the nested business fields are examples, not a guaranteed schema. Paging is a per-endpoint request parameter (page, search_id, cursor_score, and similar), not a value you round-trip. 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 Xiaohongshu partnership. SandBase provides uniform access to public data; respect RED’s terms and applicable rules for your use case.

FAQ

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

What identifies a search or a product? search-notes, search-products, and search-users take a keyword; product-detail, product-reviews, and product-recommendations take a sku_id.

How does pagination work? Paging is a per-endpoint request parameter, not a value returned and passed back. Most search endpoints take a page (1-based; product-reviews starts at 0), some also take search_id/search_session_id, and product-recommendations takes a cursor_score. 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-notes with a keyword, and inspect the returned schema before you expand to products, users, or reviews. When you are ready: