RedNote Creator Monitoring avatar

RedNote Creator Monitoring

Pricing

from $18.00 / 1,000 creator profiles

Go to Apify Store
RedNote Creator Monitoring

RedNote Creator Monitoring

RedNote Creator Monitoring turns Xiaohongshu (RedNote) into a scheduled, schema-versioned data feed for agencies and analytics teams tracking creator performance, not a hobby scraper.

Pricing

from $18.00 / 1,000 creator profiles

Rating

0.0

(0)

Developer

Protocol

Protocol

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

10 days ago

Last modified

Share

The unofficial RedNote / Xiaohongshu data API — extract creator profiles, the discovery feed, and post detail, and get computed within-sample intelligence signals (engagement quality, save-ratio, creator momentum) on every enriched row, billed only on success. Built for recurring creator monitoring: schedule a roster, dedupe seen notes, pay only for what's new.

Store name: RedNote API (for discoverability). This is the RedNote Creator Monitoring product — unofficial, not affiliated with or endorsed by RedNote/Xiaohongshu, and not an official API.

Contents

Quick start

Replace <your-apify-username>~rednote-api below with the Actor ID shown on the Apify Store page (the Actor is not yet pushed — this is the placeholder ID).

Mode 2 — creator profile (the recommended path; lead with this one):

{
"mode": "creator",
"creatorUrls": [
"https://www.xiaohongshu.com/user/profile/57206aec84edcd55224690c9"
],
"dedupe": true,
"maxItems": 100
}

Mode 1 — search / discovery:

{
"mode": "search",
"query": "",
"maxItems": 100
}

Mode 3 — post / note detail (Bounded Beta, cookie-only):

{
"mode": "post",
"postUrl": "https://www.xiaohongshu.com/explore/6a278466000000001603fcad",
"sessionCookie": "your-rednote-session-cookie-string"
}

JavaScript (apify-client):

import { ApifyClient } from 'apify-client';
const client = new ApifyClient({ token: process.env.APIFY_TOKEN });
const run = await client.actor('<your-apify-username>~rednote-api').call({
mode: 'creator',
creatorUrls: ['https://www.xiaohongshu.com/user/profile/57206aec84edcd55224690c9'],
dedupe: true,
maxItems: 100,
});
const { items } = await client.dataset(run.defaultDatasetId).listItems();
console.log(items);

Python:

from apify_client import ApifyClient
client = ApifyClient(token=os.environ['APIFY_TOKEN'])
run = client.actor('<your-apify-username>~rednote-api').call(run_input={
'mode': 'creator',
'creatorUrls': ['https://www.xiaohongshu.com/user/profile/57206aec84edcd55224690c9'],
'dedupe': True,
'maxItems': 100,
})
items = client.dataset(run['defaultDatasetId']).list_items().items
print(items)

curl:

curl -X POST "https://api.apify.com/v2/acts/<your-apify-username>~rednote-api/runs?token=$APIFY_TOKEN" \
-H "Content-Type: application/json" \
-d '{"mode":"creator","creatorUrls":["https://www.xiaohongshu.com/user/profile/57206aec84edcd55224690c9"],"dedupe":true,"maxItems":100}'

Why this actor

  • Within-sample intelligence signals on every enriched row — a composite engagement-quality score plus the individual engagement, save, and comment ratios and normalized audience size, creator momentum, and a content fingerprint. saveRatio (collects/likes) is RedNote's distinctive save signal that no incumbent in this niche surfaces.
  • Recurring-monitoring dedupe — pay only for new notes — schedule a roster of creators with dedupe: true; each run re-checks every profile but emits and bills only the new note cards since last time.
  • Schema-validated, versioned output — every row validates against output.v1 (schemaVersion: "2.0.0") at the single write point, with the per-surface data shape enforced at the charge gate via runtime AJV. Invalid rows become structured error rows and are not charged.
  • PIPL-compliant by construction — RedNote is China-hosted, so China's Personal Information Protection Law applies (not only GDPR). ipLocation and other PII are stripped by src/sanitize.ts at the write point, before any row is emitted.
  • Honest, bounded keyword-search depth — we state openly that keyword-search depth is bounded (thin SSR — R-003); a deeper signed-API spike is roadmap, not V1. We tell you the ceiling rather than imply depth we cannot deliver.
  • No-charge-on-failure PPE — Pay-Per-Event; you are charged only on a successful enriched result. Failed, partial, and auth_required results charge nothing.

Built for

Primary ICP is agencies and social-intelligence analyst teams running recurring RedNote creator-monitoring pipelines, and developers integrating RedNote-derived data into broader analytics systems. The buyer need is structured, repeatable, diagnostics-rich access — not hobby tooling.

Enterprise & reliability

The Actor is built to production-grade data-contract discipline. These are the guarantees that hold today — stated honestly, with no SLA claim beyond best-effort support.

  • Contract-stable, versioned output. Every row validates against output.v1 (schemaVersion: "2.0.0") at the single write point (src/normalizer.ts — the sole writer), with the per-surface data shape enforced by runtime AJV at the charge gate. Additive fields (like the intelligence namespace) appear within v1; any breaking row-shape change ships as a new output.v2 schema with a changelog migration notice — v1 consumers are never broken silently.
  • Pay-Per-Event with no-charge-on-failure. Actor.charge() fires only on a successful enriched result, only at the normalizer seam. Failed, partial, auth_required, not_found, blocked, and error rows are emitted as structured rows and cost nothing — cost is predictable, never a surprise.
  • Resilience ceilings, enforced in code. ≤10,000 items/run · ≤500 pages/session · browser fallback ≤20% (structural at the adapter seam) · abort at 10% parse failures · ≤3 retries with backoff + jitter · 50 MB payload cap. The guardrails live in src/limits.ts, not just in docs.
  • PIPL-aware by construction. RedNote is China-hosted, so China's Personal Information Protection Law applies (not only GDPR). ipLocation and other PII are stripped by src/sanitize.ts at the write point, before any row is emitted. Secret inputs (sessionCookie, llmApiKey) are encrypted at rest, never logged, never persisted, never written to output.
  • Deterministic, auditable intelligence. Every Tier 1 intelligence sub-field is tagged method: "deterministic" / scope: "within-sample" — reproducible from the returned rows, no opaque model in the GA path. (Tier 3 LLM enrichment is opt-in, OFF by default, BYOK — never on by accident.)
  • Diagnostics-rich runs. Every run emits a RUN_SUMMARY key-value record with per-status / per-surface counters, HTTP vs browser counts, retry / parse-failure / session-rotation counters, fallback ratio, item throughput, and outcome — so you can monitor pipeline health and feed downstream alerting.
  • Honest scope. We state the ceiling openly rather than imply depth we cannot deliver (bounded keyword-search depth, R-003). Trend tracking, rising-creator detection, and historical backfill are deferred tiers — roadmap items, not commitments, and never claimed in this README.

No SLA beyond best-effort support within 2 business days. Upstream access is unofficial and may drift. For volume or custom needs, reach out via the Apify Console actor contact.

What it does

RedNote Creator Monitoring extracts publicly accessible, server-rendered RedNote / Xiaohongshu data across three surfaces, normalizes it, enriches it with deterministic within-sample intelligence, validates every row against a versioned schema, and bills you only for successful results.

  • Extracts creator profiles (GA), the discovery / keyword search feed (GA), and post / note detail (Bounded Beta, cookie-only).
  • Normalizes every Chinese-number metric (4.4万44000, with the raw string and an approx flag preserved) — no /亿 math in your spreadsheet.
  • Enriches each enriched ok row with a Tier 1 deterministic intelligence namespace — a composite engagement-quality score plus its individual engagement, save, and comment ratios and normalized audience size, creator momentum, and a content fingerprint — computed from the rows returned in this run only.
  • Validates every row against output.v1 (schemaVersion: "2.0.0") at the single write point, with the per-surface data shape enforced at the charge gate (runtime AJV). Invalid rows become structured error rows and are not charged.
  • Bills per event (Pay-Per-Event): you pay only on a successful enriched result — failed, partial, and auth_required results cost nothing.

Three extraction surfaces. The matrix below is honest about what works today, not aspirational — documented limits, never surprises.

ModeSurfaceAnonymousCookieStatus
2Creator profile✅ GAPrimary. Basic info + interactions + first-tab note cards (preview-only: title/cover/likes). Carries the Tier 1 intelligence namespace.
1Search / discovery✅ GA /explore feed (empty query)Keyword query returns thin SSR — no note cards in V1 (R-003 / D-007). Feed cards do not carry the intelligence namespace.
3Post / note detail❌ Not supported✅ Bounded BetaExperimental, cookie-only, account-ban risk. Carries a partial Tier 1 intelligence namespace (fingerprint + null-valued EQS).
  • Mode 2 — Creator profile (GA). The recommended path. /user/profile/<id> — nickname, redId, bio, follower/fan/interaction counts (with -normalized integers), profile tags, and the first-tab note cards. These cards are preview-only (title, cover, liked count, user) and do not carry noteId, xsecToken, or noteUrl — for deep-linkable note references use Mode 1 discovery cards. Anonymous, batchable (creatorUrls), and the least exposed to RedNote's login/signing arms race — which is why it leads. On a valid profile row the Actor attaches the Tier 1 intelligence namespace (see Output) and charges intelligence_basic exactly once.
  • Mode 1 — Search / discovery (GA). Extracts the /explore discovery feed (~25–31 note cards per page, anonymous) — only when query is empty. A filled query hits /search_result, whose note cards load via RedNote's signed API; anonymous HTTP returns only a thin server-rendered state with no note cards (zero ok rows) — keyword card-extraction is the deferred signed-API spike, not V1 (R-003 / D-007). Leave query empty for cards. Feed rows aggregate cards from many creators and do not carry per-creator intelligence — within-sample intelligence is a per-creator contract, not a per-feed aggregate.
  • Mode 3 — Post / note detail (Bounded Beta — experimental). /explore/<noteId> — full note detail, metrics, images, tags, hashtags. Cookie-only: requires your RedNote sessionCookie. Batch postUrls entries each need their own xsec_token; the single postUrl path is cookie-driven and does not require one. Carries account-ban risk (see below) and is not the recommended path — it's an experimental upsell, not a GA promise. Without a cookie it returns auth_required (a graceful structured result, not a run failure). Post rows attach a partial intelligence namespace: contentFingerprint plus an engagementQualityScore whose value is null (a single post exposes no follower count for the divide-by-zero guard), and the individual engagementRate/saveRatio/commentRatio/i18nCount ratios are null for the same reason; creatorMomentum is null (momentum needs ≥2 posts in the sample).

The bounded keyword-search depth (R-003) is a trust differentiator, not a softening of the honesty: we state the ceiling openly rather than imply a depth we cannot deliver.

How it works

  1. Anonymous-first fetch. The Actor fetches public, server-rendered RedNote pages over HTTP using impit (TLS + HTTP/2 browser fingerprinting), with a bounded Playwright browser fallback (≤20% of requests) only when a client-side challenge blocks the HTTP path. Mode 3 (post detail) is the one cookie-aware path.
  2. Resilient fetch. Retry with exponential backoff + jitter (max 3 attempts), and the ≤20% browser-fallback ceiling enforced structurally at the adapter seam. Graceful degradation, never a silent break.
  3. Normalize → validate → enrich. Each result is normalized to the output.v1 shape, validated at the single write point (runtime AJV enforces the per-surface data oneOf), and — on ok — enriched with the Tier 1 intelligence namespace.
  4. Pay-Per-Event charge. Actor.charge() fires only on a successful enriched result, only at the normalizer seam. Failed, partial, and auth_required results charge nothing.

Input

Full contract: .actor/input_schema.json. mode is required; everything else is conditional on the mode.

InputTypeDefaultNotes
modesearch | creator | postsearchRequired. creator is the recommended path.
creatorUrlstringRequired for mode=creator (single profile).
creatorUrlsstring[][]Batch alternative to creatorUrl — multiple profiles per run. Recommended for monitoring.
querystringmode=search. Empty = discovery feed (/explore) — returns ~25–31 note cards. Filled = keyword search — returns thin SSR, no note cards in V1 (signed-API spike deferred, R-003).
postUrlstringRequired for mode=post (single post, Bounded Beta, cookie-only). An xsec_token is not required on the single-post path — auth comes from sessionCookie.
postUrlsstring[][]Batch alternative to postUrl. Each entry must include its own xsec_token — tokenless entries are rejected as malformed (canon 03:16).
maxItemsinteger1001–10,000. A hard ceiling, not a target — there is no pagination in V1, so discovery returns ~25–31 rows/run regardless. See Limits.
sortrelevance | recent | popularrelevanceKeyword-search ordering hint. Not yet wired into the outgoing request (tracked as D-3) — accepted for forward compatibility only.
regionstringBounded targeting hint, best-effort only. Not yet wired (D-3).
languagestringBounded language hint. Not yet wired (D-3).
sessionCookiestring (secret)Mode 3 only. Encrypted at rest; never logged, never persisted, never written to output. Using it may risk your RedNote account.
proxyConfigurationobjectApify Proxy or custom proxy.
includeDiagnosticsbooleanfalseOpt-in verbose run diagnostics in the run summary.
dedupebooleanfalseSkip already-seen notes in subsequent runs — keyed by noteId for discovery cards and by a synthetic key (creator userId + title + cover) for creator-tab cards, which don't carry a noteId. Persistent seen-set in the KV store. Recommended for scheduled/recurring runs.
outputTransformobjectOptional (D-031). Reshape each row's datafields (dot-paths to keep), flatten (collapse nested objects to dot keys), classify (group the run's rows by dot-paths into per-class counts in the run summary; does not alter rows). Applied per-row AFTER billing fires on the original; the row re-validates against output.v1 and reverts on failure. Emits rows on the additive surface: "transformed" branch. GA, not Tier 3, not behind a flag.

Proxy / CN-egress note. RedNote is China-hosted. Residential CN-egress proxies via proxyConfiguration improve Mode 1/2 reliability; for Mode 3 use a proxy matching the cookie's origin account. sort, region, and language are accepted for forward compatibility but are not yet wired into the outgoing request (tracked as D-3).

Output

Every dataset row is validated against schemas/output.v1.schema.json at the single write point (src/normalizer.ts). Each row carries a surface, a requestStatus, a confidence tier, a fetchedAt timestamp, a data payload (null for non-ok statuses), and — when Tier 1 enrichment succeeded — an additive intelligence namespace. A row without the intelligence namespace still validates: the namespace is additive, not required.

Top-level row fields:

FieldTypeNotes
schemaVersion"2.0.0"The contract version.
surfacesearch | creator | post | insight | transformedWhich mode produced the row. insight is an internal prototype, not emitted in GA runs. transformed is emitted via the outputTransform input.
requestStatusok | partial | auth_required | not_found | blocked | errorAn auth_required row (Mode 3 with no cookie) is a normal structured result with data: null, not a run failure.
urlstringThe source URL.
dataobject | nullNormalized payload; null for non-ok statuses.
confidencestable | best_effort | experimentalSee tiers below.
fetchedAtstring (ISO 8601)When the row was written.
intelligenceobject (optional)Tier 1 deterministic intelligence — present only on ok rows whose enrichment succeeded. Additive; omitted on search rows and on any row where enrichment degraded.

Confidence tiers:

  • stable — name, type, and nullability protected across minor releases.
  • best_effort — present and documented, but values may be absent or approximate.
  • experimental — may change or disappear with limited notice.

intelligence namespace (Tier 1 deterministic, within-sample — additive, schema-validated, billed as intelligence_basic once per enriched row). The three composite sub-fields are required when the namespace is present; the four individual-ratio sub-fields (D-030) are additive optional and always populated on an enriched row (value: null on the post surface, which exposes no follower count):

Sub-fieldTypeNotes
engagementQualityScoreobject | nullComposite 0–1 = mean of engagementRate + saveRatio + commentRatio. null on divide-by-zero (zero followers or zero likes — never NaN). For a single post (Mode 3) the value is null because a post exposes no follower count.
engagementRateobject | nullD-030. (likes + collects + comments) / followers, clamped to [0,1] (engagement can exceed the audience). The individual signal behind the composite. null on the same divide-by-zero guard.
saveRatioobject | nullD-030. collects / likes in [0,1] — RedNote's distinctive save signal; no incumbent surfaces it. null when likes are zero; 0 when the surface carries no collects (creator-tab cards are preview-only).
commentRatioobject | nullD-030. comments / likes in [0,1]. null when likes are zero; 0 when the surface carries no comments (creator-tab cards).
i18nCountobject | nullD-030. The i18n-normalized follower count — the denominator of engagementRate, surfacing the /亿 parse as a first-class signal. null on the post surface (no follower count).
creatorMomentumobject | nullWithin-sample rolling-average engagement, post cadence (days between consecutive posts), and most-recent-vs-median delta. null when fewer than 2 posts are in the returned sample.
contentFingerprintobjectHashtags + topics + noteType + language (zh/en/null) + hasVideo + imageCount. Extracted from whatever the surface's data carries.

Every sub-field carries the frozen tags method: "deterministic" and scope: "within-sample". "Within-sample" means the signals are computed from the rows returned in this run only — they are not longitudinal trends and not cross-sample comparisons. We return signals, not just rows; we do not claim trends, rising-creator detection, or historical access (those tiers are deferred — see Known limitations).

Sample dataset rows

One real output.v1 row for the primary surface (values drawn from the project's sanitized fixtures). Metrics show the raw string, the parsed integer, and an approx flag side by side.

Mode 2 — creator profile (surface: "creator", billed creator_profile plus intelligence_basic; note cards bill creator_note and do not carry the intelligence namespace):

{
"schemaVersion": "2.0.0",
"surface": "creator",
"requestStatus": "ok",
"url": "https://www.xiaohongshu.com/user/profile/57206aec84edcd55224690c9",
"confidence": "best_effort",
"fetchedAt": "2026-06-30T09:12:04.000Z",
"data": {
"basicInfo": {
"redId": "622954348",
"nickname": "和女儿跳舞的波斯猫妞",
"desc": "女儿已窈窕 妈妈还未老 时光正正好…",
"gender": 1,
"ipLocation": "",
"images": "https://sns-avatar-qc.xhscdn.com/avatar/61eb8adda1b9bac71f61f7a5.jpg?imageView2/2/w/360/format/webp",
"imageb": "https://sns-avatar-qc.xhscdn.com/avatar/61eb8adda1b9bac71f61f7a5.jpg?imageView2/2/w/540/format/webp"
},
"interactions": [
{ "type": "follows", "name": "关注", "count": "10+", "countParsed": 10, "countApprox": true, "i18nCount": "10+" },
{ "type": "fans", "name": "粉丝", "count": "1万+", "countParsed": 10000, "countApprox": true, "i18nCount": "10K+" },
{ "type": "interaction", "name": "获赞与收藏", "count": "1万+", "countParsed": 10000, "countApprox": true, "i18nCount": "10K+" }
],
"tags": [
{ "name": "", "tagType": "info" },
{ "name": "舞蹈博主", "tagType": "profession" }
],
"notes": [
{
"displayTitle": "都说妈妈看着年轻,那是因为你们没见过爸爸",
"type": "video",
"user": {
"userId": "57206aec84edcd55224690c9",
"nickname": "和女儿跳舞的波斯猫妞",
"avatar": "https://sns-avatar-qc.xhscdn.com/avatar/61eb8adda1b9bac71f61f7a5.jpg"
},
"cover": { "url": "http://sns-webpic-qc.xhscdn.com/…!nc_n_nwebp_mw_1", "width": 596, "height": 796 },
"likedCount": "2.3万",
"likedCountParsed": 23000,
"likedCountApprox": true
}
]
},
"intelligence": {
"engagementQualityScore": { "value": 0.33, "method": "deterministic", "scope": "within-sample" },
"engagementRate": { "value": 1.0, "method": "deterministic", "scope": "within-sample" },
"saveRatio": { "value": 0, "method": "deterministic", "scope": "within-sample" },
"commentRatio": { "value": 0, "method": "deterministic", "scope": "within-sample" },
"i18nCount": { "value": 10000, "method": "deterministic", "scope": "within-sample" },
"creatorMomentum": {
"rollingAvgEngagement": 3055,
"postCadenceDays": null,
"recentVsMedianDelta": null,
"method": "deterministic",
"scope": "within-sample"
},
"contentFingerprint": {
"hashtags": [],
"topics": ["舞蹈博主"],
"noteType": "video",
"language": "zh",
"hasVideo": true,
"imageCount": 0,
"method": "deterministic",
"scope": "within-sample"
}
}
}

Creator-tab note cards are preview-only (title, cover, liked count, user). Probe-verified 2026-07-02: noteId, xsecToken, and noteUrl are all absent on this surface — only displayTitle, type, user{userId,nickname,avatar}, cover{url,width,height}, and likedCount are returned. publishedAt is also empty, so creatorMomentum.postCadenceDays is null for a profile whose sample has unparseable timestamps. The individual ratios in the sample above reflect this: engagementRate is clamped to 1.0 (23,000 likes against 10,000 followers), while saveRatio and commentRatio are 0 because creator-tab cards carry no collects or comments.

The notes[] array is shown truncated to 1 of the 31 notes the profile actually returned in this run — the pipeline's explodeEntity unwraps each note to the FLAT noteCard shape (the parser wrapper {noteId, xsecToken, noteUrl, noteCard, publishedAt} is dropped before emit; an empty publishedAt is not merged in). creatorMomentum.rollingAvgEngagement is the aggregate mean across all 31 notes (~94,706 total likes ÷ 31 ≈ 3055), NOT the single displayed note's 23,000 likes. recentVsMedianDelta is null (not 0) because every publishedAt is empty, so the dated[] array used by the most-recent-vs-median computation is empty. For deep-linkable note references (noteId / xsecToken / noteUrl), use Mode 1 discovery cards. Mode 3 (post detail) is entered via a Mode-1 noteId + xsecToken, or via a user-supplied postUrl (the single-post path is cookie-driven and does not require an xsec_token; batch postUrls entries each do) — not via a creator-tab card.

Search and post sample rows: see fixtures/ and schemas/output.v1.schema.json.

ipLocation is stripped from output under PIPL (canon 08 — it is on the PII deny list and sanitize() removes it before any row is emitted). The field above is illustrative of the upstream payload only; it never reaches the dataset.

Pricing

from $18 / 1,000 enriched creator-profile rows.

Worked-example cost for a daily monitoring run: daily monitoring of 20 creators returning 12 new notes ≈ 20× creator_profile ($0.36) + 12× creator_note ($0.072) + 1× scheduled_run ($0.02) = ~$0.45/run, with intelligence_basic at the Apify platform-minimum $0.01/1,000 on the enriched rows (≈$0.0003 here — negligible, so the total stays ~$0.45). At daily cadence ≈ $13.50/month.

Pay-Per-Event. You are charged only on a successful enriched result; failed, partial, and auth_required results cost nothing. Five priced events plus Tier 1 intelligence, which is bundled at no surcharge (Apify platform minimum $0.01/1,000):

EventPrice (USD)When it fires
discovery_result$0.010One enriched search/discovery result returned (Mode 1).
creator_profile$0.018One enriched creator profile returned (Mode 2, profile row).
creator_note$0.006One enriched creator note card returned (Mode 2, notes-tab row, preview-only).
post_detail$0.025One enriched post-detail record returned (Mode 3, Bounded Beta).
scheduled_run$0.02 (flat, per scheduled run)A completed scheduled analytics run — additive, on top of the per-result charges.
intelligence_basic$0.01 / 1,000 (platform minimum — effectively no surcharge)Tier 1 deterministic intelligence (EQS + creator momentum + content fingerprint) attached to a billable row. Fires exactly once per enriched ok row, only when enrichment succeeded. Failed/partial/error rows charge nothing. Apify rejects a literal $0, so the price is the platform floor — it bills as an auditable usage signal, not a real cost.

Launch prices for the first five events were set 2026-07-04 (matching src/billing.ts), priced at the incumbent comparable Actor — not above; the honesty, governance, and data-quality is the premium, not the sticker.

Tier 1 intelligence is bundled at no surcharge. intelligence_basic is priced at the Apify platform minimum ($0.01/1,000; Apify rejects a literal $0): it is deterministic arithmetic over data you already paid for via the surface event, so there is no marginal cost to pass on — effectively free. The event still fires on every enriched row, so it stays visible in your charge log as an auditable usage signal.

Scheduled-run charge is additive. Scheduled runs incur a per-run scheduled_run charge in addition to the per-result charges above. A scheduled monitoring run that returns 12 new creator notes bills 12 creator_note events (plus one creator_profile per profile row, plus any intelligence_basic on enriched rows) plus one scheduled_run event. Any pricing change ships with at least 14 days' notice — never a surprise.

Recurring monitoring

Track a roster of creators and only pay for new notes (this is the workflow behind the worked-example cost above):

  1. Configure a run with mode: "creator" and your roster in creatorUrls (batch multiple profiles per run).
  2. Set dedupe: true. The Actor persists a seen-set of dedupe keys in the key-value store and skips anything it has already returned — keyed by noteId for discovery cards and by a synthetic key (creator userId + title + cover) for creator-tab cards, which don't carry a noteId.
  3. Save it as a Task and put it on a schedule in the Apify Console (e.g. daily or weekly). Each scheduled run re-checks every profile but emits — and bills — only the new note cards since last time. The profile row itself (basic info + intelligence) is re-emitted each run so you can track within-sample momentum on the latest sample.
  4. Read the deltas. Each run's dataset is the new-notes report; the RUN_SUMMARY key-value record carries run-level counts and outcome.

Use cases

  • Recurring creator & competitor monitoring. Schedule mode: "creator" over a roster of profiles with dedupe: true and pay only for new note cards each run — the headline workflow (see Recurring monitoring).
  • New-content alerting. The dedupe seen-set turns each scheduled run into a "what's new since last time" report.
  • Within-sample engagement quality. Score a creator's returned notes by engagement quality (0–1) and momentum to prioritize outreach within the sample this run returned.
  • Content fingerprinting & tagging. Hashtags, topics, note type, language, and media shape on every enriched row — for filtering, dedupe, or feed classification.
  • Discovery feed browsing. Pull the anonymous /explore feed (~25–31 cards per page) for content discovery and deep-linkable note references.
  • Post / note detail lookup. Resolve a single note's full detail, metrics, and tags (Mode 3, cookie-only, Bounded Beta).

Integrations

Standard Apify integrations work out of the box — the Actor is callable via the Apify API (JavaScript, Python, CLI; see Quick start) and connects to the usual automation targets:

  • Make / Zapier / n8n — trigger a run on a schedule or event, then route the dataset to your destinations (Sheets, Airtable, Slack, Notion, a webhook).
  • Slack / email / webhook — use the RUN_SUMMARY key-value record (per-status counts, outcome, item throughput) to drive "new notes since last run" alerts.
  • Apify Scheduler — save a mode: "creator" + dedupe: true config as a Task and schedule it daily/weekly for recurring monitoring (see Recurring monitoring).
  • Apify API / CLIapify call, apify-client (JS), apify-client (Python) — programmatic access for your own pipelines.

Output is plain validated JSON in the Apify dataset — pull it with any tool that reads the Apify dataset API.

Honest scope & limits

No pagination (V1). The Actor fetches one page per URL. Discovery mode therefore returns roughly one feed page (~25–31 cards) per run no matter how high maxItems is set; scale comes from supplying more URLs (creator batches), not from deeper paging. See Limits.

Not supported (roadmap, not commitments): longitudinal trend tracking, rising-creator detection, historical backfill beyond bounded windows, demographic insights, brand-sentiment analysis, creator-fit scoring, cross-platform comparison, and any MCP server integration. These are deferred tiers — see Known limitations.

  • Anonymous access depends on RedNote's current server-side rendering. The GA (anonymous) modes work because RedNote server-renders public profile and discovery state today. If RedNote tightens login-gating, GA modes may degrade to auth_required with notice (a structured result, not a silent break) — we monitor SSR completeness as an operational signal and will announce any degradation in the changelog.
  • PIPL applies. RedNote / Xiaohongshu is China-hosted, so China's Personal Information Protection Law is the applicable privacy regime (not only GDPR). ipLocation and other PII are stripped by src/sanitize.ts before any row is emitted.
  • The dataset may contain personal information from public profiles. You are responsible for lawful use and any redistribution of that data.
  • Mode 3 carries account-ban risk. Using your own RedNote session for automated extraction may put your RedNote account at risk of restriction or ban. Use a throwaway or expendable account, and use this mode at your own risk. The Actor does not scrape or generate cookies — you bring your own from an authenticated browser session (DevTools → Application → Cookies → xiaohongshu.com, copy name=value pairs separated by ; ).
  • No SLA. Upstream access is unofficial and may drift; availability and field coverage are best-effort. Support is best-effort within 2 business days.

Limits

Per-run ceilings (enforced in src/limits.ts):

No pagination in V1 — one page fetched per URL. These are ceilings, not reachable targets. The Actor fetches a single page per URL and does not paginate, so the rows a run can actually return is driven by how many URLs you supply, not by maxItems:

ModeRealistic rows per run
Search / discovery~25–31 — one /explore page, regardless of maxItems
Creatorfirst-tab note cards per profile × the number of creatorUrls
Post1 row per URL (≤500 URLs)

Only creator batches approach the 10,000 ceiling. Deeper depth needs the signed-API spike tracked as R-003 (roadmap, not V1).

CeilingValue
Max items per run10,000 (ceiling — see the pagination note above)
Max pages per session500
Max browser-fallback ratio20%
Parse-failure abort ratio10%
Max payload per run50 MB
Max retries per request3

Known limitations

  • Keyword-search depth is bounded (see Mode 1) pending a deeper signed-API spike.
  • Creator-note dedupe uses a synthetic key. Note cards on a creator's profile tab carry no noteId, so recurring-monitoring dedupe keys them on userId + displayTitle + cover.url. Two distinct notes from the same creator that share all three (e.g. a repost or re-upload of the same cover + title) would collide and the second would be silently deduped. Discovery cards (Mode 1) are unaffected — they carry a real noteId.
  • Within-sample intelligence is not longitudinal. creatorMomentum and engagementQualityScore are computed from the rows returned in this run only. The following are deferred (candidate, not GA) and are not claimed by this Actor: trend tracking, rising-creator detection, historical backfill beyond bounded windows, demographic insights, brand-sentiment analysis, creator-fit scoring, cross-platform comparison, and any MCP server integration. They are roadmap items, not commitments.

Comparison

Capability-by-capability against the other RedNote / Xiaohongshu Actors in the Apify Store. Competitor data from public Apify Store pages, 2026-08-04; verify before relying.

CapabilityThis Actor (RedNote API)sian.agencyzen-studiohabit.zhou
Keyword search✅ (bounded depth, R-003)✅ (searchUser)✅ (deep, ~7,000/keyword)
Creator profile✅ GA (primary)❌ (search-only)
Post / note detail✅ Bounded Beta (cookie-only)✅ ($0.020/note-detail)
Comments❌ Not in V1 (deferred)✅ (noteComments)
Within-sample intelligence signals (EQS / saveRatio / momentum / fingerprint)✅ UNIQUE
Recurring-monitoring dedupe (pay only for new notes)✅ UNIQUE
Schema versioning (output.v1, runtime AJV)✅ UNIQUE
PIPL ipLocation stripping at write point✅ UNIQUE❌ (returns author IP location)
No-charge-on-failure PPE❌ (run-start fee)
Trending / KOL discovery❌ Not claimed (deferred)✅ (claims it)
Login required (Mode 1/2)❌ anonymous

FAQ

How much does it cost? — Pay-Per-Event; charged only on a successful enriched result. Five priced events (discovery_result $0.010, creator_profile $0.018, creator_note $0.006, post_detail $0.025, scheduled_run $0.02 flat/run) plus intelligence_basic, which is bundled at no surcharge ($0.01/1,000 — the Apify platform minimum, effectively free; Tier 1 is deterministic arithmetic over data the surface event already paid for). Failed/partial/auth_required rows charge nothing. See Pricing for a worked daily-monitoring cost example.

Is scraping Xiaohongshu free? — The Apify free tier ($5 platform credit) lets you try the Actor at no cost — roughly ~275 enriched creator-profile rows ($0.018 each) or ~500 discovery results ($0.010 each) before paid billing, with intelligence_basic at the platform-minimum $0.01/1,000 (effectively no surcharge — Tier 1 is deterministic arithmetic over data the surface event already paid for). Pricing limits surface as a clear upgrade message, never a bug-like error.

Do I need a cookie or login? — Mode 1 (search) and Mode 2 (creator) are anonymous: no cookie, no login, no account-ban risk to you. Mode 3 (post detail) is Bounded Beta and cookie-only: it requires your RedNote sessionCookie and carries account-ban risk. We do not scrape or generate cookies — you bring your own from an authenticated browser session (DevTools → Application → Cookies → xiaohongshu.com).

Is Mode 3 safe for my account? — No. Mode 3 uses your own RedNote session for automated extraction and may put your account at risk of restriction or ban. Use a throwaway/expendable account, use a proxy matching that account's origin, and use Mode 3 at your own risk. It is Bounded Beta with no SLA. Modes 1 and 2 carry no such risk.

How do I get creatorUrls, postUrls, or xsec_token?creatorUrl is any xiaohongshu.com/user/profile/<id> URL. postUrl is any xiaohongshu.com/explore/<noteId> URL. For batch postUrls, each entry must include its own xsec_token (from the discovery feed's noteUrl query string); the single postUrl path is cookie-driven and does not require one. Tokenless batch entries are rejected as malformed.

What does "within-sample" intelligence mean? — The intelligence signals (engagementQualityScore, engagementRate, saveRatio, commentRatio, i18nCount, creatorMomentum, contentFingerprint) are computed from the rows returned in THIS run only. They are NOT longitudinal trends, NOT cross-sample comparisons, and NOT rising-creator detection. Every sub-field is tagged method: "deterministic", scope: "within-sample".

Do you fetch comments? — Not in V1. Comments retrieval is a candidate/deferred capability per our canon (not a GA feature). If you need note comments today, sian.agency's xiaohongshu scraper offers a noteComments operation; we do not, and we say so rather than imply it.

How do I schedule recurring monitoring? — Configure mode: "creator" with your roster in creatorUrls and dedupe: true, save it as an Apify Task, and put it on a daily/weekly schedule in the Apify Console. Each scheduled run re-checks every profile but emits and bills only NEW note cards since last time; the profile row (with intelligence) is re-emitted each run. A flat scheduled_run charge applies per scheduled run, additive to per-result charges.

Can I use integrations (Make, Zapier, Slack, n8n) and the Apify API? — Yes, via standard Apify integrations and the Apify API (JS, Python, CLI). See Quick start for copy-paste snippets.

Can I use it through an MCP server? — Not yet. Any MCP server integration is deferred (roadmap, not a commitment). The Actor itself is callable via the Apify API and integrations.

Is it legal to scrape Xiaohongshu? — This Actor extracts publicly accessible, server-rendered data. It is unofficial and not affiliated with or endorsed by RedNote/Xiaohongshu. RedNote is China-hosted, so China's PIPL applies (we strip ipLocation and PII at the write point). You are responsible for lawful use and any redistribution of the dataset. This is not legal advice.

What are the limits? — ≤10,000 items/run, ≤500 pages/session, browser fallback ≤20%, abort at 10% parse failures, ≤3 retries, 50MB payload cap. These are ceilings, not targets: there is no pagination in V1 — the Actor fetches one page per URL, so discovery returns ~25–31 rows/run regardless of maxItems, and scale comes from supplying more URLs (creator batches). Keyword-search depth is bounded (we tell you the ceiling; a deeper signed-API spike is roadmap, not V1). Creator-note dedupe uses a synthetic key (userId + title + cover) because creator-tab cards carry no noteId.

What about CN-egress proxies? — RedNote is China-hosted. Residential CN-egress proxies via proxyConfiguration improve Mode 1/2 reliability. For Mode 3, use a proxy matching the cookie's origin account.

Something is not working / feedback — Best-effort support within 2 business days; no SLA beyond this. Upstream access is unofficial and may drift; field coverage is best-effort.

Versioning & changelog

Output versioning. output.v1 (schemaVersion: "2.0.0") is the contract. Additive, backward-compatible fields (such as the intelligence namespace) may appear within v1. Any breaking change to row shape ships as a new output.v2 schema, announced in the changelog with migration notice — v1 consumers are never broken silently.

See CHANGELOG.md for version history and migration notes.

Support

Best-effort support within 2 business days. There is no SLA beyond this.