X(推特)API 价格完整对比 — 官方按量付费 vs 按次计费 SaaS
X(原 Twitter)API 的价格模型在 2026 年有过一次重大变化 — 过去按月订阅的固定档位已不再销售,官方 X API 现在是 按量付费、无订阅:按读取的资源计费(读取帖子每条 $0.005),每个月度账单周期最多读取 3,000,000 条帖子,超出需通过申请表单走 Enterprise(无公开价格)。成本因此与用量严格线性:读取 100 万条帖子就是 $5,000。
本文以 docs.x.com 公开的计费数据(2026 年)为准,把官方 X API 的按量付费 + Enterprise,与第三方 SaaS(TwitterAPI.io 按次计费)做完整成本拆解。重点是真实用量档下的对比 — 看「每千次推文请求实际花多少」+「不同业务规模下哪个方案更经济」+「300 万月度上限对大中型项目的影响」。
适用读者:正在做 Twitter 数据 API 商业决策的工程负责人 / 创始人;评估官方 vs 第三方 API 的产品经理;为出海舆情 / 加密项目 / 跨境营销 / AI 训练等业务采购 API 服务的采购方。不适用:只是好奇的技术爱好者(可以看 §1 概览即可)。
X API 2026 年按量付费概览
官方 X API 过去按月订阅固定档位;现在改为 按量付费、无订阅 的模型(docs.x.com):
- 按资源计费:每读取一条帖子、一个用户、一条私信事件,或每发一条帖子,单独计费,没有月费起步
- 月度上限:按量付费每个月度账单周期最多读取 3,000,000 条帖子;超出后需通过申请表单走 Enterprise(无公开价格)
- 新账号赠送:首次绑定符合条件的支付卡赠送 $20 额度,首次自动充值再按金额匹配赠送,最高 $50
300 万月度上限是这个模型最关键的约束。按 $0.005/条计算,读满 300 万条就是 $15,000/月;月度读取稳定在 300 万条以上的项目,只能走 Enterprise 或者放弃官方 API。
资源单价:
- Posts read: $0.005 / 次
- User read / DM event read / Followers·Following read: $0.010 / 个
- Owned reads(自己账号的数据): $0.001 / 次
- Post creation: $0.015 / 次
- URL Post creation: $0.200 / 次
TwitterAPI.io 计费模型
TwitterAPI.io 是面向全球开发者的 SaaS 数据 API 服务,定价逻辑跟官方完全不同:
- 按返回推文数线性计费:每条推文 15 积分 = $0.00015(约 $0.15 / 1,000 条);每次请求最低 15 积分($0.00015,即空结果的费用),没有单次封顶,满页 20 条 = $0.003
- 没有月费起步(新账号通过自动人机校验后获赠 $1 免费试用额度,每人 / 每个网络限一次,不需要绑卡,31 天内有效)
- 没有月度硬上限(余额够扣就一直能调,没有 300 万限制)
- 写入操作同样按次计费,价格跟读取在同一量级(具体见 docs.twitterapi.io 定价页)
- 没有 tier 概念,所有用户用同一套定价 + 同一套约 75 个端点(写入端点中 DM 发送不开放,产品策略保护账号安全)
计费公式极简:月度成本 ≈ 月度读取推文数 × $0.00015。100 万条 = $150,500 万条 = $750,1000 万条 = $1,500。线性可预测,没有 tier 切换的成本断崖。
5 个真实用量档下的成本对比
下面这张表给 5 个常见用量档下两个方案的月度实际成本。所有数字基于 2026 年公开定价。
关键观察:
- 10K-2M 用量档:官方按 $0.005/条线性计费,TwitterAPI.io $0.00015/条,每档都便宜约 97%(约 33×)
- 300 万条是官方按量付费的天花板:读满即 $15,000/月,再往上只能 Enterprise
- 5M+ 用量档:官方超出按量付费上限,只能 Enterprise(无公开价格),TwitterAPI.io 仍是线性 $750
中型以上项目几乎不可能选官方,除非业务上必须用官方接口(例如需要 Twitter Ads partner 资质)。
300 万月度上限对哪些业务影响最大
300 万月上限卡在「大中型项目」这个区间,这恰好是大量出海 SaaS / 跨境品牌 / 加密项目的实际用量段 — 而且在撞到上限之前成本已经很高:读满 300 万条就是 $15,000/月。
重灾区一:实时舆情监控。监控 50-200 个 keyword + 全平台公开数据,每个 keyword 每天可能产生数百-数千条新推文。50 keyword × 1,000 条/天 × 30 天 = 150 万次/月,还在上限内,但官方成本已是 150 万 × $0.005 = $7,500/月。涨到 100 keyword(300 万次/月)正好顶到上限。
重灾区二:KOL 矩阵跟踪。跟踪 500-2,000 个 KOL 的最新推文 + 互动数据。500 KOL × 每天 polling 3 次 last_tweets × 30 天 = 45,000 次/月(读 timeline 用得不多),但加上每条推文 fetch 回复 + retweeters 后,实际可能 500 KOL × 平均 3 推文/天 × 50 互动 fetch × 30 天 = 225 万次/月,在上限内但已接近,官方成本约 $11,250/月。
重灾区三:AI 训练数据持续采集。每天采集 N 万条公开中文推文做 NLP 训练。10 万条/天 × 30 天 = 300 万次/月,正好顶到上限($15,000/月),再多就要 Enterprise。这类业务在官方按量付费上几乎不可行,只能走第三方或 Enterprise。
安全区(上限内):个人开发者 PoC、单品牌出海舆情(月度 < 80 万次)、小型加密项目情报(月度 < 100 万次)。这类业务在官方按量付费上可以运行,但成本按 $0.005/条线性增长:80 万次约 $4,000/月,100 万次约 $5,000/月。
Enterprise 值不值得
Enterprise 是给真正需要官方品牌背书 + 高级能力,或月度读取超过 300 万条帖子的项目。X 不公开 Enterprise 价格,需要通过申请表单联系。来看 Enterprise 实际提供的能力:
只在 Enterprise 才开放的能力:Filtered Stream(实时高频推送,每秒级)、Ads API(广告投放数据)、Spaces 录制 API、Premium analytics、官方合作伙伴标识。这些对广告平台 / 媒体合作伙伴 / 大型监控 SaaS 是刚需,对普通业务用不到。
Enterprise 不解决的问题:写入操作风控仍然严格(API 发 DM 仍易封号)。Enterprise 主要是「能力和额度扩张」不是「成本降低」。
TwitterAPI.io 是否能替代 Enterprise:对纯数据采集类业务可以(Webhook + WebSocket 提供秒级实时推送,Trends 端点可用,advanced search 完整)。对需要官方合作伙伴资质的业务(例如 Twitter Ads partner、官方媒体合作)不行 — 这是商业合作问题不是技术 API 问题,只能官方 Enterprise。
决策树:
- 需要官方合作伙伴资质 → Enterprise,无替代
- 需要 Filtered Stream / Ads API / Spaces 录制 → Enterprise
- 只要数据(读 + 常用写入)+ 实时推送 + Trends → TwitterAPI.io 完全够用,成本约为官方按量付费的 1/33
实际选型的 4 个判断维度
选 API 的核心 4 个维度:
维度 1:月度调用量预估。先做粗略估算 — 多少 keyword × 多少推文/天 × 多少次 fetch + 多少 KOL × 多少次 polling/天 + 多少互动 fetch + 多少 webhook push。算出来在 10 万次以内 → 任何方案都行(官方约 $500/月以内);10 万-300 万次 → 强烈倾向 TwitterAPI.io;300 万次以上 → 官方只能 Enterprise,必走 TwitterAPI.io 或类似第三方。
维度 2:接入时间预算。需要立即起步 → TwitterAPI.io(Google 登录,5 分钟拿 Key);能接受注册 X 开发者账号并绑定支付卡 → 官方 API 也行(走 OAuth)。
维度 3:业务边界。需要 Twitter Ads partner 资质 / 媒体合作背书 → 官方 Enterprise;只要数据 + 自动化 → TwitterAPI.io。
维度 4:成本预算。明确告诉财务月度预算 $X,反推可承受用量上限。X = 200 → 官方按量付费可读 4 万条帖子($200 / $0.005);X = 200 → TwitterAPI.io 可读 133 万条推文,且没有月度上限(下个月想扩到 500 万次 = 充值 $750 即可,官方按量付费超过 300 万条就必须走 Enterprise)。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:YYYY-MM-DD until:YYYY-MM-DD 时间窗,避免全量重扫。每次只抓增量,长期项目节省 50-90%。
# 月度成本估算器 — 输入业务参数,输出官方 vs TwitterAPI.io 月成本对比
def estimate_monthly_cost(
monthly_calls: int,
write_calls: int = 0, # 发推/点赞/转推/关注总数
):
"""返回 (官方 X API 按量付费成本, TwitterAPI.io 成本)"""
# ---- 官方 X API 按量付费(无订阅)----
OFFICIAL_READ = 0.005 # 每条帖子读取 $0.005
OFFICIAL_WRITE = 0.015 # 每条发帖 $0.015(含链接 $0.200),写入按发帖单价粗估
OFFICIAL_MONTHLY_CAP = 3_000_000 # 按量付费每月最多 300 万条帖子读取
if monthly_calls > OFFICIAL_MONTHLY_CAP:
official = "超出 300 万按量付费上限 → 需 Enterprise(无公开价格)"
else:
official = monthly_calls * OFFICIAL_READ + write_calls * OFFICIAL_WRITE
# ---- TwitterAPI.io ----
TWITTERAPI_RATE = 0.00015 # 每条推文 $0.00015 = $0.15 / 1,000 条
# 写入单价以定价页为准,这里按同一量级粗估
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 的价格能砍价吗?
按量付费是 self-serve 公开单价(读取帖子 $0.005/条、读取用户 $0.010/个),没有订阅,不议价。月度读取超过 300 万条帖子需要 Enterprise,通过申请表单联系,价格不公开,合同可以谈。如果业务月度调用在 100-200 万次,官方按量付费约 $5,000-10,000/月,想降低成本只能换第三方 SaaS。
TwitterAPI.io $0.00015 / 条的价格会涨吗?
公开定价页面长期稳定在这个量级(2026 年数据)。SaaS 服务调价通常会提前通知 + 老客户有优惠 grace 期。对照官方 X API 2026 年从固定月费档位改为按量付费属于结构性变化,TwitterAPI.io 的按次模型本身没有 tier 切换风险,只可能在单价上微调。建议接入时跟商务确认大客户 volume discount 政策。
300 万月度上限对我影响大吗?
看你预估的月度调用量。如果项目稳定在 100 万次以内 → 不会撞上限,但官方成本已达 $5,000/月(100 万 × $0.005)。如果有可能涨到 300-500 万次 → 影响巨大,超过 300 万条后官方只能走 Enterprise(无公开价格),TwitterAPI.io 仍是线性按次。建议任何成长期项目从一开始就用 TwitterAPI.io 避免后期被锁死,或者至少做好两套接入备份,撞顶时无缝切第三方。
官方 Enterprise 真的有人在用吗?
有,但人群很窄。主要是大型舆情监控 SaaS(给政府 / 大企业卖订阅那种)、媒体合作伙伴(NYT / WaPo 等)、广告平台(需要 Ads API)、加密交易所(需要 Filtered Stream 秒级行情)。这些项目的业务模型本身就能支撑高额的年度 API 预算。普通中小项目几乎不会触碰 Enterprise,因为成本完全不合理。
新账号能跑多大规模看真实成本?
TwitterAPI.io 新账号通过自动人机校验后获赠 $1 免费试用额度(每人 / 每个网络限一次,不需要绑卡,31 天内有效)。够你跑通核心接口验证 + 看一下返回数据结构。试用够用后充值,没有最低充值门槛,$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 万条推文 ≈ $150,再加上写 5 万次按定价页写入单价计算的费用。官方 X API 上读 / 写 / DM 用资源单价分别计费($0.005 / $0.010 / $0.001 / $0.015 / $0.200 见 §1),但帖子读取仍受每月 300 万条的按量付费上限制约。本质上官方按量付费在 300 万条之后无法继续线性扩展,只能转 Enterprise,这是结构性瓶颈。
可以同时用官方 + TwitterAPI.io 做容灾吗?
可以,而且这是中大型项目的常见架构。主源 TwitterAPI.io + 容灾源官方按量付费:平时所有调用走 TwitterAPI.io(成本可控),官方 API 只保留开发者账号和已绑定的支付卡,不调用就不产生费用;如果 TwitterAPI.io 出现单源故障(网络 / DDoS / 服务商问题),应用自动 failover 到官方 API,故障期间按 $0.005/条帖子读取付费,牺牲部分成本保住可用性。按量付费没有月费,容灾的固定成本接近零,对生产业务划算。
继续阅读
- /pricing
- /tools/twitter-rate-limit-calculator
- /zh-CN/blog/twitter-data-scraping-api
- /zh-CN/blog/twitter-api-jiekou
- /blog/twitter-api-pricing