對比選型 June 13, 2026

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。輪詢頻率會獨立於實際訊息量,將讀取成本再放大一層。

用量低嘅話,呢啲都唔算咩——今年早啲嘅幾篇定價分析都提到,輕度使用每月得幾蚊美金。但呢係一種同「我哋每月交固定費用,之後就唔用再諗」完全唔同嘅成本模式。客戶訊息量嘅每一次波動——一次產品發布、一條突然爆紅嘅@提及、一波客服積壓——而家都會按訊息、按回覆、按輪詢次數,直接反映喺帳單上面。

換個角度睇:接收一條訊息,本來就唔應該需要「叫 API」

容易被忽略嘅一點係:上面呢套成本結構,係X 官方 API嘅特性,唔係「喺 X 上面收到一條訊息」呢件事本身嘅特性。如果你真正嘅需求係「有人私訊或者@我哋嘅帳號嗰陣,後端可以即刻知道,並且可以回覆」——呢個需求本身唔一定要你為每一次讀取、每一次寫入向 X 付錢。

呢正正就係 UnifyPort 為 X 提供嘅非官方入站介面所填補嘅空缺。後端唔需要輪詢 X 嘅 API(亦即係唔需要為每次讀取付錢),UnifyPort 直接連接去 X 帳號,有入站動態嗰陣即時推送去你嘅 webhook——唔計讀取次數、唔需要輪詢迴圈、平台側都唔會產生按訊息計費嘅費用。

實際點樣接入

將 X 帳號接入 UnifyPort,用嘅係同 UnifyPort Exporter 擴充功能文件入面一致嘅 session 接入流程:建立一個 provider: "twitter"、auth_mode: "session" 嘅帳號記錄,匯出你已經登入嗰個帳號嘅 session,然後啟動 runtime。

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 事件,同一個回覆介面,冇額外嘅計量層。