LINE 服務訊息 vs Messaging API：MINI App 應該點揀？
LINE 服務訊息與 Messaging API 訊息處理的是兩種需求。已認證 LINE MINI App 要確認或跟進用戶在 App 內完成的預約、訂單等操作時，應使用服務訊息；LINE Official Account 要回覆對話、靈活推送或群發時，則應使用 Messaging API。兩者不是高低版本關係，亦不能直接互相取代。
重點
- 服務訊息是綁定 MINI App 內用戶操作的交易通知，不可包含廣告、優惠券、新產品推廣或無關活動通知。
- Messaging API 屬於 LINE Official Account，支援 reply、push、multicast、narrowcast 及 broadcast 等模式。
- 正式服務訊息需要已認證 MINI App、審核通過的範本，以及綁定用戶的 service notification token。
- 服務訊息會顯示於各地區指定的 LINE MINI App 通知聊天室；用戶即使未將相關 Official Account 加為好友亦可接收。
- 同時需要交易通知和開放式客服對話時，應分開設計兩條訊息路徑，再用自有預約編號或訂單編號連結。
LINE 服務訊息與 Messaging API 訊息有甚麼分別
LINE 官方的服務訊息文件將它定義為對用戶在 LINE MINI App 內操作的確認或回應；Messaging API 發送訊息文件說明的則是由 LINE Official Account bot 發出的訊息。選擇時，產品邊界比兩者同樣叫「訊息」更重要。
| 判斷面向 | LINE MINI App 服務訊息 | LINE Messaging API 訊息 |
|---|---|---|
| 主要用途 | 確認、回報或提醒用戶在 MINI App 內完成的操作 | 從 Official Account 回覆用戶，或向個人及受眾發送訊息 |
| 觸發方式 | MINI App 內符合條件的用戶操作 | reply 由用戶事件觸發；其他模式由應用程式決定 |
| 收件人 | service notification token 綁定的用戶 | 按發送方式選擇用戶、群組、多人聊天室、受眾或 Official Account 好友 |
| 訊息設計 | LINE 提供並審核的服務訊息範本與獲批變數、連結 | text、image、video、audio、sticker、location、imagemap、template、Flex 等訊息物件 |
| 正式門檻 | 已認證 MINI App 加獲批範本 | 已連接 LINE Official Account 的 Messaging API channel，並遵守相應收件規則 |
| 顯示位置 | 各地區 MINI App 通知聊天室 | 用戶與 LINE Official Account 的聊天室 |
| 數量邊界 | 一次合資格操作通常最多 5 則，獲批用例可有不同上限 | 受 Official Account 計劃的每月訊息額度及 endpoint 限制影響 |
| 收費方式 | LINE 將 MINI App 服務訊息功能描述為免費 | Messaging API 訊息數量及計劃價格按市場與 Official Account 計劃而定 |
與用戶操作綁定的交易通知選服務訊息
如果沒有用戶在 MINI App 內完成的特定操作，這則通知便不應存在，這類情況才適合評估 Service Message API。官方例子包括預約確認、check-in 完成、出貨完成，以及與預約或已購票券相關的提醒。
伺服器先呼叫 POST /message/v3/notifier/token，用 LIFF access token 取得 service notification token；再以 POST /message/v3/notifier/send?target=service 發送獲批範本。service notification token 綁定一名用戶及該操作流程，不是永久 LINE 用戶地址，亦不是一般 push 憑證。
內容限制不會因 MINI App 已認證而消失。折扣、購物獎勵、新產品、優惠券、促銷及一般活動通知都不屬於服務訊息。準備範本時可參考服務訊息範本送審清單；已完成整合但出錯時，再使用服務訊息 API 錯誤排查手冊。
Official Account 對話與受眾訊息選 Messaging API
當訊息應由 LINE Official Account 發出時，請選 Messaging API。reply message 用 reply token 回應用戶訊息或操作；push message 發送至合資格用戶、群組或多人聊天室；multicast、narrowcast、broadcast 則處理不同受眾模式。
Messaging API 提供更靈活的訊息物件，適合 bot 對話、客服及 Official Account 溝通，同時受好友關係、收件人、每月額度、價格及 rate limit 規則約束。因此，Messaging API push 不能取代服務訊息的特殊能力：通知尚未將相關 Official Account 加為好友的 MINI App 用戶。
可直接使用的選擇流程
- 用戶是否在 MINI App 內完成預約、落單、排隊、check-in 等操作？ 如是，繼續評估服務訊息。
- 通知是否只用作確認、回報結果或提醒同一次操作？ 如否，不要使用服務訊息。
- MINI App 是否已取得正式認證，而且準確範本已獲批？ 如是，使用 Service Message API，並在每次成功發送後儲存更新 token。
- 訊息是否應來自 Official Account、回覆對話或觸達受眾？ 使用 Messaging API，並按收件模型選 reply、push、multicast、narrowcast 或 broadcast。
- 用戶收到通知後會否提出自由形式的客服問題？ 另行設計對話接收路徑，再於自有系統連結交易。
不要預設從兩條路徑重複發送同一更新。重複通知會令用戶混亂，亦增加交付、同意與客服責任的審計難度。
UnifyPort 適合的位置
UnifyPort 不簽發 LINE service notification token、不審批 MINI App 範本、不授予認證狀態，亦不建立 Official Account 或取代 Messaging API 的官方出站功能；這些工作應使用 LINE 官方 API。
UnifyPort 解決另一項獨立需求：從已連接的一般 LINE 帳號接收客戶訊息，並將支援的訊息交付為標準化 message.received 事件。webhook endpoint 如設有 signing_secret，delivery 會包括 X-Device-Timestamp 和 X-Device-Signature；路由對話前，應用 raw body 驗證 HMAC-SHA256 簽署。
例如，服務訊息確認預約後，客戶另行發起一般客服對話。應用程式可保存預約編號並連結對話，但不要把 service notification token 當作聊天身分。採用前請閱讀 LINE 授權指南並核對訊息支援矩陣。
限制與取捨
平台原生 MINI App 服務訊息只能使用官方 Service Message API。非官方介面無法改變認證狀態、審批範本、擴張與操作綁定的內容範圍，或增加獲批訊息數量。
豐富的 Official Account 對話及受眾訊息更適合 Messaging API，但亦要採用 Official Account 的收件、額度及收費模式。UnifyPort 的一般帳號訊息路徑可處理受支援的客戶對話，但不會把對話變成 MINI App 服務訊息，亦不會取得 Official Account 受眾功能。
常見問題
LINE 服務訊息是甚麼？
它是 LINE MINI App 對用戶在 App 內完成的操作進行確認、結果回報或提醒的交易通知。正式環境需要已認證 MINI App 及審核通過的範本。
LINE 服務訊息等同 push message 嗎？
不等同。服務訊息使用綁定用戶的 service notification token 和經審核的 MINI App 範本；Messaging API push 來自 LINE Official Account，並遵守其收件、額度及價格規則。
用戶必須加入 Official Account 才可收到服務訊息嗎？
不必。LINE 表示，即使用戶未將相關 LINE Official Account 加為好友，亦可收到服務訊息；訊息會進入該地區指定的 MINI App 通知聊天室。
服務訊息可以包含促銷或優惠券嗎？
不可以。LINE 禁止廣告及活動通知，包括折扣、獎勵、新產品、優惠券和促銷。推廣內容應在符合自身規則的前提下選擇 Official Account 訊息方式。
同一產品可以同時使用兩種 API 嗎？
可以。服務訊息處理獲批的 MINI App 操作通知，Messaging API 處理 Official Account 對話或受眾訊息。兩條路徑的憑證與狀態應分開，再用自有業務 ID 連結。
下一步
先閱讀 LINE 官方的服務訊息判斷與實作指南。如另一項需求是接收一般 LINE 客戶訊息，再到 UnifyPort 的訊息支援矩陣確認現行邊界。
來源
以下 LINE 官方資料於 2026-08-07 核對：