X(推特)API 价格完整对比 — 官方 Tier vs 按次计费 SaaS
X(原 Twitter)API 的价格在 2026 年 2 月有过一次重大变化 — 从过去的纯 tier-based 月费模型,切换到 混合计费:月费起步 + 按资源单价计费 + 2,000,000 Posts 月度硬上限。这次切换让中等规模项目的成本曲线发生了显著变化,很多原本「Basic 够用」的项目突然撞上 2M 上限,被迫升级到 Pro 层 $5,000/月起。
本文以 2026 年 5 月公开的 docs.x.com 计费数据为准,把官方 X API 的三个 tier(Basic / Pro / Enterprise)+ 第三方 SaaS(TwitterAPI.io 按次计费)做完整成本拆解。重点是真实用量档下的对比 — 不只是看月费数字,而是看「每千次推文请求实际花多少」+「不同业务规模下哪个方案更经济」+「2M 月度硬上限对中型项目的影响」。
适用读者:正在做 Twitter 数据 API 商业决策的工程负责人 / 创始人;评估官方 vs 第三方 API 的产品经理;为出海舆情 / 加密项目 / 跨境营销 / AI 训练等业务采购 API 服务的采购方。不适用:只是好奇的技术爱好者(可以看 §1 概览即可)。
X API 2026 年 2 月混合计费切换概览
2026 年 2 月之前,官方 X API 是纯 tier-based 月费模型 — Basic $200/月、Pro $5,000/月、Enterprise $42,000+/月,每个 tier 有固定的 Posts 读取额度。2 月切换后变成 「月费起步 + 按资源单价 + 月度硬上限」 的混合模型:
- Basic 月费 $200:含 2,000,000 Posts/月读取额度,硬上限(超出后不可购买更多)+ 写入 $0.005/次 overage(超出基础读取额度的 Posts 按 $0.005/次计费,但仍受 2M 月上限制约)
- Pro 月费 $5,000:含 2,000,000 Posts/月读取额度(注意:Pro 的额度跟 Basic 一样!Pro 主要加的是高级功能如 Filtered Stream / advanced search 等)+ 同样的 2M 月度硬上限
- Enterprise 月费 $42,000+:含更高额度 + Filtered Stream / Spaces / Ads API 等完整能力
2M 月度硬上限是这次切换最大的变化。它意味着:无论你付 $200 还是 $5,000,Posts 读取都不能超过 2 百万次。中型项目如果月度调用稳定在 300-500 万次,在 2 月之前可能 Basic 还能用(超额 overage),2 月之后必须升级到 Enterprise 或者放弃官方 API。
资源单价(超出基础额度的 overage,但仍受月上限制约):
- Posts read: $0.005 / 次
- User / DM read: $0.010 / 次
- Owned reads(自己账号的数据): $0.001 / 次
- Post creation: $0.015 / 次
- URL Post creation: $0.200 / 次
TwitterAPI.io 计费模型
TwitterAPI.io 是面向全球开发者的 SaaS 数据 API 服务,定价逻辑跟官方完全不同:
- 按调用次数线性计费,每条推文返回约 $0.15 / 1,000 条 = $0.00015 / 次
- 没有月费起步(新账号 $1 试用额度,不需要绑卡,约可调 6,000 次基础接口)
- 没有月度硬上限(余额够扣就一直能调,没有 2M 限制)
- 写入操作同样按次计费,价格跟读取在同一量级(具体见 docs.twitterapi.io 定价页)
- 没有 tier 概念,所有用户用同一套定价 + 同一套约 75 个端点(写入端点中 DM 发送不开放,产品策略保护账号安全)
计费公式极简:月度成本 = 月度调用次数 × $0.00015。100 万次 = $150,500 万次 = $750,1000 万次 = $1,500。线性可预测,没有 tier 切换的成本断崖。
5 个真实用量档下的成本对比
下面这张表给 5 个常见用量档下两个方案的月度实际成本。所有数字基于 2026 年 5 月公开定价。
| 月度用量 | 典型场景 | 官方 X API | TwitterAPI.io | 差额 |
|---|---|---|---|---|
| 10,000 次 | 个人 PoC / 学术研究采样 | Basic $200(月费门槛) | $1.5 | 节省 $198(99%) |
| 100,000 次 | 小品牌出海试水 | Basic $200(在额度内) | $15 | 节省 $185(93%) |
| 500,000 次 | 中型 SaaS 工具 | Basic $200(在额度内) | $75 | 节省 $125(63%) |
| 2,000,000 次 | 中大型舆情平台 | Basic $200(撞到月上限) | $300 | TwitterAPI.io +$100 但无月上限制约 |
| 5,000,000 次 | 大型监控 / 加密情报 | Enterprise $42,000+(Basic/Pro 撞上限) | $750 | 节省 $41,250(98%) |
关键观察:
1. 10K-500K 用量档:TwitterAPI.io 因为没有 $200 月费门槛,节省 60%-99%
2. 2M 用量档:两边接近(TwitterAPI.io 略贵 $100),但 TwitterAPI.io 没月度上限,未来可继续扩张
3. 5M+ 用量档:官方撞 2M 上限被迫 Enterprise $42,000+,TwitterAPI.io 仍是线性 $750,节省 50×+
中型以上项目几乎不可能选官方,除非业务上必须用官方接口(例如需要 Twitter Ads partner 资质)。
2,000,000 月度硬上限对哪些业务影响最大
2M 月上限不是均匀分布的痛 — 它精准卡在「中型项目」这个区间,这恰好是大量出海 SaaS / 跨境品牌 / 加密项目的实际用量段。
重灾区一:实时舆情监控。监控 50-200 个 keyword + 全平台公开数据,每个 keyword 每天可能产生数百-数千条新推文。50 keyword × 1,000 条/天 × 30 天 = 150 万次/月,Basic 还在额度内但接近上限。涨到 100 keyword 立刻撞顶。
重灾区二:KOL 矩阵跟踪。跟踪 500-2,000 个 KOL 的最新推文 + 互动数据。500 KOL × 每天 polling 3 次 last_tweets × 30 天 = 45,000 次/月(读 timeline 用得不多),但加上每条推文 fetch 回复 + retweeters 后,实际可能 500 KOL × 平均 3 推文/天 × 50 互动 fetch × 30 天 = 225 万次/月,直接撞顶。
重灾区三:AI 训练数据持续采集。每天采集 N 万条公开中文推文做 NLP 训练。10 万条/天 × 30 天 = 300 万次/月,直接超出。这类业务在官方 API 上完全不可行,只能走第三方。
安全区(2M 内够用):个人开发者 PoC、单品牌出海舆情(月度 < 80 万次)、小型加密项目情报(月度 < 100 万次)。这类业务可以继续用官方 Basic,但要小心成长期突然撞顶的临界点。
Enterprise 层值不值 $42,000+/月
Enterprise 层是给真正需要官方品牌背书 + 高级能力的项目。但 $42,000+/月对绝大多数项目来说成本过高。来看 Enterprise 实际提供的能力:
只在 Enterprise 才开放的能力:Filtered Stream(实时高频推送,每秒级)、Ads API(广告投放数据)、Spaces 录制 API、Premium analytics、官方合作伙伴标识。这些对广告平台 / 媒体合作伙伴 / 大型监控 SaaS 是刚需,对普通业务用不到。
Enterprise 不解决的问题:同样的 2M Posts/月硬上限(Enterprise 额度更高但仍有上限),且写入操作风控仍然严格(API 发 DM 仍易封号)。Enterprise 主要是「能力扩张」不是「成本降低」。
TwitterAPI.io 是否能替代 Enterprise:对纯数据采集类业务可以(Webhook + WebSocket 提供秒级实时推送,Trends 端点可用,advanced search 完整)。对需要官方合作伙伴资质的业务(例如 Twitter Ads partner、官方媒体合作)不行 — 这是商业合作问题不是技术 API 问题,只能官方 Enterprise。
决策树:
- 需要官方合作伙伴资质 → Enterprise,无替代
- 需要 Filtered Stream / Ads API / Spaces 录制 → Enterprise 或拼 Pro+ 自定义合同
- 只要数据(读 + 常用写入)+ 实时推送 + Trends → TwitterAPI.io 完全够用,成本 1/10-1/50
实际选型的 4 个判断维度
选 API 的核心 4 个维度:
维度 1:月度调用量预估。先做粗略估算 — 多少 keyword × 多少推文/天 × 多少次 fetch + 多少 KOL × 多少次 polling/天 + 多少互动 fetch + 多少 webhook push。算出来在 100 万次以内 → 任何方案都行;100-500 万次 → 强烈倾向 TwitterAPI.io;500 万次以上 → 必走 TwitterAPI.io 或类似第三方。
维度 2:接入时间预算。需要立即起步(< 1 周)→ TwitterAPI.io(5 分钟拿 Key);可以等 1-2 周审核 → 官方 API 也行(走 OAuth + 项目审核)。
维度 3:业务边界。需要 Twitter Ads partner 资质 / 媒体合作背书 → 官方 Enterprise;只要数据 + 自动化 → TwitterAPI.io。
维度 4:成本预算。明确告诉财务月度预算 $X,反推可承受用量上限。X = 200 → 官方 Basic 只能用 200 万次内;X = 200 → TwitterAPI.io 可用 133 万次但没月度上限(下个月想扩到 500 万次 = 充值 $750 即可,官方 API 这个月就锁死)。TwitterAPI.io 在弹性上有结构性优势。
成本控制 — 把 API 预算从 $1000/月降到 $200/月的 5 个技巧
某舆情监控项目在 TwitterAPI.io 上原本月度 $1000+,应用以下 5 个技巧后降到 $180-$220/月,数据覆盖度反而提升:
技巧 1:Redis 缓存热点查询(TTL 15-30 min)。dashboard 多 widget 重复请求同一个 KOL 的最新推文 → 一次抓 + N 次 cache hit,实测节省 60-80% 重复调用。
技巧 2:用轻量端点。粉丝列表用 /twitter/user/followers_ids(只返 ID 数组)而不是 /twitter/user/followers(返完整 profile),同样数据流量节省 80%。
技巧 3:Webhook 替代 Polling。监控类项目从「每分钟 polling advanced_search」改为「注册 /oapi/tweet_filter/add_rule 规则 + Webhook push」,可省 90%+ 调用(只有真有新推文时才计费)。
技巧 4:Dedup。抓取流程加 dedup 层 — 已抓过且 N 小时内未过期的 user/tweet 不再重抓。实际项目中 dedup 后真实调用量可能只剩 10-20%。
技巧 5:精准 since:until 时间窗。advanced_search 加 since:2026-05-20 until:2026-05-27 时间窗,避免全量重扫。每次只抓增量,长期项目节省 50-90%。
# 月度成本估算器 — 输入业务参数,输出官方 vs TwitterAPI.io 月成本对比
def estimate_monthly_cost(
monthly_calls: int,
write_calls: int = 0, # 发推/点赞/转推/关注总数
):
"""返回 (官方 X API Basic 成本, TwitterAPI.io 成本)"""
# ---- 官方 X API Basic ----
OFFICIAL_FLOOR = 200 # 月费门槛
OFFICIAL_INCLUDED_READ = 2_000_000 # 含 2M Posts/月
OFFICIAL_OVERAGE_READ = 0.005 # 超出每次 $0.005
OFFICIAL_MONTHLY_CAP = 2_000_000 # 月度硬上限,超出不可购买
if monthly_calls > OFFICIAL_MONTHLY_CAP:
official = "超出月度硬上限,Basic 不可用 → 必须 Enterprise $42,000+"
elif monthly_calls <= OFFICIAL_INCLUDED_READ:
official = OFFICIAL_FLOOR # 月费内
else:
overage = (monthly_calls - OFFICIAL_INCLUDED_READ) * OFFICIAL_OVERAGE_READ
official = OFFICIAL_FLOOR + overage
# ---- TwitterAPI.io ----
TWITTERAPI_RATE = 0.00015 # $0.15 / 1,000 calls
twitterapi = (monthly_calls + write_calls) * TWITTERAPI_RATE
return official, twitterapi
# 几个真实场景
scenarios = [
("个人 PoC", 10_000, 0),
("小品牌舆情", 100_000, 100),
("中型 SaaS", 500_000, 1_000),
("中大型监控", 2_000_000, 5_000),
("大型加密情报", 5_000_000, 0),
]
print(f"{'场景':<15} {'调用量':>12} {'官方':>20} {'TwitterAPI.io':>15} {'节省':>12}")
print("-" * 80)
for name, reads, writes in scenarios:
official, twitterapi = estimate_monthly_cost(reads, writes)
if isinstance(official, str):
savings = "无法对比"
official_str = official
else:
savings = f"${official - twitterapi:,.0f}"
official_str = f"${official:,.0f}"
print(f"{name:<15} {reads:>12,} {official_str:>20} {f'${twitterapi:>10,.0f}':>15} {savings:>12}")常见问题
官方 X API 月费 $200 / $5,000 真的不能砍价吗?
Basic($200/月)和 Pro($5,000/月)都是 self-serve 价目,固定不议价。Enterprise 层($42,000+/月)是 contact-sales 模式,合同价可以谈,但起步价仍很高。如果业务规模刚好卡在 Basic-Pro 中间 + 月度调用 100-200 万次,目前没办法砍 Basic 月费,只能换第三方 SaaS。
TwitterAPI.io $0.00015 / 次价格会涨吗?
公开定价页面长期稳定在这个量级(2026 年 5 月数据)。SaaS 服务调价通常会提前通知 + 老客户有优惠 grace 期。对照官方 X API 在 2026 年 2 月那次混合计费切换属于结构性变化(增加月度硬上限),TwitterAPI.io 的按次模型本身没有 tier 切换风险,只可能在单价上微调。建议接入时跟商务确认大客户 volume discount 政策。
2,000,000 月度硬上限对我影响大吗?
看你预估的月度调用量。如果项目稳定在 100 万次以内 → 影响为 0,Basic 完全够用,选谁都行。如果有可能涨到 200-500 万次 → 影响巨大,Basic 撞顶后只能 Enterprise $42,000+/月,TwitterAPI.io 仍是线性按次。建议任何成长期项目从一开始就用 TwitterAPI.io 避免后期被锁死,或者至少做好两套接入备份,撞顶时无缝切第三方。
Enterprise $42,000+ 真的有人在用吗?
有,但人群很窄。主要是大型舆情监控 SaaS(给政府 / 大企业卖订阅那种)、媒体合作伙伴(NYT / WaPo 等)、广告平台(需要 Ads API)、加密交易所(需要 Filtered Stream 秒级行情)。这些项目的业务模型本身就能支撑数十万美元年度 API 预算。普通中小项目几乎不会触碰 Enterprise,因为成本完全不合理。
新账号能跑多大规模看真实成本?
TwitterAPI.io 新账号默认 $1 试用额度(不需要绑卡),可调约 6,000 次基础接口。够你跑一周的 PoC + 试一下批量抓取效率 + 验证接口稳定性。试用够用后充值,没有最低充值门槛,$10 起即可。如果想精确试一个特定规模,文章里 §代码块的成本估算器可以输入预估调用量算出准确月成本。
省钱技巧里 Webhook 替代 Polling 实际能省多少?
一个真实例子:某舆情项目原来每分钟 polling advanced_search query=brand1 OR brand2 OR brand3,即使没有新推文也要付费。月度调用 = 60 × 24 × 30 = 43,200 次/月仅用于 keep-polling。改用 /oapi/tweet_filter/add_rule 注册规则 + Webhook 后,只有真有匹配推文才被 push 计费,实测节省 92%(43,200 → 3,500/月,因为该 brand 实际每天大约 100 条新推文)。对 polling-heavy 项目这是最显著的优化。
我们项目混合用读+写,价格怎么算?
TwitterAPI.io 上读 + 写在同一量级单价(具体看 docs.twitterapi.io 公开定价)。混合用法直接累加:读 100 万次 + 写 5 万次 ≈ ($100 + $7.5) ≈ $107.5。官方 X API 上读 / 写 / DM 用资源单价分别计费($0.005 / $0.010 / $0.001 / $0.015 / $0.200 见 §1),但仍受 2M Posts 月度硬上限制约,所以再多写入也帮不了你绕过上限。本质上官方 API 的混合计费在 2M 之后无法继续线性扩展,这是结构性瓶颈。
可以同时用官方 + TwitterAPI.io 做容灾吗?
可以,而且这是中大型项目的常见架构。主源 TwitterAPI.io + 容灾源官方 Basic(月费 $200 当保险):平时所有调用走 TwitterAPI.io(成本可控),官方 Basic 月费照付但不调用;如果 TwitterAPI.io 出现单源故障(网络 / DDoS / 服务商问题),应用自动 failover 到官方 API,牺牲数据完整性保住可用性。一个月 $200 保险费换 99.99% 可用性,对生产业务划算。
继续阅读
- /pricing
- /tools/twitter-rate-limit-calculator
- /zh-CN/blog/twitter-data-scraping-api
- /zh-CN/blog/twitter-api-jiekou
- /blog/twitter-api-pricing