← 所有文章
個案分析

TikTok Shop 將私訊鎖喺賣家後台——一個三人團隊點樣用 Webhook 接收訊息 — UnifyPort

呢個團隊——三個人喺胡志明市做緊 TikTok Shop 美妝小店——第一次直播帶貨就喺 11 分鐘內賣斷咗一個 SKU。直播高峰期 400 人同時在線，留言區滾得飛快，訂單實時成交。直播完打開賣家後台，140 條私訊等緊佢哋。其中大部分嘅 12 小時回覆計時器，已經行咗兩個鐘。

佢哋知道問題喺邊——唔係人手問題，三個人應付日常查詢綽綽有餘——而係「接入」問題。所有私訊都困喺 TikTok 賣家後台裡面，嗰個介面係設計用嚟手動管理收件箱嘅，完全冇辦法將呢啲訊息推送到團隊已經在用嘅客服工具。佢哋同時用 WhatsApp 同 Zalo 接待客戶，TikTok 呢邊只能靠人盯住兩塊屏幕、手動複製訊息、喺賣家後台逐條回覆。面對 140 條訊息，呢條路走唔通。

問題好清楚：有冇辦法透過 Webhook 程式化咁接收 TikTok 私訊——就好似佢哋而家接收 WhatsApp 訊息咁？佢哋花咗一個下午將所有搵到嘅方案過咗一遍。共有三條路。

方案一：賣家後台手動收件箱

TikTok 賣家後台有個內置嘅訊息分頁。買家發嚟嘅所有私訊都喺度，可以查睇、可以回覆，全部喺 TikTok 介面內搞掂。冇 API，冇 Webhook，冇匯出功能。需要人盯住呢個分頁，將訊息手動複製到 CRM 或表格入面，再喺賣家後台逐條回覆。

日常量少嘅時候仲撐得住——例如每日穩定嚟十幾條查詢。但直播帶貨之後嘅訊息洪峰根本頂唔順：一個客服讀完第一條訊息，佇列裡已經多咗二十條新嘅。而且呢個要求有人專門盯住一個獨立嘅 App，完全脫離團隊其他人在用嘅工具。

結論：低流量勉強夠用；直播爆量期間必然失效。

方案二：TikTok 官方開發者 API 或 Shop Partner API

佢哋喺 TikTok for Developers 後台掃咗一遍。冇私訊接口。TikTok 官方開發者 API 係為內容發布設計嘅——發影片、讀公開數據、管理素材。私訊明確唔喺開放範圍之內；TikTok 官方說明，出於私隱原因，私訊數據唔對第三方整合開放。

仲有一條窄啲嘅路：TikTok Shop Partner API，通過審核嘅賣家可以喺 Shop 場景入面存取部分訊息功能。但需要通過 TikTok 自己嘅合作夥伴審核同開通流程，只對特定市場入面嘅認證賣家開放。佢哋嘅帳號——透過標準 TikTok Shop 賣家註冊流程開設嘅越南小店——唔符合條件。審核流程本身就要幾個禮拜，仲唔保證批准。

結論：通用開發者 API 唔提供私訊存取；Shop Partner 路徑有門檻，大部分帳號拿唔到。

方案三：非官方入站接口

第三條路從完全唔同嘅角度切入 TikTok 私訊。佢唔走開發者 API（嗰個接口本身就唔係為開放私訊設計嘅），而係好似 App 咁喺帳號層面連接 TikTok，將每條進嚟嘅私訊轉成一個 HTTP 事件，推送到你伺服器註冊嘅 Webhook 地址。唔需要合作夥伴審核，冇市場准入門檻，唔用設定開發者後台。用你已有嘅帳號就得。

方案一：賣家後台方案二：官方 API方案三：非官方入站接口
開通時間即時數週（審核），批唔批唔保證1 日內
私訊 API 存取無（只能手動）一般帳號無法存取完整 Webhook
可自動化否否係
頂到直播爆量否—係
所有帳號可用係否係

表格擺出嚟，選擇就清楚咗。方案二行唔通。方案一頂唔住壓力。方案三係唯一真正可用嘅路。

方案三實際係咩樣

團隊透過 UnifyPort 接入咗佢哋嘅 TikTok 帳號，註冊咗一個 Webhook 端點，設定咗 signing_secret。由此之後，每條進嚟嘅 TikTok 私訊都會以標準化嘅 message.received 事件推送到後端：

{
  "event": "message.received",
  "account_id": "acct_tk_9Zp2",
  "provider": "tiktok",
  "from": "user_c14f8b",
  "text": "你好，我昨日直播買咗玫瑰套裝，請問幾時發貨？",
  "timestamp": 1750060800,
  "message_id": "tt_msg_c14f8b"
}

後端用 HMAC-SHA256 對每次推送做簽名驗證，核對 Webhook 端點上設定嘅 signing_secret，驗證通過後將訊息放入佢哋已有嘅工單佇列——同一個佇列，WhatsApp 同 Zalo 嘅訊息都係進呢度：

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

  const evt = req.body;
  if (evt.event === "message.received") {
    supportQueue.add({
      channel: evt.provider,    // "tiktok"、"whatsapp"、"zalo" 等
      customer: evt.from,
      text: evt.text,
      messageId: evt.message_id,
    });
  }
  res.sendStatus(200);
});

provider 欄位話俾路由邏輯知訊息係從哪個渠道嚟嘅。佇列邏輯、CRM 寫入、客服介面——全部唔洗郁，因為 TikTok 嚟嘅 message.received 同 WhatsApp 嚟嘅結構完全一樣。團隊唔係為 TikTok 另起爐灶，而係直接將 TikTok 加入原本嗰套裡面。

變咗咩，冇變咩

下一次直播，TikTok 私訊同 WhatsApp、Zalo 訊息一齊進咗佇列。客服從一個統一列表入面處理工單。TikTok 嘅 12 小時回覆指標——呢個指標影響住店鋪嘅流量權重——唔再係煩惱，因為訊息發出後幾秒鐘就入咗系統，而唔係等人手動錄入。

團隊發現咗一個細節：直播後嘅私訊普遍又短又密，都係催出貨、問庫存、查訂單呢類。每條訊息到達時，發件人 ID、訊息內容、時間戳記都已經解析好，客服唔使再從 TikTok App 入面手動抄錄——訊息直接就係後續流程期望嘅格式。

團隊冇引入新工具，冇擴充人手，加咗一個 Webhook 端點、一個簽名密鑰，TikTok 私訊就同其他渠道嘅訊息一樣正常流轉。對於同時經營 TikTok 同 WhatsApp、Zalo 嘅跨境賣家嚟講，同一個 message.received 事件意味住同一套處理邏輯可以覆蓋所有渠道——因為非官方入站接口喺訊息到達你嘅代碼之前，已經將渠道差異抹平咗。