再加一個 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——訊息本來就已經送到呢度。
官方審核流程仍喺背後跑住。只係佢已經唔喺關鍵路徑上。