點樣用通知 token 發送 LINE MINI App 服務訊息

要發送 LINE MINI App 服務訊息，請喺用戶完成操作後取得最新嘅 LIFF access token，喺伺服器交換成綁定該用戶嘅服務通知 token，再用獲批嘅範本呼叫官方發送端點。每次收到回應後，都要保存更新咗嘅 notificationToken：每次成功發送之後，token 值都會輪替，而 remainingCount 會決定嗰次操作仲可以發送幾多則後續訊息。

重點一覽

• 正式環境嘅服務訊息需要已驗證 LINE MINI App，同埋通過審核嘅範本。未驗證應用只可以透過內部 Developing channel，向 Admin 或 Tester 帳號進行測試。
• 一個 LIFF access token 只可以透過 POST /message/v3/notifier/token 簽發一個服務通知 token。取得嘅 token 只屬於一位用戶同一次操作 session。
• 用 POST /message/v3/notifier/send?target=service 發送訊息，之後用回應入面更新咗嘅 notificationToken 取代已儲存嘅舊 token。
• 新簽發嘅 token 會喺一年後到期，一般由五次發送開始。實際獲批嘅使用情境可能有唔同訊息上限，所以執行時應該以 remainingCount 為準。
• 呢套官方流程適用於同 MINI App 操作有關嘅確認、結果同提醒，唔係自由格式嘅客服 inbox，亦唔係推廣群發 API。

簽發通知 token 前嘅必要條件

本教學由資格判斷完成後開始。如果你仲要確認應用可唔可以喺正式環境使用服務訊息，請先睇已驗證同未驗證 LINE MINI App 清單。

實作 token 流程前，請確認以下四項必要條件：

必要條件	必須達到嘅狀態	點解重要
LINE MINI App channel	已完成正式環境驗證	未驗證應用唔可以由 Published channel 發送服務訊息
服務訊息範本	已新增、通過審核，而且狀態係 PUBLISHING	API 只接受通過審核嘅範本名稱同預先定義嘅變數
用戶操作	預約、購買、登記、出貨或其他獲批操作	每則通知都必須確認或回應該項操作
伺服器憑證	Stateless 或短效 channel access token	LINE MINI App channel 唔接受長效憑證或 Channel Access Token v2.1

LINE 建議使用 stateless channel access token，因為應用唔需要自行管理有效期。Channel access token 必須留喺伺服器，切勿回傳畀 MINI App client。

三種 LINE token 有咩分別

只要每種憑證各自負責一項工作，成套實作就會更容易理解：

憑證	來源	證明內容	重要生命週期規則
LIFF access token	MINI App 入面嘅 liff.getAccessToken()	目前 LINE 用戶已授權存取	最長可以有效 12 小時，但用戶關閉應用後可能會被撤銷
Channel access token	伺服器端 LINE 憑證	你嘅 LINE MINI App channel 可以呼叫 API	盡量使用 stateless token，唔好暴露畀瀏覽器
服務通知 token	POST /message/v3/notifier/token	一位用戶符合接收同某次操作相關通知嘅資格	綁定用戶、最長有效一年、有次數限制，而且每次發送後都會更新

一個 LIFF access token 只可以簽發一個服務通知 token。應該喺用戶完成操作後盡快交換：即使 LIFF token 名義上仍未到期，用戶關閉 MINI App 或授予額外權限之後，佢仍然可能失效。

點樣用通知 token 發送 LINE MINI App 服務訊息

1. 喺用戶完成操作後取得 LIFF access token

當 MINI App 入面嘅預約、購買或其他獲批操作成功後，呼叫 liff.getAccessToken()，再透過 HTTPS 將取得嘅值發送去自己嘅 backend。請將呢個 backend request 同內部操作紀錄建立關聯，但唔好將 LIFF token 或稍後取得嘅服務通知 token 寫入應用 log。

瀏覽器唔應該直接呼叫 Service Message API，因為簽發同發送流程仲需要 channel access token。

2. 交換成服務通知 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"
}

將 token 加密後儲存，並一併保存 expiresIn、remainingCount、sessionId 同你自己嘅用戶操作識別碼。唔好將 sessionId 當成用戶身份：服務通知 token 本身已經綁定收件人，而且唔可以畀其他用戶使用。

3. 發送已獲批嘅範本

用 token 呼叫官方發送端點。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 同變數 key。範本名稱格式係 {template name}_{BCP 47 language tag}，長度上限為 30 個字元。服務訊息支援嘅語言 suffix 係 ja、en、zh-TW、th、id 同 ko。即使所選範本冇變數，params 仍然係必填，而且個值必須係 {}。

4. 每次發送後儲存更新咗嘅 token

成功發送後，回應會有另一個 notificationToken、更新咗嘅 expiresIn 同 remainingCount，以及同一個以操作為單位嘅 sessionId。安排下一則提醒前，請用 atomic update 方式更新紀錄。重用之前嘅 token，可能令原本有效嘅後續訊息發送失敗。

如果 expiresIn 同 remainingCount 都係 0，即係 LINE 已經接受目前呢則訊息，但無法更新 token。請將該次操作 session 標記為完成，亦唔好再根據呢次回應安排其他訊息。

儲存同重試清單

服務通知 token 係會輪替嘅憑證，唔係永久嘅用戶地址：

1. 用戶完成符合資格嘅 MINI App 操作時，建立一筆操作紀錄。
2. 只交換 LIFF token 一次，並保存回傳嘅 sessionId、加密 token、有效期同剩餘次數。
3. 發送期間鎖定操作紀錄或使用版本控制，避免兩個 worker 同時使用同一個 token。
4. 收到 HTTP 200 時，先提交更新咗嘅 token 同計數，再將下一則提醒加入 queue。
5. 收到 400 時，先驗證 request body、收件人狀態同範本變數，再重試。
6. 收到 401 時，更新伺服器端 channel 憑證，或者開始新嘅用戶操作流程；唔好持續重送無效嘅 LIFF token 或服務通知 token。
7. 收到 403 時，確認 channel 已獲授權，而且確實範本存在並處於允許狀態。

唔好自行為 LINE 設定固定數字嘅重試政策。官方文件有定義錯誤類型，但冇公布呢個 API 嘅固定 request rate。只有暫時性失敗先可以作有限次重試，亦絕對唔可以將失敗操作變成同原本操作無關嘅通知。

UnifyPort 適合放喺邊一層

請使用 LINE 官方 Service Message API，由 MINI App 發送交易型通知。UnifyPort 唔會簽發或更新 LINE 服務通知 token、唔會提交範本、唔會授予已驗證狀態，亦唔會將普通訊息變成 MINI App 服務訊息。

UnifyPort 適合處理另一條自由格式客服路徑。如果客戶喺交易通知前後開啟普通 LINE 對話，已連接嘅 LINE 帳號可以將該則入站文字訊息以標準 message.received 事件傳入。你嘅客服系統就可以將佢同 WhatsApp、Telegram、Zalo、TikTok 或 X 事件一齊分流，並喺 provider 能力矩陣確認支援嘅情況下使用 POST /v1/messages。

呢個分工同 LINE MINI App 付款及客服 Webhook 指南所講嘅架構相同：官方 MINI App API 負責交易，客戶訊息 pipeline 就負責接收普通對話。要建置後者，請先睇 LINE 授權指南同完整嘅 message.received 事件參考。

限制同取捨

已驗證 MINI App 如果要確認預約、回報結果，或者提醒用戶之前已完成嘅操作，官方服務訊息路徑就係正確選擇。佢可以令通知持續同 LINE 用戶、通過審核嘅範本及獲批使用情境保持關聯。

呢條路徑嘅用途刻意受到限制。每次操作一般最多可以發送五則訊息、範本要經過審核，而且禁止廣告、優惠券、獎賞、產品推廣同一般活動公告。LY Corporation 可能喺審核時批准唔同訊息數量。每個 channel 最多可以設定 20 個範本，訊息用途亦必須持續符合送審時嘅使用情境。

非官方接口無法改變呢啲規則，亦唔可以增加 token 可用次數。另一方面，Service Message API 唔可以取代持續接收自由格式訊息嘅客服 inbox。請喺自己系統用訂單或預約識別碼連接兩套系統，唔好嘗試喺兩者之間共用平台 token。

FAQ

LINE 服務通知 token 嘅有效期有幾長？

新簽發嘅 token 會喺一年後到期，即係 31,536,000 秒。當可發送訊息數量歸零時，佢亦可能提早失效。請一律以 LINE 最新回傳嘅 expiresIn 同 remainingCount 為準。

我可以重用同一個通知 token 發送之後嘅服務訊息嗎？

請使用最近一次成功發送後回傳嘅新版 notificationToken，唔好使用之前嘅值。呢個 token 亦綁定單一用戶，唔可以重用喺其他收件人身上。

每次用戶操作最多可以發送幾多則 LINE MINI App 服務訊息？

每次符合資格嘅用戶操作，標準上限係五則訊息。LINE 可能為特定使用情境批准唔同上限，所以回應入面嘅 remainingCount 先係實際操作上限。

未驗證 LINE MINI App 可以使用通知 token API 嗎？

可以透過內部 Developing channel，用 Admin 或 Tester 帳號測試。要由 Published channel 發送畀正式環境用戶，就必須使用已驗證 LINE MINI App 同通過審核嘅範本。

LINE 服務通知 token 同 Messaging API user ID 係咪一樣？

唔一樣。佢係一項會輪替、綁定用戶嘅授權，只可以用於同一次 MINI App 操作有關嘅服務訊息。佢唔係可重用嘅用戶地址，亦唔係一般 push message 憑證或客服對話身份。

下一步

參考 LINE MINI App API 文件實作官方兩次呼叫流程，並喺每次發送後儲存更新咗嘅 token。如果另一項需求係接收普通 LINE 客戶訊息，請另外使用 UnifyPort LINE 授權指南。

資料來源

以下 LINE 官方來源核對於 2026-07-21：

• Sending service messages
• LINE MINI App API reference
• Running your service: conditions and message-count limits