提示: 每个账号均有 100 次免费请求,无需信用卡、永不过期。可用它们验证下方模式并测量真实请求量,再选择套餐。
示例环境设置
Python 示例在后端运行,使用requests(通过 python -m pip install requests 安装)。运行前替换 API 密钥和示例 ID。search_results 指前一次请求返回的推文对象列表。
原则 1:每个推文响应已包含用户数据
这是提高 Sorsa API 效率最重要的一点。所有返回推文的端点(/search-tweets、/user-tweets、/list-tweets、/comments、/quotes、/mentions)都会在每个推文对象内嵌入完整作者资料。
user 对象包含与单独调用 /info 相同的数据:ID、用户名、显示名称、简介、粉丝数、关注数、推文数、认证状态、所在地、创建日期、头像等。
实际意义: 搜索某话题推文并构建讨论者列表时,无需再为每位作者单独调用 /info,直接提取响应中的用户数据即可:
/info 请求。
原则 2:优先使用现有批量端点
Sorsa 为常用查询提供批量版本。使用它们替代循环调用单条端点,可显著减少请求。用 /info-batch 替代循环 /info
需要多个账号资料时,使用 /info-batch 一次获取最多 100 份:
用 /tweet-info-bulk 替代循环 /tweet-info
已有推文 ID 列表,例如档案、提及导出或书签链接,需要当前互动指标和作者资料时,可通过批量端点一次补全最多 100 条:
原则 3:用 /list-tweets 替代多次 /user-tweets
监测或收集多个账号的近期推文时,不要逐个轮询。将它们加入 X 列表,一次 /list-tweets 即可返回所有成员合并后的近期活动。
原则 4:将 /info 作为通用解析端点
/info 接受用户名、用户 ID 或资料链接,并返回包含永久用户 ID 的完整资料,是统一不同输入格式的灵活方式。
收到不同格式的账号引用并需要完整资料时,每个账号只调用一次 /info,无需先调用 /username-to-id 或 /link-to-id 再单独查询资料:
id,不再请求。转换模式见 ID 转换。
原则 5:在数据库层去重
从搜索、粉丝、提及和时间线等多个来源收集数据时,同一用户会多次出现。使用永久用户 ID 去重,并更新已有记录,避免重复插入。原则 6:不要重复获取已有数据
构建多步骤管道时,将数据向后传递,而非再次获取。 示例:受众地理分析。 流程是先获取粉丝,再逐个通过/about 查询国家。第一步已包含完整粉丝资料,如简介、粉丝数和认证状态。第二步无需再次调用 /info,只需通过 /about 获取标准资料没有的国家数据。完整流程见受众地理分布。
示例:活动验证。 检查关注、转推和评论时,/check-comment 在 commented: true 时已包含完整评论推文。需要检查正文质量时直接提取,无需另外调用 /search-tweets 或 /comments 查找。
示例:从搜索结果构建用户列表。 如果已从推文嵌入的 user 对象收集到 500 位不同用户,想筛选粉丝超过 10,000 的账号时,直接过滤已有数据,无需为每位用户调用 /info。
快速参考:选择正确端点
估算请求预算
项目开始前先估算总请求数:
典型竞品情报和活动验证流程可能合计为:50(粉丝)+ 10,000(地理)+ 1(批量推文)+ 8,640(监测)+ 5,000(活动)≈ 23,700 次请求。按每秒 20 次计算,吞吐的理论最短耗时约 20 分钟。但监测本身仍持续一整天,串行分页、响应延迟和重试也会增加实际耗时。各套餐成本见价格。