← 所有文章
案例分析

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 事件意味著同一套處理邏輯能涵蓋所有管道——因為非官方入站介面在訊息抵達你的程式碼之前，已經把管道差異抹平了。