unifyport

Posted on Jul 28 • Originally published at unifyport.ai

Before You Submit a LINE MINI App Service Message Template: A Review Checklist

#api #tutorial #webdev

Passing a simulator test does not mean a LINE MINI App service message is ready for production.

A production service message must pass three separate gates:

Your LINE MINI App must be verified.
The service message template must pass review.
Your application must supply a valid service notification token at runtime.

This checklist helps you catch review and implementation problems before they delay your release.

1. Understand the three production gates

Treat verification, template review, and runtime delivery as separate controls.

Gate	What it checks
MINI App verification	Whether the service can use service messages in production
Template review	Whether the message content and use case comply with LINE requirements
Runtime token	Whether the message can be sent for the correct user action

An unverified MINI App can test service messages only through a Developing channel with users who have an Admin or Tester role.

Even after a template passes review, delivery can still fail if the service notification token is missing, expired, already used incorrectly, or unrelated to the current user action.

2. Know the template states

The template status in the LINE Developers Console is an operational signal, not just a label.

Status	Meaning
`DEVELOPING`	Review has not been requested. The template is available only for development testing.
Under review	The submitted template is being evaluated. Some template operations are restricted.
`PUBLISHING`	The template passed review and can be used in production after the MINI App is verified.

While a template is under review, you can inspect it and run simulator tests, but you cannot freely add templates, delete them, or edit their Use Case.

Plan your complete template set before requesting review.

3. Start from the user action

A service message should confirm, report the result of, or remind the user about an action they performed in the MINI App.

Good use cases include:

Confirming a reservation
Reporting a payment result
Sending a delivery update
Reminding a user about an upcoming appointment
Reporting that a submitted request has completed

A weak use case would be:

Send customers information about available products.

A stronger version would be:

After a customer completes a delivery booking, send a confirmation containing the booking number, delivery date, and status page link.

The second version identifies:

The triggering action
The recipient
The delivery timing
The message purpose
The expected content

Promotional messages, discounts, coupons, shopping rewards, new-product announcements, and general event announcements are not appropriate service-message use cases.

4. Document the entire message sequence

Do not review each message in isolation.

Document the sequence from the triggering action to the final service message:

User completes an action
        ↓
MINI App receives a service notification token
        ↓
Backend stores the token securely
        ↓
Backend selects an approved template
        ↓
Service message is sent
        ↓
Renewed token and remaining count are processed

For each message, record:

Triggering user action
Delivery timing
Template name
Language
Variable source
Destination link
Expected next user action

LINE normally permits up to five service messages for one user action, although the reviewed limit may differ by use case.

5. Choose the template and language early

LINE provides predefined service message templates. A channel can register up to 20 templates.

Supported template languages include:

Japanese
English
Traditional Chinese
Thai
Indonesian
Korean

Choose the required language variants before review. Adding or changing template information later can require another review.

For API requests, use the exact template name displayed in the LINE Developers Console. The effective name includes the template name and its BCP 47 language tag.

Do not reconstruct or translate the identifier in application code.

For example:

{
  "templateName": "delivery_result_en"
}

Treat templateName as an approved configuration value rather than a label generated at runtime.

6. Validate every variable

For every variable, confirm:

Its value comes from the action described in the Use Case
It is available when the message is sent
It cannot contain unexpected HTML or formatting
Its fallback behavior is defined
Its maximum length is enforced before the API call

LINE applies different recommendations and limits depending on the variable type.

Variable type	Recommended	Soft limit	Hard limit
Detailed	10 grapheme clusters	36	50
Simple	32 grapheme clusters	100	150

A grapheme cluster is closer to a user-perceived character than a raw byte or code point. Emoji and combined Unicode characters make this distinction important.

Your preflight validation should therefore use Unicode-aware length checks.

If a template contains no variables, send an empty params object rather than inventing placeholder values:

{
  "templateName": "booking_confirmation_en",
  "params": {}
}

7. Review button behavior

For templates containing buttons:

The first button is required
Additional buttons may be optional
Each button must use a permanent link
The destination must be available after the message is delivered
The link should take the user directly to the relevant result or next action

Avoid temporary URLs that expire before the user opens the message.

Also test:

Whether the link opens the expected MINI App page
Whether authentication state is handled correctly
Whether an invalid or completed record has a safe fallback
Whether the page still works when opened later from message history

8. Use the simulator as a content test

Before submission, preview every language variant in the simulator.

Check:

Long customer names
Long order or reservation identifiers
Emoji and combined characters
Empty optional values
Date and time formats
Currency formats
Button-label truncation
Permanent-link destinations
Differences between language variants

The simulator helps validate layout and content. It does not prove that the template is approved or that production token handling works.

9. Freeze the review package

Before requesting review, prepare one review package containing:

Final template list
Languages
Use Case
Message sequence
Variable definitions
Example values
Permanent links
Screenshots or simulator results
Runtime template identifiers

A compact internal record might look like this:

{
  "templateName": "delivery_result_en",
  "approvedUseCase": "Send the delivery result after the user completes a booking",
  "actionType": "delivery_booking",
  "variables": [
    "order_id",
    "delivery_status"
  ],
  "permanentLink": "https://miniapp.line.me/example",
  "reviewStatus": "PUBLISHING"
}

Freezing this information reduces the risk that the reviewed template differs from the implementation shipped by another team.

10. Prepare the production handoff

Before enabling production traffic, verify all of the following:

The MINI App is verified
The required template status is PUBLISHING
The backend uses the exact reviewed templateName
Each token is associated with the correct user action
Tokens are not exposed in application logs
Renewed tokens are stored correctly
remainingCount is checked when planning follow-up messages
Retries cannot accidentally duplicate a service message
Failures are observable without logging sensitive token values

Template approval and runtime token management solve different problems. Both must be tested.

11. Control changes after approval

After the LINE MINI App is verified, changes to service message template information require re-review.

Before modifying a reviewed template, compare:

Triggering action
Delivery timing
Message purpose
Text content
Variables
Language variants
Button labels
Permanent links
Message sequence

Do not treat a text or URL adjustment as automatically safe just because the overall business flow has not changed.

Final pre-submission checklist

[ ] The Use Case begins with a specific user action
[ ] The message is transactional, not promotional
[ ] The full message sequence is documented
[ ] The channel remains within the 20-template limit
[ ] Every required language variant is ready
[ ] Every variable has a source, limit, and fallback
[ ] Unicode-aware length validation is implemented
[ ] The first button and every permanent link have been tested
[ ] Long and empty values have been tested in the simulator
[ ] Runtime code uses the exact console template name
[ ] The review package matches the implementation
[ ] Production token storage, renewal, and retry behavior have been tested
[ ] The team understands which future changes require re-review

Official references

Originally published on UnifyPort.

This article was prepared with AI assistance for language and structure, then technically reviewed and verified by the author.

DEV Community