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 | 圖示、名稱、說明、Email、隱私權政策、使用條款、多語系、連結 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 日：