← 所有文章
指南

LINE Service Messages 是什么:何时使用,何时改用 Webhook 接收

LINE service messages 是 LINE MINI App 的通知能力,用来在用户完成某个 MINI App 动作后,向用户发送必须知晓的确认或提醒信息。它不是通用 LINE Messaging API push,不是自由格式聊天机器人回复,也不是客服收件箱。做交易型通知时可以用它;要接收、分流、沉淀用户对话时,应单独设计 webhook 接收层。

关键结论

  • LINE 官方文档把 service messages 定义为 LINE MINI App 中,响应或确认用户特定动作的通知。
  • 发送 service message 需要已审核的 service message template 和 service notification token。
  • LINE 文档举例包括预约完成和预约前提醒,并说明单个预约动作最多可发送 5 条 service messages。
  • 如果你要做的是接收 LINE 消息、客服分流,或把 LINE、WhatsApp、Zalo 等渠道统一到一个队列,应优先设计 inbound webhook。
  • 对比官方能力边界,可继续读 LINE Service Messages vs Messaging API;实现令牌流程可读 notification token 指南

LINE service messages 到底是什么

LINE Developers 文档说明,service messages 是 LINE MINI App 的功能,用于在用户完成特定动作后,发送用户应该知道的信息。关键不在于“能不能发消息”,而在于触发条件:它应当跟 MINI App 内的用户动作绑定,例如预约、下单或类似确认步骤。

所以它更像受控的交易通知,而不是客服系统。对跨境团队来说,这个边界很重要:如果你在日本、泰国或台湾市场运营 LINE MINI App,service messages 适合做动作后的确认;但如果你的海外客服需要处理用户主动发来的问题,它就不是完整收件箱。

官方发送路径

LINE 文档里的流程可以拆成三步:

  1. 在 LINE Developers Console 的 LINE MINI App channel 中添加 service message template。
  2. 模板通过 LY Corporation 的审核后,才能用于 Service Message API。
  3. 在用户动作后签发 service notification token,再用该 token 发送 service message。

同一份官方文档还说明,模板来自 LY Corporation 提供的模板,并且每个 LINE MINI App channel 最多可配置 20 个 service message templates。也就是说,模板不是后端随手拼 JSON 的问题,而是产品、运营和审核共同约束的设计对象。

判断问题如果是如果不是
消息是否绑定一个 MINI App 用户动作?可考虑 service messages。应选择其他消息或客服路径。
是否已有 LINE MINI App channel?准备模板和通知令牌。service messages 通常不是第一步。
内容能否放进官方模板?提交审核并测试。调整通知设计或换渠道。
用户是否需要回复并进入客服流程?增加 inbound webhook 队列。保持为单向通知即可。

不要把它和聊天 UI 模板混在一起

LINE Messaging API 也有 template messages,例如 buttons、confirm、carousel 和 image carousel。官方文档说明 confirm template 是两个按钮;quick replies 在支持的消息上最多可放 13 个回复按钮。

这些是 LINE Official Account 对话里的交互 UI;service messages 则是 LINE MINI App 的通知机制,有自己的模板、审核和通知令牌流程。用户搜索“LINE service messages 是什么”时,最短答案就是:它是用户动作后的 MINI App 审核通知,不是通用聊天模板。

什么时候应该用 webhook 接收层

一旦用户可能回复、追问,或从 LINE 切换到 WhatsApp、Zalo、Telegram、TikTok、X 等渠道,问题就变了。你不只是发送一条受控通知,而是要接收事件、验签、入库、分流给客服或 AI 工作流。

UnifyPort API reference 文档定义了跨平台标准化的 message.received 事件。事件 envelope 包含 idtypeprovideraccount_idoccurred_atdata;消息部分包含 data.conversationdata.senderdata.message。webhook 可通过 signing_secret 和 HMAC-SHA256 验证。可查看深层文档:standard webhook events

{
  "id": "evt_2f9c1a4b7e",
  "type": "message.received",
  "provider": "line",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-06-08T12:34:56Z",
  "data": {
    "conversation": { "id": "line_user_123", "type": "user" },
    "sender": { "id": "line_user_123", "type": "user", "name": "Jordan Lee" },
    "message": {
      "id": "msg_10472",
      "text": "我可以改预约时间吗?",
      "direction": "inbound",
      "sent_at": "2026-06-08T12:34:55Z"
    }
  }
}

这就是 service message 和接收层的分工:一个确认动作,一个承接对话。

决策规则

如果消息绑定 MINI App 用户动作、能放进审核模板、且不需要成为客服主收件箱,使用 LINE service messages。若核心任务是接收、分类、路由 LINE 或多平台消息,使用签名 webhook 接收层。

如果还在比较 LINE 官方能力,先读 LINE Service Messages vs Messaging API。如果要落地接收层,下一步是打开 webhook event reference 并先注册端点。

FAQ

LINE service messages 和 Messaging API push 一样吗?

不一样。service messages 属于 LINE MINI App,并且绑定用户动作和模板;Messaging API push 属于 LINE Official Account 消息能力。

service messages 能处理用户回复吗?

service message 本身是通知机制。若用户需要回复、团队需要分流对话,应增加 inbound webhook 队列。

每个 MINI App channel 能配置多少 service message templates?

LINE 官方 service-message 文档说明,每个 LINE MINI App channel 最多可配置 20 个 service message templates。

2026-08-27 核对来源

UnifyPort API

让消息接入变成一条稳定的产品管线。

先用统一 API 跑通发送,再用标准事件把所有入站消息接回业务系统。