← 所有文章
對比選型

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" 的帳號記錄,匯出你已登入帳號的會話,然後啟動執行階段。

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