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 路由嘅端點，等你嘅團隊返去做嗰件新規從來冇限制過嘅事：回答嗰啲嚟搵佢哋嘅人。