LINE MINI App 服務訊息範本審查：送件前檢查清單
LINE MINI App 服務訊息範本送審前，先從 LINE 提供的範本中選出最符合用途的一種，在 Use Case 寫明使用者動作與通知順序，測試全部變數與永久連結，並移除促銷內容。正式發送同時需要已驗證 MINI App，以及 Published status 為 PUBLISHING 的範本；模擬器成功或顯示 DEVELOPING，都不等於正式環境已核准。
重點整理
- 服務訊息只能確認或回應使用者在 MINI App 內完成的動作；折扣、購物回饋、新品、優惠券、促銷及一般活動通知皆不允許。
- 版型由 LINE 提供，團隊選擇適合的分類與語言，設定變數、連結及真實使用情境。
- 每個 channel 最多可加入 20 個範本。API 名稱採
{template name}_{BCP 47 language tag}，必須與 LINE Developers Console 一致。 - MINI App channel 審查期間可查看範本與使用模擬器，但不能新增、編輯 Use Case 或刪除範本。
- 驗證後若變更服務訊息範本資訊，需要重新審查；核准的 Use Case 應視為正式環境邊界。
LINE 服務訊息範本審查核准的範圍
LINE 官方服務訊息說明把三個常被混在一起的階段分開：
- MINI App 資格： 正式環境的服務訊息只供已驗證 LINE MINI App 使用；未驗證 App 僅能讓內部 Developing channel 的 Admin 或 Tester 測試。
- 範本審查： 選定的範本與申報 Use Case 必須通過 LY Corporation 審查，才能用於正式環境。
- 執行階段授權： 核准後，伺服器仍須取得綁定使用者與動作的 service notification token，才能呼叫發送 API。
既有的已驗證與未驗證 MINI App 指南處理第一項判斷，service notification token 教學處理第三項實作。本文聚焦在中間缺口：送審前如何準備範本及運作規則。
| 狀態 | 可以做什麼 | 不能證明什麼 |
|---|---|---|
DEVELOPING | 在內部 Developing channel 對合資格開發者帳號預覽、測試 | 正式使用者已可收到訊息 |
| MINI App channel 審查中 | 查看範本細節、使用模擬器測試 | 審查期間仍可新增、編輯或刪除範本 |
PUBLISHING | MINI App 驗證後，在正式 channel 使用已審查範本 | 可變更 Use Case 或改成促銷用途 |
| 驗證後修改範本 | 為更新內容準備重新審查 | 舊核准會自動涵蓋新內容 |
LINE 的狀態表將通過審查的範本標示為 PUBLISHING。不要在系統中自行推測另一種「可上線」狀態；應儲存 Console 實際顯示的狀態，並在 channel 與範本都就緒前擋下正式工作。
LINE MINI App 服務訊息範本送審前檢查清單
1. 先定義一次使用者動作，再撰寫訊息
先寫出觸發動作，例如餐廳訂位、候位登記、下單、報到或配送申請；再列出使用者因該動作需要收到的確認、結果或提醒。LINE 通常允許一次使用者動作最多發送五則服務訊息，但實際核准上限可能依情境而異。
審查說明應呈現完整順序，例如「訂位後立即確認、前一天提醒、當天狀態更新」，而不是描述長期行銷受眾。這能讓審查者及後續工程團隊判斷每則訊息是否仍直接對應原始動作。
2. 選擇最相符的官方範本與語言
LINE 依商店預約、候位管理、配送通知等分類提供範本，支援日文、英文、繁體中文、泰文、印尼文與韓文。應選擇真正符合操作目的的版型，不要把宣傳文案放進交易型範本。
請原樣記錄 Console 顯示的 Template name for API use。發送要求中的欄位是 templateName，格式為 {template name}_{BCP 47 language tag}；不要依可見標題自行拼接語言後綴。
3. 將 Use Case 寫到可驗收的程度
Use Case 應說明誰在何處完成什麼動作、每則通知確認什麼、何時發送。「顧客更新」太模糊；較可驗收的寫法是：「使用者在 MINI App 完成配送預約後立即寄送預約確認，承運商更新訂單時再寄送配送結果。」
LINE 說明，若範本實際用途偏離申報內容，可能會禁止使用。把核准文字同步到內部 runbook 與 job 定義，避免產品改動後不知不覺擴張用途。
4. 驗證變數、字數限制與永久連結
在 Console preview 中，以短值、常見值及接近上限的值測試每個變數，確認日期、姓名、訂單編號與本地化文字符合所選範本的建議及硬性限制。即使範本沒有變數，發送要求仍需帶 params: {}。
按鈕必須使用 LINE MINI App 頁面的永久連結。第一個按鈕為必填，之後的按鈕依範本而定。請在 LINE 用戶端內檢查目的頁、登入狀態與過期訂單畫面，不要只在桌面瀏覽器確認網址可開啟。
5. 凍結審查集合前完成模擬器測試
Console 可向目前登入開發者帳號所綁定的 LINE 帳號發送測試訊息。應檢查排版、變數順序、語言、按鈕及 Footer。模擬器成功只證明顯示正確，不代表已有正式資格。
提交 MINI App channel 審查前，先補齊所有範本。審查期間不能新增範本、編輯 Use Case 或刪除範本。先前已成功加入的範本不受影響，但此時才發現缺少通知，會延後上線。
6. 定義核准後的變更邊界
MINI App 驗證後，LINE 的更新說明要求任何服務訊息範本資訊變更都重新審查。應把範本更新納入變更管理，在發布相依程式前，比較新舊使用者動作、內容、變數、連結及發送時間。
執行階段可記錄 templateName、動作或訂單 ID、sessionId 與最新 remainingCount，但不要把 LIFF access token、channel access token 或 service notification token 寫入 log。通過審查不會取代 token 生命週期及投遞監控。
UnifyPort 適合放在哪一層
UnifyPort 不會提交或核准 LINE MINI App 範本，不會更改 Published status、簽發 LINE service notification token，也不會擴大 LINE 允許的訊息內容。預約、訂單、候位等 MINI App 內動作的通知，應使用 LINE 官方流程。
UnifyPort 處理的是另一項需求：從已連接的一般 LINE 帳號接收自由格式的顧客訊息。LINE 帳號透過 QR 流程授權，支援的入站訊息會以標準 message.received 事件送達。若 webhook endpoint 設定 signing_secret，投遞會包含 X-Device-Timestamp 與 X-Device-Signature，供接收端驗證 HMAC-SHA256。
使用者收到官方服務訊息後若再提出客服問題，這個分界就很重要：已審查範本負責交易通知，獨立入站路徑負責對話。LINE 入站訊息指南說明第二種架構，但不會改變 MINI App 資格。
限制與取捨
- MINI App 需要發送核准的交易通知時，LINE 官方路徑最合適；非官方介面無法取得驗證狀態或範本核准。
PUBLISHING不是一般發訊權限，內容仍須符合核准 Use Case 與服務訊息政策。- 審查通過不保證每次 API 呼叫成功；token 會失效或輪替，
remainingCount會歸零，錯誤變數仍會造成失敗。 - 服務訊息不是客服收件匣。若使用者需要自由提問，應另建訊息接收路徑。
FAQ
LINE 服務訊息範本什麼狀態代表通過審查？
LINE 將通過審查、可在 MINI App 驗證後用於正式 channel 的範本 Published status 定義為 PUBLISHING。
未驗證 LINE MINI App 能申請正式服務訊息嗎？
不能。未驗證 App 僅能在內部 Developing channel 對合資格開發者帳號測試；正式發送需要 MINI App 已驗證，範本也已審查。
服務訊息可以放優惠券或促銷嗎？
不可以。折扣、購物回饋、新品、優惠券、促銷、廣告及一般活動通知都被禁止；訊息必須確認或回應 MINI App 內的使用者動作。
MINI App channel 審查期間可以編輯範本嗎？
不可以。審查中可查看範本細節與使用模擬器，但不能新增範本、編輯 Use Case 或刪除範本，應在送審前準備完整。
修改服務訊息範本需要重新審查嗎？
需要。LINE 把服務訊息範本的所有資訊列為已驗證 MINI App 更新後需要重新審查的 Console 設定。
下一步
先依官方LINE 服務訊息指南準備範本、Use Case、變數及模擬器證據。若真正需求不是交易通知，而是接收自由格式顧客訊息，可將 UnifyPort LINE 授權指南作為獨立實作路徑。
官方來源
以下 LINE 官方資料核對於 2026 年 7 月 28 日：