← 所有文章
教程

如何使用通知令牌发送 LINE MINI App 服务消息

发送 LINE MINI App 服务消息时，应在用户完成操作后取得新的 LIFF access token，由服务端换取只绑定该用户的 service notification token，再用已审核模板调用官方发送接口。每次发送成功后都要保存响应里更新的 notificationToken；令牌值会轮换，剩余可发送次数则以 remainingCount 为准。

要点速览

  • 生产环境服务消息要求 LINE MINI App 已通过验证，所用模板也已获批。未验证应用只能在内部 Developing channel 向 Admin 或 Tester 账号测试。
  • 一个 LIFF access token 只能通过 POST /message/v3/notifier/token 签发一个 service notification token；该令牌只对应一个用户和一次操作会话。
  • 发送接口是 POST /message/v3/notifier/send?target=service。发送后必须用响应中的新 notificationToken 覆盖旧值。
  • 新令牌有效期为一年，通常从五次可发送额度开始。审核场景可能采用不同上限，因此运行时要以 remainingCount 为准。
  • 这条官方链路只用于确认、结果和提醒等与 MINI App 用户操作直接相关的通知，不是自由格式客服会话或营销群发接口。

签发通知令牌前要满足哪些条件

本文从“已具备资格”之后开始讲实现。如果团队还在判断生产环境能否使用服务消息，请先阅读LINE MINI App 已验证与未验证限制清单。

动手接入前，先确认四项前置条件：

前置条件必须达到的状态原因
LINE MINI App channel生产环境已通过验证未验证应用不能从 Published channel 发送服务消息
服务消息模板已添加，并以 PUBLISHING 状态通过审核接口只接受已审核的模板名及其定义的变量
用户操作预约、购买、签到、发货或其他获准操作每条通知都必须确认或回应这次操作
服务端凭据Stateless 或 short-lived channel access tokenMINI App channel 不接受 long-lived token 或 Channel Access Token v2.1

LINE 推荐 stateless channel access token，因为应用无需管理其过期时间。Channel access token 必须留在服务端，绝不能返回给 MINI App 前端。

三类 LINE token 分别负责什么

为每类凭据只分配一个职责，整个流程就会清楚很多：

凭据获取位置证明什么关键生命周期规则
LIFF access tokenMINI App 中的 liff.getAccessToken()当前 LINE 用户已经授权最长有效 12 小时，但用户关闭应用后可能立即失效
Channel access token服务端保存的 LINE 凭据当前 LINE MINI App channel 有权调用接口优先使用 stateless token，不能暴露给浏览器
Service notification tokenPOST /message/v3/notifier/token某个用户的一次操作可以触发通知只绑定一个用户、最长一年、受次数限制，而且每次发送后都会更新

同一个 LIFF access token 只能签发一个 service notification token。用户完成操作后应尽快在服务端完成交换：即使 LIFF token 还没到标称过期时间，用户关闭 MINI App 或追加授权也可能使它失效。

如何使用通知令牌发送 LINE MINI App 服务消息

1. 用户完成操作后取得 LIFF access token

预约、购买或其他获准操作成功后，在 MINI App 中调用 liff.getAccessToken()，再通过 HTTPS 把结果交给自己的服务端。可以把后端请求关联到内部订单或预约记录，但不要把 LIFF token 或稍后取得的 service notification token 写进应用日志。

浏览器不能直接调用 Service Message API，因为签发和发送还需要 channel access token。

2. 在服务端换取 service notification token

服务端调用官方签发接口：

curl -X POST https://api.line.me/message/v3/notifier/token \
  -H "Authorization: Bearer ${LINE_CHANNEL_ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d "{\"liffAccessToken\":\"${LIFF_ACCESS_TOKEN}\"}"

成功响应包含四个字段：

{
  "notificationToken": "34c11a03-b726-49e3-8ce0-949387a9f531",
  "expiresIn": 31536000,
  "remainingCount": 5,
  "sessionId": "xD06R2407210008"
}

应加密保存令牌，并同时记录 expiresIn、remainingCount、sessionId 和自己的用户操作标识。不要把 sessionId 当作用户身份：接收人绑定已经在 service notification token 内完成，而且该令牌不能用于另一位用户。

3. 发送已审核模板

调用官方发送接口，并带上必填的 target=service query parameter：

curl -X POST "https://api.line.me/message/v3/notifier/send?target=service" \
  -H "Authorization: Bearer ${LINE_CHANNEL_ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "templateName": "thankyou_msg_en",
    "params": {
      "date": "2026-07-21",
      "username": "Brown & Cony"
    },
    "notificationToken": "34c11a03-b726-49e3-8ce0-949387a9f531"
  }'

必须使用 LINE Developers Console 中显示的准确 templateName 和变量名。模板名格式是 {template name}_{BCP 47 language tag}，最长 30 个字符；服务消息支持的语言后缀为 ja、en、zh-TW、th、id 和 ko。即使模板没有变量，params 仍是必填字段，值应为 {}。

4. 每次发送后保存更新的 token

发送成功后，响应会返回新的 notificationToken、更新后的 expiresIn 与 remainingCount，以及同一操作对应的 sessionId。在安排下一条提醒前，应原子更新这条记录。继续使用旧令牌，可能让本来合规的后续通知失败。

如果 expiresIn 和 remainingCount 同时为 0，代表本次消息已经发送，但 LINE 没有续发令牌。此时应把操作会话标记为完成，不能再基于该响应安排下一条消息。

存储与重试检查清单

Service notification token 是会轮换的凭据，不是永久用户地址：

  1. 用户完成符合条件的 MINI App 操作时，建立一条操作记录。
  2. 只交换一次 LIFF token，保存 sessionId、加密令牌、过期时间和剩余次数。
  3. 发送期间对操作记录加锁或做版本控制，避免两个 worker 同时消耗同一令牌。
  4. 收到 HTTP 200 后，先提交新令牌和计数，再安排下一次提醒。
  5. 收到 400 时，先核对请求体、接收人状态和模板变量，再决定是否重试。
  6. 收到 401 时，更新服务端 channel credential，或重新开始一条用户操作链路；不要持续重放无效的 LIFF 或 service notification token。
  7. 收到 403 时，检查 channel 是否获准，以及准确模板是否处于允许状态。

不要自行编造 LINE 的数值重试策略。官方文档定义了错误类别，但没有公布这组接口的固定请求频率。只有临时故障才适合有限重试，也不能把一次失败操作变成无关通知。

UnifyPort 在哪里承接

MINI App 交易通知必须使用 LINE 官方 Service Message API。UnifyPort 不签发或更新 LINE service notification token，不提交模板、不授予验证状态，也不会把普通聊天消息转换成 MINI App 服务消息。

UnifyPort 承接的是另一条自由格式客服路径。如果客户在交易通知前后打开普通 LINE 会话，已连接的 LINE 账号可以把入站文本交付为标准 message.received 事件。客服系统可将它与 WhatsApp、Telegram、Zalo、TikTok 或 X 的事件一起路由，并在 provider capability matrix 确认支持后使用 POST /v1/messages 回复。

这与LINE MINI App 支付和客服 webhook 指南中的拆分一致：官方 MINI App API 负责交易动作，客户消息管道负责普通会话接入。后一条路径可从LINE 授权指南和准确的 message.received 事件文档开始。

限制与取舍

如果已验证 MINI App 需要确认预约、报告操作结果或提醒用户此前完成的操作，官方服务消息是正确选择。它把通知与 LINE 用户、审核模板和获准用途绑定在一起。

这项能力被有意设计得很窄：一次操作通常最多发送五条，模板需要审核，广告、优惠券、积分奖励、新品推广和一般活动公告都禁止发送。LY Corporation 可能在审核时指定不同上限。一个 channel 最多配置 20 个模板，实际发送用途也必须始终与提交的 Use Case 一致。

非官方接口不能改变这些规则或增加 token 次数；Service Message API 也不能替代开放式客服收件箱。两套系统应通过团队自己的订单号或预约号关联，而不是在它们之间共享平台 token。

常见问题

LINE service notification token 有效多久？

新签发 token 的有效期为一年，也就是 31,536,000 秒。剩余发送次数归零时，它可能更早停止可用；实际运行应始终以 LINE 最新返回的 expiresIn 和 remainingCount 为准。

后续服务消息能继续使用同一个 notification token 吗？

应使用最近一次成功发送后返回的新 notificationToken，不能继续使用旧值。令牌还只绑定一个用户，不能换给另一位接收人。

一次用户操作最多能发送多少条 LINE MINI App 服务消息？

标准上限是五条。LINE 可能为特定 Use Case 批准不同限制，因此响应中的 remainingCount 才是运行时上限。

未验证的 LINE MINI App 能调用通知令牌接口吗？

可以在内部 Developing channel 向 Admin 或 Tester 账号测试；从 Published channel 向正式用户发送，必须先取得 LINE MINI App 验证并使用已审核模板。

Service notification token 等同于 Messaging API user ID 吗？

不等同。它是针对某次 MINI App 用户操作、只绑定一个用户且会轮换的服务消息授权，不是通用用户地址、push message credential 或客服聊天身份。

下一步

按照 LINE MINI App API Reference实现官方两次调用，并在每次发送后保存更新令牌。如果另一项需求是接收普通 LINE 客户消息，再把 UnifyPort LINE 授权指南作为辅助路径。

官方来源

以下 LINE 官方来源核验于 2026-07-21：