X 在 2026 年封鎖自動私訊——只負責接收的客服團隊如何照常收發訊息 — UnifyPort

如果你在 X 上做客服或社群經營，平台 2026 年的規則調整大概已經帶著一個讓人心頭一緊的標題，躺進了你的收件匣。自動私訊——也就是有人追蹤你時自動彈出的那則「感謝追蹤，看看我的產品」——現在被明確禁止。透過自動化大量發送的私訊、對陌生用戶的冷啟動私訊，全都不允許。任何把私訊介面用於行銷目的的程式化呼叫，都可能直接導致 API 權限被收回。再疊加上 2026 年 2 月切換到的按量計費——讀取一則私訊就是一次計費請求——對一個小團隊來說，結論很直白：在 X 上做外發自動化，現在既受限制又要花錢。

但有一點在恐慌中被忽略了。如果你的團隊是用 X 來接收訊息的——訂單詢問、客服工單、需要人工回覆的提及——那麼 2026 年這波整頓幾乎沒有一條是衝著你來的。新規針對的是一種非常具體的行為：未經許可、自動化、大規模的外發私訊。而接收別人主動發給你的訊息、並盡快交到人工手上，是另一個完全不同的問題，答案也不一樣。

到底改了什麼

把新規說精確很重要，因為「X 嚴打私訊自動化」這個標題，比規則本身寬泛得多。

被禁止的行為本質上都是未經許可的外發：追蹤觸發的自動私訊、大量私訊行銷、對從沒先聯絡過你的人的冷啟動私訊，以及任何為行銷而自動發出的私訊。X 同時收緊了資料處理的表述——服務在儲存非公開私訊內容前必須取得明確、知情的同意，也不得把私訊內容暴露給無權查看的人。

定價方面，免費 API 等級在 2026 年 2 月對新開發者關閉，其餘人轉為按量計費。開放之後費率幾經調整，但結構才是關鍵：每一次讀取都是一次請求，每一次請求都有價。對於靠輪詢監控私訊的團隊——每 30 秒呼叫一次介面看有沒有新訊息——這意味著一塊持續運轉的電表，無論這段時間進來了十則訊息還是一則都沒有。

所以對一個入站團隊而言，官方路徑如今帶著兩筆互不相干的成本：合規成本（高頻程式化存取會在自動化新規下受到審查）與計費成本（每次輪詢都要付費）。而這兩筆成本，都跟你的客戶實際發來的訊息毫無關係。

為什麼「接收」是另一個問題

重新看清楚你的客服團隊到底在做什麼。客戶發來一則私訊問問題，一個人讀到它、打字回覆、發出去。這則外發訊息沒有任何「自動化」成分——是人寫的——所以自動私訊禁令根本不適用。你真正需要自動化的，只是把進來的訊息夠快地送到團隊手上，快到能在 SLA 內回覆。

這是一個入站路由問題，不是外發自動化問題。而最乾淨的解法恰恰和輪詢相反：不是讓你的服務反覆去問 X「有新訊息了嗎？」，而是訊息一到就被推送給你。沒有輪詢迴圈，就沒有持續運轉的讀取電表，也沒有讓自動化新規盯上的高頻存取模式。你接收別人發給你的東西，人工回覆，從頭到尾不會主動發出一則未經許可的私訊。

用一個 Webhook 接收 X 的私訊與提及

UnifyPort 接入你的 X 帳號，把入站私訊與提及在發生的瞬間推送到你自己的 Webhook 端點。你只需註冊一次端點、訂閱你關心的事件，入站活動就會以正規化的 message.received 事件抵達——這和 WhatsApp、Telegram、LINE、TikTok、Zalo 是同一套結構，於是一個多通路客服台只讀一套 schema，而不必應付六種平台格式。

建立 Webhook 時，你列出 subscribed_events（用 ["*"] 訂閱全部，或明確寫出 message.received 與 account.status.updated），並設定一個 signing_secret。此後每一次投遞都會帶上 HMAC-SHA256 簽章，你的處理器在信任請求內文之前先驗章。一則投遞過來的私訊長這樣：

{
  "event": "message.received",
  "data": {
    "account_id": "acct_x_support",
    "provider": "twitter",
    "chat_id": "dm_8841f0",
    "sender": "user_3a91c7",
    "message": {
      "id": "x_msg_5f2a91",
      "type": "text",
      "text": "你好——我的訂單出貨了嗎？物流連結打不開",
      "reply_token": "rt_9b1c7e..."
    },
    "timestamp": 1750939200
  }
}

你的接收端先驗章，再把訊息路由到團隊分流的地方——一個 Slack 頻道、一個工單系統、一個資料庫：

const crypto = require("crypto");

app.post("/webhook", express.raw({ type: "application/json" }), (req, res) => {
  const signature = req.get("X-UnifyPort-Signature");
  const expected = crypto
    .createHmac("sha256", process.env.SIGNING_SECRET)
    .update(req.body)
    .digest("hex");
  if (signature !== expected) return res.sendStatus(401);

  const { event, data } = JSON.parse(req.body);
  if (event === "message.received" && data.provider === "twitter") {
    routeToTriage({
      chatId: data.chat_id,
      from: data.sender,
      text: data.message.text,
      messageId: data.message.id,
    });
  }
  res.sendStatus(200);
});

注意這個處理器不做什麼：它從不發私訊。它只接收、驗章、路由。當你的客服寫好回覆，回覆會透過 UnifyPort 的正規化發送介面以「人工撰寫」的形式發出——不是自動私訊，不是大量行銷。（一個 X 特有的小提醒：引用回覆用的 reply_to.reply_token 欄位目前僅 WhatsApp 支援，所以在 X 上你發的是一般回覆而非引用回覆；入站事件依然會帶上這個 token，供支援它的平台使用。）

因為事件是推送的、漏掉的事件也不靠輪詢補回，你的團隊會在訊息發出後數秒內看到入站活動——通常比 30 秒的輪詢週期更快，而且在沒人來的安靜日子裡，讀取電表不會在背景空轉。

落地的下一步

2026 年的新規劃了一條清晰的線：X 不希望自動外發的私訊淹沒用戶的收件匣，並且現在對程式化讀取收費。一個入站客服團隊完全站在這條線正確的一側——每一則回覆都是人寫的，根本沒有理由去輪詢介面。如果你現在為了知道「客戶什麼時候發來訊息」而對著 X 跑一個輪詢服務，那麼換成基於推送的 Webhook，一步就同時消除了合規風險與計費讀取。

把你的 X 帳號接到一個統一入站 Webhook，指向一個會驗章並按 chat_id 路由的端點，讓你的團隊回到那件新規從未限制過的事上：回答那些來找他們的人。