兩人團隊點樣喺唔使畀 X 逐次讀取費嘅情況下監控四個客戶帳號嘅私訊同提及 — UnifyPort

2026 年 1 月，里斯本一間兩人社交媒體代理公司同時管理緊四個客戶嘅 X（Twitter）帳號——兩個電商品牌、一間 SaaS 初創公司同一間本地連鎖餐廳。工作內容好簡單：監控每個帳號嘅私訊同提及，幾個鐘頭內回覆，需要客戶本人處理嘅嘢就升級轉發。技術方案都好簡單：一個 Node.js 服務每 30 秒輪詢一次每個帳號嘅 X API，檢查新訊息，然後將訊息路由到一個共用嘅 Slack 頻道做分類。

喺 X 嘅舊定價體系下——由 2023 年沿用至今嘅固定月費方案——呢套架構每月花費 100 美元嘅 Basic 方案。可預測、易做預算，客戶按月畀嘅代理費輕鬆涵蓋，根本唔使單獨解釋。

然後二月嚟咗。

計費錶開始跳字

2026 年 2 月 3 日，X 將固定方案定價換成咗按次收費。每次 API 呼叫——讀取同寫入都計——都有咗單獨嘅價格標籤。唔再有月度上限。團隊嗰套為「方案內呼叫無限」設計嘅輪詢架構，一夜之間開始持續跑錶。

數字即刻擺喺面前。四個客戶帳號，每個每 30 秒輪詢一次私訊同提及。每分鐘 8 次讀取（每帳號 2 個端點 × 4 個帳號），每日 11,520 次，每月大約 345,600 次——呢個只係監控嘅成本，一條訊息都未收到。

4 月 20 日 X 調整咗費率，自有資源讀取降到每次 $0.001——月度監控讀取成本降到大約 346 美元。但同一次調整將寫入請求（回覆）由 $0.010 加到 $0.015。團隊每月跨四個帳號大約發送 400–600 條回覆；按 $0.015 計，增加咗 $6–$9。單獨睇唔算多，但趨勢令人不安：每多接一個客戶帳號就多一個輪詢循環，每多一條回覆就喺兩頭推高帳單。

真正貴嘅唔係費率，係架構

團隊創辦人計咗一筆 Q3 嘅數：如果再接兩個客戶（按現有管線完全合理），淨係輪詢讀取就要翻倍。單次費率確實低，但呼叫量係結構性嘅——由服務檢查新訊息嘅頻率決定，而唔係實際收到幾多條訊息。星期日一條私訊都冇嘅時候，輪詢循環照樣全速運轉，成本同產品上線嗰日一模一樣。

呢個就係 X 按次收費模型入面啲定價比較文章唔會話你聽嘅部分：等待訊息嘅成本唔係零，而且佢隨你嘅監控架構擴展，唔係隨你嘅實際訊息量擴展。四個帳號每 30 秒輪詢一次，無論收到 10 條訊息定 10,000 條，都係每月 345,600 次讀取。

降低輪詢頻率係最直覺嘅做法。團隊試咗一個禮拜 2 分鐘一次嘅間隔。回應時間明顯下降——一條私訊最壞情況下可能 4 分鐘先被讀到，而其中兩個客戶合約入面寫明咗「2 小時內回應」嘅 SLA。延遲冇違反 SLA，但服務體感由「接近即時」變成咗「最終會睇到」。三日之後佢哋就改返嚟。

由拉取切換到推送

正確嘅做法唔係優化輪詢頻率——而係消滅輪詢。團隊將四個客戶嘅 X 帳號全部接入咗 UnifyPort，私訊同提及喺到達時直接推送到 webhook。冇輪詢循環，冇按次讀取收費，冇隨檢查頻率增長嘅成本。

架構變化如下：

之前（輪詢）：
  服務 ──► X API（讀私訊）    ×4 帳號  ×2次/分鐘  = 345,600 次讀取/月
  服務 ──► X API（讀提及）    ×4 帳號  ×2次/分鐘  = 345,600 次讀取/月
  合計：~691,200 次計費 API 讀取/月

之後（webhook 推送）：
  X 帳號 ──► UnifyPort ──► POST /webhook ──► Slack（客戶 A）
  X 帳號 ──► UnifyPort ──► POST /webhook ──► Slack（客戶 B）
  X 帳號 ──► UnifyPort ──► POST /webhook ──► Slack（客戶 C）
  X 帳號 ──► UnifyPort ──► POST /webhook ──► Slack（客戶 D）
  合計：0 次 X API 讀取

每個帳號嘅入站訊息以 message.received 事件嘅形式送達——同呢個團隊日後為同一批客戶接入 WhatsApp 或 Telegram 時會收到嘅格式完全一致：

{
  "event": "message.received",
  "account_id": "acct_client_a",
  "provider": "twitter",
  "from": "user_7d2e1f",
  "text": "Hey, is the summer sale still on? Saw a post but the link was broken",
  "timestamp": 1750320000,
  "message_id": "x_msg_8a3b2c"
}

webhook 處理函式用 HMAC-SHA256 驗證每次投遞嘅簽章，然後根據 account_id 路由到對應客戶嘅 Slack 頻道：

app.post("/webhook", (req, res) => {
  if (!verifySignature(req)) return res.sendStatus(401);

  const evt = req.body;
  if (evt.event === "message.received") {
    const channel = clientChannelMap[evt.account_id];
    slack.postMessage(channel, {
      text: `[${evt.provider}] ${evt.from}: ${evt.text}`,
      metadata: { messageId: evt.message_id },
    });
  }
  res.sendStatus(200);
});

四個帳號，一個端點，一個簽章金鑰。輪詢服務直接關停。

變咗乜

團隊喺 X 上嘅 API 成本由每月大約 350 美元（而且隨客戶增長）降到零計費讀取。回應延遲反而改善咗——事件喺訊息發出後幾秒內送達，唔使再等下一個輪詢週期。接入新客戶帳號都唔再意味住往帳單入面加一個輪詢循環，而只係喺 clientChannelMap 入面多加一行。

呢個兩人團隊回覆 X 私訊同提及嘅方式冇變——仲係由 Slack 出發，透過 UnifyPort 嘅回覆端點路由返去。變嘅係「監控四個 X 帳號」唔再係一項需要建模、需要向客戶解釋、需要擔心擴展性嘅 API 成本。Q3 如果管線入面再嚟兩個帳號，webhook 由收四個變成收六個，帳單睇唔出分別。

對於管理多個 X 帳號嘅代理團隊——尤其係嗰啲 X API 成本隨輪詢頻率而非訊息量增長嘅團隊——真正嘅架構問題唔係「輪詢間隔調到幾多最抵」，而係當一個推送式 webhook 可以喺唔跑錶嘅情況下送達同樣嘅訊息時，拉取模式本身係咪仲有必要。