How to Send LINE MINI App Service Messages With a Notification Token

To send a LINE MINI App service message, capture a fresh LIFF access token after the user’s action, exchange it on your server for a user-bound service notification token, then call the official send endpoint with an approved template. Persist the renewed notificationToken from every response: the token value rotates after each successful send, and its remainingCount controls how many follow-ups remain for that action.

Key takeaways

• Production service messages require a verified LINE MINI App and an approved template. An unverified app can only test through its internal Developing channel with Admin or Tester accounts.
• Issue one service notification token from one LIFF access token with POST /message/v3/notifier/token. The resulting token belongs to one user and one action session.
• Send with POST /message/v3/notifier/send?target=service, then replace the stored token with the renewed notificationToken returned in the response.
• A newly issued token expires after one year and normally starts with five sends. The reviewed use case can have a different message limit, so treat remainingCount as the runtime source of truth.
• This official flow is for confirmations, results, and reminders tied to a MINI App action. It is not a free-form support inbox or a promotional broadcast API.

Prerequisites before you issue a notification token

This tutorial starts after the eligibility decision. If you still need to determine whether your app can use service messages in production, read the verified versus unverified LINE MINI App checklist first.

Before implementing the token flow, confirm all four prerequisites:

Prerequisite	Required state	Why it matters
LINE MINI App channel	Verified for production	Unverified apps cannot send service messages from the Published channel
Service-message template	Added and approved with PUBLISHING status	The API only accepts a reviewed template name and its defined variables
User action	Reservation, purchase, check-in, shipment, or another approved action	Every notification must confirm or respond to that action
Server credentials	Stateless or short-lived channel access token	LINE MINI App channels do not accept long-lived or Channel Access Token v2.1 credentials

LINE recommends stateless channel access tokens because they do not require your application to manage expiration. Keep the channel access token on your server; never return it to the MINI App client.

How the three LINE tokens differ

The implementation is easier to reason about when each credential has one job:

Credential	Where it comes from	What it proves	Important lifecycle rule
LIFF access token	liff.getAccessToken() in the MINI App	The current LINE user granted access	Valid for up to 12 hours, but it can be revoked when the user closes the app
Channel access token	Your server-side LINE credentials	Your LINE MINI App channel may call the API	Use a stateless token when possible; do not expose it to the browser
Service notification token	POST /message/v3/notifier/token	One user is eligible for notifications tied to one action	User-bound, valid for up to one year, count-limited, and renewed after each send

One LIFF access token may issue only one service notification token. Do the exchange promptly after the action: a nominally unexpired LIFF token can still become invalid when the user closes the MINI App or grants additional permissions.

How to send LINE MINI App service messages with a notification token

1. Capture the LIFF access token after the user action

Call liff.getAccessToken() in the MINI App after the reservation, purchase, or other approved action succeeds. Send that value to your own backend over HTTPS. Associate the backend request with your internal action record, but do not write either the LIFF token or the later service notification token to application logs.

The browser should not call the Service Message API directly because issuing and sending also require the channel access token.

2. Exchange it for a service notification token

From your server, call the official issue endpoint:

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}\"}"

A successful response has four fields:

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

Store the token encrypted at rest, along with expiresIn, remainingCount, sessionId, and your own user-action identifier. Do not use sessionId as a user identity: the service notification token already carries the recipient binding, and it cannot be used for another user.

3. Send an approved template

Use the token with the official send endpoint. target=service is a required 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"
  }'

Use the exact templateName and variable keys shown in LINE Developers Console. The template name format is {template name}_{BCP 47 language tag}, with a maximum of 30 characters. The supported service-message language suffixes are ja, en, zh-TW, th, id, and ko. If the selected template has no variables, params is still required and must be {}.

4. Save the renewed token after every send

A successful send returns another notificationToken, plus the updated expiresIn, remainingCount, and the same action-oriented sessionId. Update your record atomically before scheduling a later reminder. Reusing the previous token can make an otherwise valid follow-up fail.

If both expiresIn and remainingCount are 0, LINE accepted the current message but could not renew the token. Mark the action session as complete and do not schedule another send from that response.

A storage and retry checklist

Treat the service notification token as a rotating credential, not as a permanent user address:

1. Create one action record when the user completes the qualifying MINI App action.
2. Exchange the LIFF token once and persist the returned sessionId, encrypted token, expiry, and count.
3. Lock or version the action record while sending so two workers cannot spend the same token concurrently.
4. On HTTP 200, commit the renewed token and counters before enqueueing the next reminder.
5. On 400, validate the body, recipient state, and template variables before retrying.
6. On 401, refresh the server-side channel credential or start a new user-action flow; do not keep replaying an invalid LIFF or service notification token.
7. On 403, verify that the channel is authorized and the exact template exists in an allowed status.

Do not invent a numeric retry policy for LINE. The official documentation defines the error classes but does not publish a fixed request rate for this API. Use bounded retries only for transient failures, and never turn a failed action into an unrelated notification.

Where UnifyPort fits

Use LINE’s official Service Message API for transactional notifications from a MINI App. UnifyPort does not issue or renew LINE service notification tokens, submit templates, grant verified status, or turn an ordinary message into a MINI App service message.

UnifyPort fits the separate free-form support path. If a customer opens a normal LINE conversation before or after the transactional notification, a connected LINE account can deliver that inbound text as a standard message.received event. Your support system can then route it alongside WhatsApp, Telegram, Zalo, TikTok, or X events and use POST /v1/messages where the provider capability matrix confirms support.

That separation is the same architecture described in the LINE MINI App payments and support-webhook guide: official MINI App APIs own the transaction, while a customer-message pipeline owns ordinary conversation intake. For the latter, start with the LINE authorization guide and the exact message.received event reference.

Limitations and trade-offs

The official service-message route is the right choice when a verified MINI App must confirm a reservation, report a result, or remind a user about an action they already completed. It keeps the notification tied to the LINE user, reviewed template, and approved use case.

It is deliberately narrow. Each action normally permits up to five messages, templates are reviewed, and advertising, coupons, rewards, product promotion, and general event announcements are prohibited. LY Corporation may assign a different count during review. A channel may configure up to 20 templates, and the message purpose must continue to match the submitted use case.

An unofficial interface cannot change those rules or extend the token count. Conversely, the Service Message API does not replace an open-ended customer-support inbox. Keep the two systems joined by your own order or reservation identifier rather than attempting to share platform tokens between them.

FAQ

How long does a LINE service notification token last?

A newly issued token expires after one year, or 31,536,000 seconds. It can become unusable earlier when its message count reaches zero. Always rely on the latest expiresIn and remainingCount returned by LINE.

Can I reuse the same notification token for a later service message?

Use the renewed notificationToken returned by the most recent successful send, not the previous value. The token is also bound to one user and cannot be reused for another recipient.

How many LINE MINI App service messages can I send per user action?

The standard maximum is five messages for one qualifying user action. LINE may approve a different limit for a particular use case, so the response’s remainingCount is the operational limit.

Can an unverified LINE MINI App use the notification token API?

It can test through the internal Developing channel with Admin or Tester accounts. Sending from the Published channel to production users requires a verified LINE MINI App and approved templates.

Is a LINE service notification token the same as a Messaging API user ID?

No. It is a rotating, user-bound authorization for service messages tied to one MINI App action. It is not a reusable user address, a general push-message credential, or a support-chat identity.

Next step

Implement the official two-call flow against the LINE MINI App API reference, storing the renewed token after every send. If your separate requirement is to receive ordinary LINE customer messages, use the UnifyPort LINE authorization guide as the secondary path.

Sources

Official LINE sources checked on 2026-07-21:

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