← 所有文章
对比选型

X 平台 2026 年 API 定价大改：按量付费对接收私信和@提及意味着什么 — UnifyPort

如果你今年第一次注册 X 的开发者 API,会撞上一个 2025 年还不存在的门槛:没有免费额度了。X 在 2026 年 2 月把开发者 API 改成了按量付费模式,取代了原来 0 到 5000 美元/月不等的固定套餐。新开发者必须先充值才能调用任何一个接口——再也没有”先免费试用几次”的选项了。

对于只想接收 X 账号的私信和@提及的团队来说——也就是入站这一侧,不是发推或做数据分析——这把决策的性质彻底改变了。以前是”哪个固定套餐够用”,现在变成”我们收到的每一条消息,都会变成一笔持续产生的账单”。

具体改了什么,而且改了两次

2026 年 2 月的这次大改定下了基线:按次计费,读和写分开定价,没有用量上限——调用多少就按多少收费。然后在 4 月 20 日,X 又发布了一次未提前预告的费率调整。读取自己账号的数据——自己账号的推文、粉丝、私信——单价大幅下降到每次 0.001 美元,比最初按量付费的价格降了 5 倍。同时,标准的写请求价格从每次 0.010 美元涨到了 0.015 美元。

对于一条接收私信/@提及的入站链路来说,这意味着同时跑着两个计费器:

  • 读取入站私信和@提及——4 月调整后,每次读取自有资源的价格相对便宜,只要 0.001 美元
  • 发送回复——属于写请求,现在每次 0.015 美元

0.001 美元这个数字听起来很小,但放到一个真正做客服的团队的日常里算一算就不一样了。一个每天处理几百条私信和@提及的小团队,每一条需要回复的消息,都是一笔读费用加一笔写费用——而且这还没算上轮询的开销,因为 X 的 API 接收私信本质上还是”主动去查有没有新动态”,而不是平台主动推送的 webhook。轮询的频率会独立于真实消息量,把读取成本再放大一层。

低用量的情况下,这一切都不算什么——今年早些时候的几篇定价分析也提到,轻度使用每月只要几美元。但这是一种和”我们每月付固定的 X 美元,然后不用再操心”完全不同的成本模型。客户消息量的每一次波动——一次产品发布、一条意外爆火的@提及、一波客服积压——现在都会按消息、按回复、按轮询次数,直接体现在账单上。

换个角度看:接收一条消息,本不该需要”调用 API”

容易被忽略的一点是:上面这套成本结构,是X 官方 API的属性,不是”在 X 上收到一条消息”这件事本身的属性。如果你真正的需求是”有人私信或@我们的账号时,后端能立刻知道,并且能回复”——这个需求本身并不必然要求你为每一次读取、每一次写入向 X 付费。

这正是 UnifyPort 为 X 提供的非官方入站接口所填补的空白。后端不需要轮询 X 的 API(也就不需要为每次读取付费),UnifyPort 直接连接到 X 账号,有入站动态时实时推送到你的 webhook——不计读次数、不需要轮询循环、平台侧不产生按消息计费的费用。

实际接入方式

将 X 账号接入 UnifyPort,使用的是和 UnifyPort Exporter 插件文档里一致的会话(session)接入流程:创建一个 provider: "twitter"、auth_mode: "session" 的账号记录,导出你已登录账号的会话,然后启动运行时。

POST /v1/accounts
Content-Type: application/json

{
  "provider": "twitter",
  "auth_mode": "session"
}

之后,这个账号收到的每一条私信和@提及,都会以 message.received 事件推送到你的 webhook——和 WhatsApp、Telegram、LINE、TikTok、Zalo 共用同一种归一化格式:

{
  "event": "message.received",
  "account_id": "acct_8Q2vK",
  "provider": "twitter",
  "from": "user_3f9c1a",
  "text": "Hey, do you ship to the EU?",
  "timestamp": 1749427200,
  "message_id": "x_msg_7c1f9d"
}

回复同样调用 POST /v1/messages,通过 account_id 和 from 定位收件人——和其他渠道完全一样。不需要先”读取”私信再处理,事件本身已经包含了你需要的全部信息,也没有任何按消息量或按查询频率计费的环节。

X (Twitter) ──► UnifyPort ──► message.received ──► 你的 webhook
                    ▲                                    │
                    │                                    ▼
              POST /v1/messages ◄──────────── 你的回复逻辑

每次投递都用你配置的 signing_secret 做 HMAC-SHA256 签名,验签逻辑和你接入的其他渠道是同一套代码。

实际意味着什么

如果你的 X 用量本来就很轻——每周几条私信,没有其他自动化——4 月调整后的 0.001 美元读费率已经足够便宜,官方 API 完全够用,单独再接一条链路并不值得。

但如果 X 是你的团队监控的多个入站渠道之一,尤其是用量不可预测——一次刷屏的帖子、一波客服高峰、一次产品发布——按次计费的读+写模型会把”我们获得了更多关注”直接变成”账单变多了”,这个激励方向是反的。通过 UnifyPort 的统一 webhook 接入 X,可以让它和你其他渠道一样,处在同一种统一、不计量的基础上——同一个 message.received 事件,同一个回复接口,没有额外的计量层。