小红书用户搜索 API
POST
接口健康状态
- 24h 健康值
- 正常
- 24h 平均耗时
- —
- 最近检查时间
- 2026年9月30日 13:12(北京时间)
- 健康 / 正常
- 可用
- 少量可用
- 基本不可用
健康 API正常
24 小时趋势
30 天趋势
健康值怎么算
- 健康值 = 返回了数据的调用占比(百分比)。空结果、失败和结果未知都不算返回数据。
- 档位:≥90% 健康、≥70% 可用、≥40% 少量可用,更低是基本不可用。
- 一个时段(24 小时、每小时、每天)调用满 50 次才计算健康值;不足的时段显示为正常——少量调用里的偶发失败不代表接口不可用。
- 调用包括客户的真实调用和我们每天的探测调用;请求本身的错误(参数不对、余额不足)不计入。
- 平均耗时只算正常返回的调用:同步取响应时间,异步取受理到完成。
逐时段数据
| 时间(北京时间) | 状态 | 健康值 | 平均耗时 |
|---|---|---|---|
| 2026-09-30 13:00 - 13:59 | 正常 | — | — |
| 2026-09-30 12:00 - 12:59 | 正常 | — | — |
| 2026-09-30 11:00 - 11:59 | 正常 | — | — |
| 2026-09-30 10:00 - 10:59 | 正常 | — | — |
| 2026-09-30 09:00 - 09:59 | 正常 | — | — |
| 2026-09-30 08:00 - 08:59 | 正常 | — | — |
| 2026-09-30 07:00 - 07:59 | 正常 | — | — |
| 2026-09-30 06:00 - 06:59 | 正常 | — | — |
| 2026-09-30 05:00 - 05:59 | 正常 | — | — |
| 2026-09-30 04:00 - 04:59 | 正常 | — | — |
| 2026-09-30 03:00 - 03:59 | 正常 | — | — |
| 2026-09-30 02:00 - 02:59 | 正常 | — | — |
| 2026-09-30 01:00 - 01:59 | 正常 | — | — |
| 2026-09-30 00:00 - 00:59 | 正常 | — | — |
| 2026-09-29 23:00 - 23:59 | 正常 | — | — |
| 2026-09-29 22:00 - 22:59 | 正常 | — | — |
| 2026-09-29 21:00 - 21:59 | 正常 | — | — |
| 2026-09-29 20:00 - 20:59 | 正常 | — | — |
| 2026-09-29 19:00 - 19:59 | 正常 | — | — |
| 2026-09-29 18:00 - 18:59 | 正常 | — | — |
| 2026-09-29 17:00 - 17:59 | 正常 | — | — |
| 2026-09-29 16:00 - 16:59 | 正常 | — | — |
| 2026-09-29 15:00 - 15:59 | 正常 | — | — |
| 2026-09-29 14:00 - 14:59 | 正常 | — | — |
| 2026-09-30 | 正常 | — | — |
| 2026-09-29 | 正常 | — | — |
| 2026-09-28 | 正常 | — | — |
| 2026-09-27 | 正常 | — | — |
| 2026-09-26 | 正常 | — | — |
| 2026-09-25 | 正常 | — | — |
| 2026-09-24 | 正常 | — | — |
| 2026-09-23 | 正常 | — | — |
| 2026-09-22 | 正常 | — | — |
| 2026-09-21 | 正常 | — | — |
| 2026-09-20 | 正常 | — | — |
| 2026-09-19 | 正常 | — | — |
| 2026-09-18 | 正常 | — | — |
| 2026-09-17 | 正常 | — | — |
| 2026-09-16 | 正常 | — | — |
| 2026-09-15 | 正常 | — | — |
| 2026-09-14 | 正常 | — | — |
| 2026-09-13 | 正常 | — | — |
| 2026-09-12 | 正常 | — | — |
| 2026-09-11 | 正常 | — | — |
| 2026-09-10 | 正常 | — | — |
| 2026-09-09 | 正常 | — | — |
| 2026-09-08 | 正常 | — | — |
| 2026-09-07 | 正常 | — | — |
| 2026-09-06 | 正常 | — | — |
| 2026-09-05 | 正常 | — | — |
| 2026-09-04 | 正常 | — | — |
| 2026-09-03 | 正常 | — | — |
| 2026-09-02 | 正常 | — | — |
| 2026-09-01 | 正常 | — | — |
用户搜索:返回列表,每次一页、固定 20 条(最后一页可能更少),要更多就把结果行里的 next_page_token 作为 page_token 再调;limit 照收但不起作用;主要字段 user_id、nickname、red_id、avatar_url、url、follower_count。支持翻页:把响应里的 next_page_token 作为 page_token 传回拿下一页,其他参数不变,每页算一次调用。
单价 $5.56 / 千次(每次 $0.005556),失败与空结果不扣费。 同步返回;慢任务可在请求体加 "mode": "async",先拿 job_id 再轮询。
请求参数
| 参数名 | 位置 | 类型 | 必填 | 默认值 | 说明 |
|---|---|---|---|---|---|
Authorization | header | string | 是 | - | Bearer 加你的 API Key。在控制台创建;不要放进网址或代码仓库。 |
platform | body | string | 是 | xiaohongshu | 平台标识,固定值。 |
action | body | string | 是 | search_users | 能力标识,固定值。 |
keyword | body.params | 未声明 | 是 | - | 找账号的关键词,如 咖啡、品牌名或领域词;返回的是用户(博主、品牌号),不是笔记。 |
follower_range | body.params | enum | 否 | - | search_users 按粉丝量级筛选账号:under_100 不到 100、100_to_1k 100–1000、1k_to_10k 1000–1万、10k_to_100k 1万–10万、over_100k 10万以上;不传不限。允许值100_to_1k10k_to_100k1k_to_10kover_100kunder_100 |
page_token | body.params | 未声明 | 否 | - | 翻页游标(comments、sub_comments、search、user_posts、search_users、hashtag):把上一次返回结果行里的 next_page_token 原样传入就拿下一页;不传从第一页开始。每页算一次调用,按次计费。 |
user_type | body.params | enum | 否 | - | search_users 按账号类型筛选:general 普通用户、verified_individual 个人认证、business 企业认证;不传不限。允许值businessgeneralverified_individual |
代码示例
text
我想用 EveryInfra API 的「用户搜索」(xiaohongshu/search_users)采集数据。请你当我的数据采集助手,按下面三步来。
第一步:先不要写代码。一轮一轮地问我,每次只问 1–3 个问题,直到下面这些都清楚:
1. 这些数据拿来做什么(决定要哪些字段、要多少);
2. 具体采哪些对象:关键词、链接还是 ID,一共多少个;
3. 要多少条、要不要翻页、时间范围;
4. 需要哪些字段(先查文末目录里有哪些字段,再问我);
5. 结果存成什么:CSV、Excel、JSON 还是数据库,存在哪里;
6. 脚本用什么语言、在哪里运行,跑一次还是定时跑;
7. 这次最多愿意花多少钱。
我答得含糊或前后矛盾,就继续追问;我说不知道,就给出建议让我确认。
第二步:写代码前,先把方案讲给我确认:要发哪些请求、大约调用多少次、按目录价格大约花多少钱、结果长什么样。
第三步:我确认后再写脚本,并遵守下面的接口约定:
- 请求:POST https://api.everyinfra.com/api/v1/social
- 鉴权:请求头 Authorization: Bearer <API Key>,Key 从环境变量 EVERYINFRA_API_KEY 读取,不要写进代码、日志或提交记录。
- 请求体示例(字段名和取值按原样使用):
{
"platform": "xiaohongshu",
"action": "search_users",
"params": {
"keyword": "咖啡"
}
}
- 慢任务或数据量大时,在请求体加 "mode": "async":接口先返回 202 和 job_id,再轮询 GET https://api.everyinfra.com/api/v1/jobs/{job_id},直到 status 为 succeeded 或 failed。202 不是成功。同步请求返回超时错误时,加上 "mode": "async" 重发同一个请求。
- 结果里有 next_page_token 时,把它作为 page_token 传回拿下一页,其他参数不变;每页算一次调用。
- 失败或空结果不形成最终扣费,已预扣的会自动退回;以响应里的 billing 和 refund 字段为准。
- 返回 422 时,按错误信息里的候选参数名和允许值修正,不要自行猜测参数。
- 返回 429 或 503 时,按 Retry-After 等待后再试;没有 Retry-After 就逐步拉长间隔。
- 网络中断或结果未知时,保留 request_id / job_id 并先查询,不要自动重发请求。
- 参数、允许值、字段和价格:GET https://api.everyinfra.com/api/v1/social/catalog?platform=xiaohongshu(不需要 Key)[OpenAPI 定义 (JSON)]示例从环境变量 EVERYINFRA_API_KEY 读取 Key,复制出去的代码不含你的 Key。
响应示例
字段预览
这组示例参数还没有真实样例:这里只按契约列出响应结构和字段,值用 … 占位,不是一次真实调用的结果。
json
{
"id": "req_…",
"platform": "xiaohongshu",
"action": "search_users",
"results": [
{
"user_id": …,
"nickname": …,
"red_id": …,
"avatar_url": …,
"url": …,
"follower_count": …,
"is_verified": …,
"verification_type": …,
"next_page_token": …,
"platform": …
}
],
"count": …,
"billing": { … },
"quota": { … }
}返回字段
业务数据在 results 里;下表是每条记录可能包含的字段,平台没有提供的值不会被补造。
| 字段 | 含义 |
|---|---|
user_id | 用户在原平台的唯一 ID。 |
nickname本平台特有 | 用户昵称。 |
red_id本平台特有 | 小红书号,用户自定义的可搜索 ID,区别于内部 user_id。 |
avatar_url | 头像图片链接。部分平台给的是带尺寸参数的 CDN 链接,可能有时效。 |
url本平台特有 | 该记录在小红书上的链接。search、note、profile、hashtag 返回的链接一般带访问令牌,未登录的浏览器也能打开(令牌有时效,过期后重新调用即可);user_posts 返回的笔记链接不带令牌,在浏览器里打开需要令牌:用笔记 ID 调 note 能拿到可以打开的链接;search_users 返回的主页链接同样不带令牌,用 user_id 调 profile 拿能打开的链接。 |
follower_count本平台特有 | 粉丝数。profile 里是精确值;search_users 里是从列表展示的「粉丝 1.2万」换算的近似值(1.2万 → 12000)。null 表示不公开或没认出来,不等于 0。 |
is_verified | 是否为平台认证账号(蓝V等)。null 表示无法判定。 |
verification_type本平台特有 | 认证类型(search_users):individual 个人认证、business 企业认证、other 其他认证;未认证的账号没有这个字段。 |
next_page_token | 保留平台原语义 |
platform | 数据来源平台标识,与请求里的 platform 一致(如 xiaohongshu、tiktok)。 |
错误与计费
- 401
- 缺少 Key 或 Key 无效。先鉴权再校验参数,未鉴权的请求拿不到参数结构。
- 422
- 参数名或取值不对。错误信息会列出这项能力支持的参数、允许值和最接近的候选,按它改即可;发生在扣费之前。
- 402
- 余额不足,请先充值。
- 429
- 超过每分钟请求上限,按 Retry-After 等待后再试。
- 503
- 暂时无法完成。已预扣的费用按原账本退回;响应里的 billing 与 refund 写明实际结果,结果未知时会明确标出,不要直接重发。
- 200 空结果
- 请求完成但没有数据,不扣费(billing.reason = empty_result_refunded)。