兩人團隊如何在不付 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 能在不跑表的情況下送達同樣的訊息時，拉取模式本身是否還有必要。