LINE MINI App 再審發布：掌握 Approved 與 Reflected
已認證 LINE MINI App 如更改名稱、私隱政策 URL、Published Endpoint、scope、連結的 LINE Official Account、Service Message template 或公司資料等受審設定，就要重新送審。對已發布的應用程式而言，審核通過並不等於即時上線：狀態會先停在 Approved，按 Publish changes 後才轉為 Reflected。如沒有操作，LINE 會在第 31 天自動套用已批准變更。
重點摘要
- LINE Developers Console 中受審設定的變更需要再審；不涉及這些設定的程式或內容更新不會單純因部署而觸發再審，但仍要符合 LINE MINI App Policy。
- 已認證 MINI App 有 Developing、Review、Published 三個內部 channel，每個 channel 都有獨立 LIFF ID。
- 對現有應用程式來說，
Approved是發布窗口；按 Publish changes 才會把已審設定複製到 Published 並轉為Reflected。 - 如 30 天內未手動發布，LINE 會在第 31 天日本時間上午 9:00 自動套用，週末及公眾假期亦計算在內。
- 因維護等正當原因暫時替換 Published Endpoint 是官方列出的例外；它是短期應變安排，不能代替永久變更的再審。
哪些 LINE MINI App 變更需要再審？
LINE 官方再審指南列出會重新進入審核流程的 Console 設定。判斷重點不是「今次有沒有部署程式碼」，而是「是否改變已經審核的 LINE Developers Console 合約」。
| 範圍 | 需要再審的例子 | 發布影響 |
|---|---|---|
| Basic settings | 圖示、名稱、說明、電郵、私隱政策、使用條款、多語言、連結 Official Account | 將品牌及法律變更合併成一個送審版本 |
| Web app settings | shareTargetPicker、consent simplification、Published Endpoint、scope、加好友選項 | 設定進入 Reflected 前，不要啟用依賴它的正式功能 |
| 公司及聯絡資料 | 服務、開發、provider 及全部聯絡資料 | 保持法律主體與支援聯絡人一致 |
| Service Message | 任何 template 資料 | 新版本反映前，沿用目前已發布 template |
| In-app purchase | 申請頁內的資料 | 先協調獨立的 in-app purchase 審核，再送驗證審核 |
如更新沒有觸及以上 Console 設定，就不會只因應用程式內容改變而要求再審。不過這不是政策豁免；如已發布內容或素材違反 LINE MINI App Policy，LINE 仍可要求修正。
本文由首次認證之後開始。第一次提交請使用認證審核清單；如修改 Service Message 的 use case、變數或連結，請先依照模板審核清單準備。
Approved 是發布窗口，不是正式環境
官方提交指南區分兩種審核後流程：
| 情況 | 審核通過後 | 營運動作 | 自動界線 |
|---|---|---|---|
| 第一次驗證 | Approved 即時轉為 Reflected | 準備好後另行啟用站內搜尋 | 未手動啟用時，第 31 天日本時間 9:00 自動啟用搜尋 |
| 已發布認證應用程式的再審 | 停在 Approved，正式環境仍使用目前設定 | 按 Publish changes | 未手動發布時，第 31 天日本時間 9:00 自動反映 |
第二種才是本次發布控制的核心。Approved 只代表變更可以發布，不代表用戶已經看到。按 Publish changes 後，Review 設定才會複製到 Published，狀態轉為 Reflected。LINE 提醒，第 31 天的自動切換可能延遲一至兩小時。
由 Developing 到 Reflected 的發布清單
- 盤點本次受審設定。 保存名稱、URL、scope、連結帳戶、template 組合及公司資料的準確版本。
- 分開三個 LIFF ID。 Developing、Review、Published 各有獨立 LIFF ID；每個環境都要使用對應 ID 初始化，並測試審核人員實際打開的 Review URL。
- 發布前驗證依賴項目。 檢查 redirect、私隱政策與條款頁、permanent link、Service Message template、加好友及 consent 行為。
- 記錄批准時間及第 31 天限期。 週末和假期都計算在內，不要把自動發布當作無限期暫存。
- 安排 Publish changes。 指定一位負責人、訂立 go/no-go 檢查，並保存
Approved到Reflected的狀態證據。 - 進行發布後驗收。 在真實 LINE 用戶端開啟 Published LIFF URL，核對名稱與設定，並檢查原有客戶訊息接收鏈路。
進入 Reflected 後，channel 會回到 Not yet reviewed，準備下一輪變更。新的編輯只留在 Developing，不會影響目前已發布的認證應用程式，直至下一次審核通過並發布。
緊急 Endpoint 切換與還原
LINE 說明，因維護或其他正當理由暫時替換 Published Endpoint 不需再審，而且會即時生效。應嚴格限制用途：切換到受控維護頁面、保存原 Endpoint、驗證用戶看到的結果，並在事件結束後恢復已審服務。
不要利用維護例外長期發布新產品、scope、身分或 template；它們仍然是受審變更。如同時修改 in-app purchase 資料，也要安排審核次序：in-app purchase 申請審核期間不能提交驗證審核，而驗證審核期間也不能申請 in-app purchase。
UnifyPort 適用在哪裏？
UnifyPort 不會代 LINE MINI App 送審、改變 Approved 或 Reflected、在內部 channel 之間複製設定，亦不能授予已認證功能。MINI App 身分、搜尋、Service Message、Quick-fill、捷徑及 in-app purchase 必須使用 LINE 官方流程。
UnifyPort 處理另一條獨立路徑：把已連接一般 LINE 帳戶所支援的訊息轉為標準化 message.received event。Webhook endpoint 設有 signing_secret 時，應以 raw request body 驗證 X-Device-Timestamp 及 X-Device-Signature 後才作路由。
分開兩條路徑，可讓 MINI App 發布遵循 LINE 審核，同時不暗中改變客戶服務訊息接收合約。先看 LINE 授權指南，再從訊息支援矩陣確認目前範圍。
限制與取捨
只要變更涉及受審 MINI App 設定或已認證專屬功能，官方再審就是必要流程。非官方接口不能加快批准、阻止第 31 天自動發布、還原 LINE Console 變更，亦不能把一般帳戶訊息變成 MINI App Service Message。
相反，通過再審只證明 LINE 接受已提交設定，不能證明部署、deep link、監控或 inbound queue 已完成端到端驗證。應把審核狀態與營運就緒設成兩個獨立 gate。
FAQ
Approved 和 Reflected 有甚麼分別？
Approved 代表 LINE 接受變更。對已發布的認證 MINI App，用戶仍看到目前設定，直至按 Publish changes 或到達自動發布時間。Reflected 代表已審變更已複製到 Published。
已批准變更最多可等待多久才發布？
最多 30 天。如沒有按 Publish changes，LINE 會在第 31 天日本時間上午 9:00 自動反映，週末和假期也計入，並可能延遲一至兩小時。
每次程式部署都需要再審嗎？
不需要。LINE 說明，不涉及受審 Console 設定的更新不需要再審，但已發布服務仍須遵守 LINE MINI App Policy。
維護時可以暫時更改 Published Endpoint 嗎？
可以。LINE 把維護或其他正當理由的暫時 Endpoint 替換列為不需再審且即時生效。請保持短期使用，並準備已驗證的還原方案。
Service Message template 修改需要再審嗎？
需要。LINE 將全部 Service Message template 資料列為受審設定；新版本通過並發布前，目前 Reflected 的 template 仍是正式合約。
下一步
依 LINE 官方再審指南與提交發布流程建立發布日曆。如另一個需求是接收一般 LINE 客戶訊息，請使用 UnifyPort LINE 授權指南。
資料來源
以下 LINE 官方來源核對於 2026 年 8 月 9 日：