推特 API 接口 — 实时获取推文、用户、关注者数据
中文开发者在搜索「推特 API 接口」时,通常想要的是一份清晰的接口清单 + 调用示例 + 计费说明,而不是泛泛的产品介绍。本文以 TwitterAPI.io 这一面向全球开发者的 SaaS 数据 API 为例,把推特(X)API 接口的全貌讲清楚:约 75 个端点的功能分类、每类的典型使用场景、和官方 X API 的接口对照、5 分钟从注册到第一个成功调用的完整流程。
TwitterAPI.io 提供的接口分为读取类(advanced search、user info、followers、tweets timeline、replies、quotes、retweeters 等约 60 个)和常用写入类(create_tweet 发推、like_tweet 点赞、retweet 转推、follow_user / unfollow_user 关注/取关 等约 15 个)。唯独私信(DM)发送接口不开放 — 因为 API 发送 DM 极易触发 X 的反垃圾风控导致账号被封禁,出于账号安全考虑产品策略上不提供。
适用人群:用 Python / Node.js / Go 等任何语言做推特数据采集、舆情监控、社交媒体分析、加密项目情报、AI 训练语料、跨境营销复盘、品牌出海监控等读取场景的开发者;或需要程序化发推 / 点赞 / 转推 / 关注的自动化工作流。不适用:需要 API 发送 DM 的项目(必须用官方 X API 且仍有较高被风控的风险)、需要 X 官方平台合作身份背书的项目。
推特 API 接口 7 大功能分类(共约 75 个端点)
TwitterAPI.io 的约 75 个端点按功能分为 7 大类。下面这张表是工程接入时最常查的快速索引。
1. 推文搜索类(约 8 个):最常用的是 /twitter/tweet/advanced_search(支持 X 原生 advanced search syntax,可按 keyword / from:user / since: 等组合查询)、/twitter/tweets(按 tweet ID 批量查详情)、/twitter/tweet/replies(查某条推文的回复)、/twitter/tweet/quotes(查某条推文的引用转推)、/twitter/tweet/retweeters(查某条推文的转推者列表)、/twitter/tweet/thread_context(查推文所在的完整 thread)。
2. 用户数据类(约 8 个):/twitter/user/info(单个用户基础资料 by username 或 user_id)、/twitter/user/batch_info_by_ids(批量按 ID 查多个用户)、/twitter/user/last_tweets(用户最近 N 条推文)、/twitter/user/tweet_timeline(用户完整 timeline,含回复和转推)、/twitter/user/mentions(被提到的推文)、/twitter/user/search(按 keyword 搜索用户)、/twitter/user_about(用户详细 about / bio)。
3. 关注关系类(约 6 个):/twitter/user/followers(粉丝列表,分页 cursor)、/twitter/user/followers_ids(只要 ID 的快速版,批量大时省 80% 流量)、/twitter/user/followings(关注列表)、/twitter/user/verifiedFollowers(只看 verified 粉丝)、/twitter/user/check_follow_relationship(检查 A 是否关注 B)。
4. 写入操作类(约 15 个):/twitter/create_tweet(发推,支持纯文本 + 图片 + 视频)、/twitter/like_tweet / /twitter/unlike_tweet_v2(点赞 / 取消点赞)、/twitter/retweet_tweet / /twitter/retweet_v3(转推)、/twitter/follow_user_v2 / /twitter/unfollow_user_v2(关注 / 取关)。注意:DM 发送(send_dm_to_user 等)出于账号安全考虑不开放,见 §「写入接口的边界」。
5. 实时推送类(Webhook / WebSocket,约 8 个):/oapi/tweet_filter/add_rule(注册过滤规则)、/oapi/tweet_filter/get_rules(列规则)、/oapi/tweet_filter/update_rule / /oapi/tweet_filter/delete_rule(改/删)。配合 Webhook URL 或 WebSocket 连接,新推文匹配规则后秒级推送到调用方。
6. Trends 与发现类(约 6 个):/twitter/trends(按 WOEID 查询某地区的热门话题)、/twitter/community/info(社区信息)。
7. 其他工具类(约 18 个):DM 历史读取(/twitter/get_dm_history_by_user_id — 注意是读历史不是发送,读自己账号的历史 DM 是 OK 的)、Spaces、List、其他辅助端点。
5 分钟从注册到第一个成功调用
TwitterAPI.io 的接入设计目标是「5 分钟跑通」。不需要 OAuth、不需要任何审核、不需要绑卡。完整流程如下。
第 1 步:Google 一键登录获取 API Key。打开 twitterapi.io,点 Sign in with Google,即时拿到 API Key(格式形如 cb482...)。新账号默认 $1 试用额度(可调约 6,000 次基础接口),不需要绑卡。
第 2 步:第一个 curl 调用 — 读 @openai 的最新推文。把下面命令粘到终端,把 YOUR_KEY 换成你的 Key:
和官方 X API 接口的对照
对在「官方 X API」和「TwitterAPI.io」之间犹豫的开发者,关键接口对照如下。所有维度基于公开信息(docs.x.com 与 docs.twitterapi.io 在 2026 年 5 月的状态)。
接入流程:官方 X API 需要走 OAuth 2.0 / OAuth 1.0a 认证 + 申请 developer account + 项目审核(2026 年起新建项目的人工审核周期通常在 1-2 周);TwitterAPI.io 用 Google 一键登录,API Key 即时下发,从注册到第一个成功调用通常在 5 分钟内。
计费模型:官方 X API 2026 年 2 月切到混合计费 — 月费起步 + 按资源单价计费 + 2,000,000 Posts/月硬上限(超出后不可购买更多),Basic 月费 $200、Pro 月费 $5,000;TwitterAPI.io 按调用次数计费,约 $0.15 / 1,000 条推文返回,无月费、无月度上限。
接口对照(关键端点):
| 用途 | 官方 X API(典型 endpoint) | TwitterAPI.io |
|---|---|---|
| 推文 advanced search | GET /2/tweets/search/all(Academic / Pro 限定) | /twitter/tweet/advanced_search |
| 用户基础信息 | GET /2/users/by/username/:username | /twitter/user/info |
| 用户最近推文 | GET /2/users/:id/tweets | /twitter/user/last_tweets |
| 粉丝列表 | GET /2/users/:id/followers | /twitter/user/followers |
| 发推 | POST /2/tweets(OAuth user context) | /twitter/create_tweet |
| 点赞 | POST /2/users/:id/likes | /twitter/like_tweet |
| 转推 | POST /2/users/:id/retweets | /twitter/retweet_tweet |
| 关注 | POST /2/users/:id/following | /twitter/follow_user_v2 |
| 实时流 | Filtered Stream(Pro 层 $5,000/月起) | /oapi/tweet_filter/add_rule + Webhook/WebSocket |
| 私信发送 | DM v2 endpoints(OAuth + 严格风控) | 不开放(见下) |
实际选型建议:如果项目需要 API 发送 DM,必须用官方 X API(且仍有较高被风控的风险)。其他情况下,TwitterAPI.io 通常更经济 — 读类 + 常用写类都提供,且对接入速度、月费门槛、批量能力更友好。
写入接口的边界 — 为什么 DM 发送不开放
TwitterAPI.io 在写入接口上的产品策略是:常用写入(发推 / 点赞 / 转推 / 关注 / 取关)全部开放,但 DM 发送刻意不提供。这个边界来自工程实践:
X 平台对 API 行为的风控分级。X(原 Twitter)的反垃圾系统对不同操作的容忍度不同 — 发推、点赞、转推、关注这类「公开互动」操作,只要频率合理(不超出人类节奏),平台默认允许;但 DM 是 1-to-1 私密通信,从用户体验角度任何自动化批量发送都是 spam 候选,X 的风控对 API 调用 DM 的检测极其严格。
实际数据:在公开社区报告里,通过 API 程序化发 DM 的账号被封禁率远高于其他类型操作,无论调用量大小。即使每天只发 5-10 条 DM,只要风控判定行为非人类(消息内容相似、间隔规律、收件人结构异常)就会触发封禁。
产品决策:基于这个事实,TwitterAPI.io 主动不提供 DM 发送接口,避免用户在不知情下程序化发 DM 导致自己主账号被封。这是产品对用户负责的边界,不是技术能力问题。
项目真的需要 DM:如果业务场景真的需要 DM(例如 CRM 工具的客服回复),只能走官方 X API 的 OAuth 用户授权路径,且需要做好风控措施 — 控制频率、随机化间隔、避免内容相似、最好接入 X 官方 Premium / Premium+ 提高频率限额。
三个高频接入场景的端点组合
下面三个组合是接入时最常 ramp 出来的「场景套餐」,每个场景给出主用端点 + 配合端点 + 月度调用量估算。
场景一:品牌舆情监控(中小规模,月调用 50-200 万)
- 主用端点:/twitter/tweet/advanced_search(用 keyword + lang:zh 过滤每天匹配品牌名的新推文)
- 配合端点:/twitter/tweet/replies 查每条匹配推文的回复树、/twitter/user/info 拿评论者的粉丝数做权重
- 月度成本:50-200 万次 × $0.00015 = $75 - $300 / 月
场景二:加密 KOL 追踪(实时,月调用 200-500 万)
- 主用端点:/oapi/tweet_filter/add_rule 注册规则 from:KOL1 OR from:KOL2 OR ...
- 配合 Webhook:KOL 发新推文秒级推到内部 Slack / 自建 dashboard
- 月度成本:200-500 万次 × $0.00015 = $300 - $750 / 月
场景三:跨境电商互动自动化(读 + 写,月调用 100-300 万)
- 读取:/twitter/tweet/advanced_search 找品牌相关推文
- 写入:/twitter/like_tweet 自动点赞、/twitter/create_tweet 回复推荐内容
- 频率控制:点赞 / 回复严格按人类节奏(每小时 < 30 次)避开风控
- 月度成本:100-300 万次 × $0.00015 = $150 - $450 / 月
接口使用最佳实践
几个工程实践能让 API 调用成本和稳定性大幅改善。
1. 缓存热点查询。对高频复用的查询(知名 KOL 的最近推文、热门关键词搜索结果)做 Redis / Memcached 缓存,TTL 5-15 分钟即可去掉 80% 重复调用。
2. 使用轻量端点。需要粉丝 ID 列表时用 /twitter/user/followers_ids(只返 ID 数组)而不是 /twitter/user/followers(返完整 profile),流量节省 80% 以上。
3. 分页 cursor 而非数字 offset。所有列表端点都用 next_cursor 翻页(性能稳定),不用旧式 page 数字翻页。
4. 错误重试加 backoff。HTTP 429 / 5xx 重试时用 exponential backoff(0.5s → 1s → 2s → 4s),不要立即 retry。
5. 写入操作频率人类化。所有写入(发推 / 点赞 / 转推 / 关注)严格按人类节奏控制:每小时点赞 < 30、每天发推 < 50、间隔随机化。不要批量爆发。
6. 调用配额监控。后端记录每个 user / feature 的调用次数,设预警阈值($100 / 月 → ping,$500 / 月 → 自动暂停),避免某个 bug 导致调用量爆炸。
# 拿 @openai 的最新 20 条推文 — 把 YOUR_KEY 换成 twitterapi.io Dashboard 的 API Key
curl -s -H "X-API-Key: YOUR_KEY" \
"https://api.twitterapi.io/twitter/user/last_tweets?userName=openai" \
| head -c 800
# 返回结构
# {
# "status": "success",
# "data": {
# "tweets": [
# {
# "id": "1800...",
# "text": "...",
# "createdAt": "2026-05-27T...",
# "author": { "userName": "openai", "name": "OpenAI", ... },
# "likeCount": 1234,
# "retweetCount": 56,
# "replyCount": 78
# },
# ... 更多
# ],
# "next_cursor": "..."
# }
# }
# advanced search — 过去 7 天提到 "openai" 的中文推文
curl -s -H "X-API-Key: YOUR_KEY" \
"https://api.twitterapi.io/twitter/tweet/advanced_search?query=openai+lang:zh&queryType=Latest" \
| head -c 600
# 发推(常用写入端点示例)
curl -s -X POST -H "X-API-Key: YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"hello world from twitterapi.io"}' \
"https://api.twitterapi.io/twitter/create_tweet"常见问题
推特 API 接口总共有多少个?
TwitterAPI.io 当前公开约 75 个端点,按功能分 7 大类:推文搜索(~8)、用户数据(~12)、关注关系(~8)、写入操作(~15)、实时推送 Webhook/WebSocket(~8)、Trends 与发现(~6)、其他工具类(~18)。完整端点清单见 docs.twitterapi.io,本文给出了每类的典型代表端点。
TwitterAPI.io 的接口跟官方 X API 是同一套吗?
不是。TwitterAPI.io 是一个独立的 SaaS API 服务,主机名是 api.twitterapi.io,跟官方 X API 的 api.twitter.com 主机完全不同的 endpoint。但两边能拿到的数据基本对应(同样的推文、用户、互动关系),只是 TwitterAPI.io 的接入门槛低(不需要 OAuth + 不需要审核 + 按次计费无月费)。具体路径对照见本文「和官方 X API 接口的对照」章节。
需要 OAuth 审核吗?多久能跑通第一个调用?
不需要 OAuth、不需要任何审核。流程:Google 一键登录 → Dashboard 即时拿 API Key → curl 调用(Key 放 X-API-Key HTTP header 里)。从注册到第一个成功调用通常 5 分钟内。官方 X API 走 OAuth 2.0 + 项目审核,2026 年起人工审核周期一般 1-2 周。
接口怎么计费?有月费门槛吗?
按调用次数计费,推文返回约 $0.15 / 1,000 条(参考公开定价页),没有月费、没有月度配额上限。新账号默认 $1 试用额度(可调约 6,000 次基础接口),不需要绑卡即可试用。100 万次推文请求 / 月用量下约 $150。
能用接口发推、点赞、关注吗?
能。/twitter/create_tweet(发推)、/twitter/like_tweet(点赞)、/twitter/retweet_tweet(转推)、/twitter/follow_user_v2 / /twitter/unfollow_user_v2(关注 / 取关)、/twitter/unlike_tweet_v2(取消点赞)都开放调用。注意频率人类化:每小时点赞 < 30、每天发推 < 50、间隔随机化,避开 X 反垃圾风控。
能用接口发私信(DM)吗?
不能。这是 TwitterAPI.io 刻意不提供的能力 — API 发 DM 极易触发 X 反垃圾系统导致账号封禁,产品策略上出于保护用户账号安全考虑不开放。如果业务必须做 DM 发送,只能走官方 X API 的 OAuth 用户授权路径(且仍有较高被风控风险)。但 DM 历史读取(/twitter/get_dm_history_by_user_id,只读自己账号的 DM 历史)是开放的。
实时推送怎么用?Webhook 和 WebSocket 都支持吗?
两种都支持。流程:/oapi/tweet_filter/add_rule POST 一个过滤规则(写法用 X advanced search syntax,例如 from:openai OR from:anthropic),配合 Webhook URL(填在 Dashboard,新推文匹配规则后 POST 到你的 URL)或 WebSocket 连接(持久连接秒级 push)。Webhook 适合纯后端服务,WebSocket 适合前端 dashboard 直连。两种延迟都在数秒到数十秒级。
支持哪些编程语言?
任何能发 HTTPS 请求的语言都行 — TwitterAPI.io 是标准 RESTful + JSON。常见接入:Python(requests)、Node.js(axios / node-fetch)、Go(net/http)、Java(OkHttp)、Ruby(Net::HTTP)、PHP(curl)、Rust(reqwest)。Dashboard 提供 cURL + Python + Node.js 三种示例代码模板。