再加一個 LINE 也沒問題:一個東京團隊如何把 LINE 和 WhatsApp 接到同一個入站 Webhook — UnifyPort
2026 年 4 月底,一家總部位於東京、只有四名成員的護膚品牌,正在為初夏的活動做最後準備——一款限量防曬產品線即將上市,搭配的是以 LINE 為基礎的客服與會員互動管道。在日本市場,LINE 幾乎是消費者聯繫品牌的預設方式。計畫很簡單:客戶透過品牌的 LINE 帳號詢問新品、補貨時間或訂單狀態,這些訊息會被導入團隊既有的客服處理佇列。
這個「既有佇列」指的是 WhatsApp。這個品牌的包材供應鏈分布在中國與東南亞,所有供應商溝通都走 WhatsApp,並在年初就透過 UnifyPort 接進了後端系統。在團隊看來,接入 LINE 應該是同樣的操作:連接帳號、接收訊息、做路由。
但事情並非如此——因為 LINE 的官方路徑,第一步根本不是「連接帳號」。
上線前兩週撞上 60 個工作日的牆
要在 LINE 上以程式方式接收訊息,Messaging API 要求擁有一個 LINE 官方帳號(Official Account)。團隊在 5 月初提交了註冊申請,以為是常規審核流程。結果在 LINE 官方文件中看到的是:認證型官方帳號的審核時程最長可達 60 個工作日;而未認證帳號則被限制在 500 個好友以內——對一個真正有聲量的季節性活動來說,第一週就會撞到這個上限。
從 5 月初起算的 60 個工作日,遠遠超出了活動上線的時間窗,甚至超過了防曬產品的銷售季本身。團隊面前是幾條熟悉的老路:在沒有 LINE 客服支援的情況下硬著頭皮上線(而在 LINE 幾乎等於客服本身的市場裡);用未認證帳號上線,然後在流量高峰時撞上好友數上限;或是找一家在地代理機構加急辦理註冊——成本與時程兩位創辦人都說不清楚。
這些選項其實都跟技術無關。後端的處理邏輯——接收一則訊息、查詢訂單、回覆——和他們替 WhatsApp 寫的那九行路由邏輯幾乎一模一樣。真正的瓶頸,完完全全卡在「我們已經有 LINE 帳號」和「後端能看到送到這個帳號的訊息」之間的那段審核排程。
重新定義問題:WhatsApp 的接入方式早就驗證過這個思路
團隊的主力開發人員幾個月前就透過 UnifyPort 接入了 WhatsApp——不是走 Meta 的 Cloud API,而是 UnifyPort 的非官方入站介面:直接連接一個既有的 WhatsApp 帳號,把 message.received 事件推送到 Webhook,完全不需要 Business Verification。當時做這個決定的理由其實跟 LINE 無關(面向供應商的那個 WhatsApp 號碼不需要任何對外行銷功能,只需要穩定的入站訊息),但它正好驗證了團隊現在面對 LINE 時需要的判斷:官方認證/審核機制管控的是對外群發能力,而不是入站訊息的送達。
客戶主動傳訊息給品牌的 LINE 帳號——正是這個案例裡的全部場景——並不需要品牌持有一個粉絲數達標、經過認證的官方帳號,訊息才能送達後端。同一套已經默默處理 WhatsApp 的非官方入站介面,完全可以用同樣方式接入 LINE 帳號。
把 LINE 接進既有的 Webhook
團隊把 LINE 帳號接進了 UnifyPort,和已經設定好的 WhatsApp 帳號共用同一條連線——沒有新的 Webhook 網址,沒有第二套簽章機制,也不需要另外維護一份憑證輪換排程。兩個帳號的訊息都會送到同一個 POST /webhook 網址,用同一個 HMAC-SHA256 密鑰簽章:
LINE 客戶(日本) ──┐
WhatsApp 供應商(中國/東南亞) ──┼──► UnifyPort ──► POST /webhook(既有後端)
┘ X-UnifyPort-Signature: sha256=...一則來自 LINE 客戶的補貨詢問,和一則來自 WhatsApp 供應商的訊息,會以完全相同的結構抵達——唯一變化的是 provider 欄位:
{
"event": "message.received",
"account_id": "acct_3Tn8qZ",
"provider": "line",
"from": "U2c91af77b8d4e...",
"text": "新作の日焼け止め、再入荷はいつ頃ですか？",
"timestamp": 1748332800,
"message_id": "line_msg_7e2a91"
}團隊既有的路由處理函式——原本就把 WhatsApp 供應商訊息分流到採購佇列——只多了一個分支:當 provider == "line" 時,導向客服佇列。不需要解析新的資料結構,不需要重新實作簽章驗證,也不用再寫一套去重與重試邏輯。年初就已經在線上跑了好幾個月的 WhatsApp 處理邏輯,只用一個條件判斷就接住了 LINE。
在活動上線前就跑起來,而不是上線之後
LINE 接入當天就上線了——比活動正式啟動早了大約兩週,留下足夠時間用一小部分預熱流量測試路由規則。當防曬產品線在 6 月初正式上市時,所有透過 LINE 傳來的客戶詢問,從第一則訊息開始就自動分類、自動路由,和其他管道的訊息一起進入同一個處理佇列。
團隊 5 月初提交的 LINE 官方帳號申請,在活動上線時仍在審核中。大約七週後才終於通過。但那時,LINE 入站訊息已經在整個活動期間穩定運行——審核結果已經不再卡住任何流程。如果這個官方帳號未來獲准,並帶來團隊想要的群發功能(豐富選單、官方認證標誌、面向更大粉絲群的推播活動),團隊可以在不動到入站連線的前提下疊加這些能力——因為入站本來就不是被卡住的那部分。
可以複用的模式
真正起作用的,不是什麼 LINE 專屬的技巧——而是團隊從 WhatsApp 的接入經驗裡已經吃透了一個道理:入站訊息接收和對外群發資格是由不同門檻把關的兩個不同問題。一旦某個平台的統一入站 Webhook 跑起來,接入第二個平台往往只是把另一個帳號連到同一條連線,再在已經跑通的處理邏輯裡加一個分支。
對於在日本、泰國、台灣,或任何把 LINE 當作主要客戶管道的團隊來說,真正的問題從來不是「我們能不能在活動上線前把 LINE 官方帳號核准下來」,而是「我們第一天就需要對外群發能力,還是只需要看到客戶現在在問什麼」。如果是後者,把一個 LINE 帳號接進 UnifyPort 是一天內就能完成的事;如果團隊的 WhatsApp、Zalo、TikTok 或 X 也已經在用 UnifyPort,那就是同一個 Webhook——訊息本來就已經送到這裡了。
官方審核流程仍在背景中跑著。只是它已經不在關鍵路徑上了。