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 或刪除範本。
- 已驗證 MINI App 修改服務訊息範本資料後需要再審，獲批 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 將通過審核嘅範本 Published status 定義為 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 日：