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 已完成端到端验证。应把审核状态与运行就绪状态设为两个独立发布门禁。
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 日：