如何使用通知權杖傳送 LINE MINI App 服務訊息

若要傳送 LINE MINI App 服務訊息，請在使用者完成操作後取得最新的 LIFF access token，於伺服器端交換成綁定該使用者的服務通知權杖，再使用已核准的範本呼叫官方傳送端點。每次收到回應後，都要保存更新後的 notificationToken：每次成功傳送後，權杖值都會輪替，而 remainingCount 會決定該次操作還能傳送多少則後續訊息。

重點整理

• 正式環境的服務訊息需要已驗證的 LINE MINI App，以及審查通過的範本。未驗證的應用程式只能透過內部 Developing channel，向 Admin 或 Tester 帳號進行測試。
• 一個 LIFF access token 只能透過 POST /message/v3/notifier/token 簽發一個服務通知權杖。取得的權杖只屬於一位使用者與一次操作工作階段。
• 使用 POST /message/v3/notifier/send?target=service 傳送訊息，之後以回應中的新版 notificationToken 取代已儲存的舊權杖。
• 新簽發的權杖會在一年後到期，通常一開始可傳送五則訊息。實際審核通過的使用情境可能採用不同上限，因此執行時應以 remainingCount 為準。
• 這套官方流程適用於與 MINI App 操作相關的確認、結果和提醒，不是自由格式的客服收件匣，也不是促銷群發 API。

簽發通知權杖前的必要條件

本教學從資格判斷完成後開始。如果你仍要確認應用程式能否在正式環境使用服務訊息，請先閱讀已驗證與未驗證 LINE MINI App 檢查清單。

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

必要條件	必須達到的狀態	重要原因
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 用戶端。

三種 LINE 權杖有何不同

只要讓每種憑證各司其職，整套實作就更容易理解：

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

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

如何使用通知權杖傳送 LINE MINI App 服務訊息

1. 在使用者完成操作後取得 LIFF access token

當 MINI App 內的預約、購買或其他核准操作成功後，呼叫 liff.getAccessToken()，再透過 HTTPS 將取得的值傳送至自己的後端。請將這項後端請求與內部操作紀錄建立關聯，但不要把 LIFF token 或稍後取得的服務通知權杖寫入應用程式 log。

瀏覽器不應直接呼叫 Service Message API，因為簽發與傳送流程還需要 channel access token。

2. 交換成服務通知權杖

從伺服器呼叫官方簽發端點：

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 當成使用者身分：服務通知權杖本身已綁定收件者，且不能用於其他使用者。

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 和變數 key。範本名稱格式為 {template name}_{BCP 47 language tag}，長度上限為 30 個字元。服務訊息支援的語言 suffix 為 ja、en、zh-TW、th、id 與 ko。即使選用的範本沒有變數，params 仍為必填，而且值必須是 {}。

4. 每次傳送後儲存更新的權杖

成功傳送後，回應會包含另一個 notificationToken、更新後的 expiresIn 和 remainingCount，以及同一個以操作為單位的 sessionId。安排下一則提醒前，請以不可分割的方式更新紀錄。重複使用先前的權杖，可能會讓原本有效的後續訊息傳送失敗。

如果 expiresIn 和 remainingCount 都是 0，表示 LINE 已接受目前這則訊息，但無法更新權杖。請將該次操作工作階段標記為完成，也不要再依據這次回應安排其他訊息。

儲存與重試檢查清單

服務通知權杖是會輪替的憑證，不是永久的使用者地址：

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

不要自行替 LINE 設定固定的數字重試政策。官方文件有定義錯誤類型，但沒有公布這個 API 的固定 request rate。只有暫時性失敗才能進行有上限的重試，也絕不能把失敗的操作轉成與原操作無關的通知。

UnifyPort 扮演的角色

請使用 LINE 官方 Service Message API，從 MINI App 傳送交易型通知。UnifyPort 不會簽發或更新 LINE 服務通知權杖、不會提交範本、不會授予已驗證狀態，也不會把一般訊息變成 MINI App 服務訊息。

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

這項分工與 LINE MINI App 付款及客服 Webhook 指南說明的架構相同：官方 MINI App API 負責交易，客戶訊息管線則負責一般對話的接收。若要建置後者，請先閱讀 LINE 授權指南和完整的 message.received 事件參考。

限制與取捨

已驗證的 MINI App 若要確認預約、回報結果，或提醒使用者先前已完成的操作，官方服務訊息路徑就是正確選擇。它會讓通知持續與 LINE 使用者、審查通過的範本及核准使用情境保持關聯。

這條路徑的用途刻意受到限制。每次操作通常最多可傳送五則訊息、範本需要審查，而且禁止廣告、優惠券、獎勵、產品促銷與一般活動公告。LY Corporation 可能在審查時核定不同的訊息數量。每個 channel 最多可設定 20 個範本，訊息用途也必須持續符合送審時的使用情境。

非官方接口無法改變這些規則，也不能增加權杖可用次數。另一方面，Service Message API 並不能取代可持續接收自由格式訊息的客服收件匣。請在自己的系統中使用訂單或預約識別碼串連兩套系統，而不要試圖在兩者之間共用平台權杖。

FAQ

LINE 服務通知權杖的有效期有多長？

新簽發的權杖會在一年後到期，也就是 31,536,000 秒。當可傳送訊息數量歸零時，它也可能提早失效。請一律以 LINE 最新回傳的 expiresIn 和 remainingCount 為準。

我可以重複使用同一個通知權杖傳送後續服務訊息嗎？

請使用最近一次成功傳送後回傳的新版 notificationToken，不要使用先前的值。這個權杖也綁定單一使用者，不能重複用於其他收件者。

每次使用者操作最多可以傳送多少則 LINE MINI App 服務訊息？

每次符合資格的使用者操作，標準上限是五則訊息。LINE 可能為特定使用情境核准不同上限，因此回應中的 remainingCount 才是實際操作上限。

未驗證的 LINE MINI App 可以使用通知權杖 API 嗎？

可以透過內部 Developing channel，使用 Admin 或 Tester 帳號進行測試。若要從 Published channel 傳送給正式環境使用者，必須採用已驗證的 LINE MINI App 和審查通過的範本。

LINE 服務通知權杖和 Messaging API user ID 相同嗎？

不同。它是一項會輪替、綁定使用者的授權，只能用於與某次 MINI App 操作相關的服務訊息。它不是可重複使用的使用者地址，也不是一般 push message 憑證或客服聊天身分。

下一步

參考 LINE MINI App API 文件實作官方兩次呼叫流程，並在每次傳送後儲存更新的權杖。如果另一項需求是接收一般 LINE 客戶訊息，請另外使用 UnifyPort LINE 授權指南。

資料來源

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

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