LINE Rich Menu Insights Are Analytics, Not an Inbound Router
On July 1, LINE announced that developers can retrieve rich menu statistics created through the Messaging API: total displays, total clicks, and day-level insight data. A month earlier, LINE had also confirmed a very different change on the same product surface: the rate limit for the Get rich menu list endpoint moved from 2,000 requests per second to 10 requests per second as of May 26, 2026.
Both changes are reasonable when you read them as analytics and configuration updates. Product teams want to know which rich menu tab gets tapped. Operations teams want to audit which menu is published. Neither workflow needs to run in the critical path for customer support. The risk starts when a small team treats the official LINE Messaging API as a live routing layer and builds polling loops around endpoints that were never meant to decide where every incoming message should go.
If your job is to receive LINE messages, route them into Slack or a CRM, and later add WhatsApp or Zalo, the architecture should have two separate loops: one slow loop for official LINE analytics, and one event-driven loop for inbound conversations.
What Changed In LINE
The July 1 update adds two official insight endpoints for rich menus created with the Messaging API: Get rich menu insight totals and Get rich menu insight by day. Previously, those statistics were only visible in LINE Official Account Manager for rich menus created there. With the new endpoints, a team that creates rich menus through the Messaging API can pull reporting data without opening a manual dashboard.
The May 26 update is more operational. LINE changed the rate limit for Get rich menu list from 2,000 requests per second to 10 requests per second. LINE stated that no other endpoint rate limits changed in that notice.
The important part is not whether 10 requests per second is enough for your dashboard. It probably is. The important part is that rich menu metadata is now clearly a cached configuration surface, not a high-frequency dependency. If your app checks rich menu state every time a user sends a message, the design is backwards.
Three Loops, Three Speeds
A LINE support stack usually mixes three concerns that should not share the same timing.
Analytics loop. Product and marketing teams read rich menu totals and daily clicks. This can run hourly or daily. It can retry later. It can tolerate delays because it answers questions like “Which menu tab drove more taps yesterday?”
Configuration loop. Engineering reads the current rich menu list, stores the menu IDs, and updates internal state when a menu changes. This should be cached. The new 10 rps limit is a reminder that configuration reads belong outside the message path.
Inbound routing loop. Support needs to know that a customer just sent a message, which account received it, who sent it, what text or media arrived, and where to route it. This loop should be event-driven. It should not wait for a rich menu list call, an insight call, or a dashboard refresh.
UnifyPort sits in the third loop. It does not replace LINE’s official analytics endpoints. It gives teams a webhook-first inbound layer for LINE, WhatsApp, Telegram, TikTok, Zalo, and X, using the same standard event shape across providers.
The Inbound Path
With UnifyPort, a LINE message arrives as a message.received webhook event. The delivery is an HTTP POST to your endpoint. The envelope uses the same fields across supported providers: id, type, provider, account_id, occurred_at, and data.
An inbound LINE text message can be handled like this:
{
"id": "evt_4f1b9c2a70",
"type": "message.received",
"provider": "line",
"account_id": "acc_8c21d0",
"occurred_at": "2026-07-04T02:18:30Z",
"data": {
"conversation": { "id": "U4af2c891", "type": "user" },
"sender": { "id": "U4af2c891", "type": "user", "name": "Mika Tanaka" },
"message": {
"id": "msg_20260704_001",
"type": "text",
"text": "Can you check whether my appointment moved to Monday?",
"direction": "inbound",
"sent_at": "2026-07-04T02:18:29Z"
},
"event": { "kind": "message_received" }
}
}Your webhook endpoint can subscribe to message.received or use ["*"] for the full standard event catalogue. If you enable signing, each delivery includes X-Device-Timestamp and X-Device-Signature. The signature is a hex-encoded HMAC-SHA256 over the timestamp, a dot, and the raw request body, signed with the endpoint’s signing_secret.
That gives the routing service a clean rule: verify the signature, deduplicate by the event ID, store the payload you need, then route the message. Rich menu insight calls do not belong in this path.
Where Official LINE Insights Still Fit
The new insight endpoints are useful. They just answer a different question.
Use them to report whether the “Support” area of a rich menu gets clicked more than the “Pricing” area. Use them to compare weekday and weekend engagement. Use them to decide whether a seasonal menu should stay live. Keep the schedule slow: daily for business reporting, maybe hourly during a campaign.
Do not use them to infer whether a user is waiting for support. A click on a rich menu is not the same as a message. A daily insight report is not a queue. A configuration endpoint with a 10 rps limit is not a routing primitive.
The simplest split is:
| Concern | Best source | Timing |
|---|---|---|
| Rich menu display and click reporting | LINE rich menu insight endpoints | Hourly or daily |
| Current rich menu configuration | LINE rich menu list endpoint | Cached, outside hot path |
| Live customer message | UnifyPort message.received webhook | Immediate event |
| Cross-platform routing | UnifyPort standard webhook envelope | Same handler for each provider |
This split also makes the team less fragile. If an analytics job fails, the support queue still receives messages. If a rich menu report is delayed, the CRM still logs every inbound conversation. If you add WhatsApp or Zalo later, the routing loop stays the same and the analytics loop remains LINE-specific.
A Practical Architecture
For a small support team, the architecture can stay boring.
Register a UnifyPort webhook endpoint with a signing_secret and subscribe it to message.received. In the handler, verify X-Device-Signature, store the raw event, and route by provider, account_id, data.sender.id, and data.message.type.
Run a separate scheduled job for official LINE rich menu reporting. That job calls the insight endpoints, writes the metrics to a warehouse or spreadsheet, and never blocks inbound routing. It can also refresh the cached rich menu list, but the cache should be read-only from the support handler.
When the support team needs to reply, the outbound path is still explicit: send through POST /v1/messages with the target account and message body. The inbound event remains the source of truth for who said what and when.
The result is a cleaner operating model:
- LINE official APIs keep ownership of LINE-specific analytics.
- UnifyPort handles normalized inbound delivery across providers.
- The support backend never polls official configuration endpoints in the message path.
- Adding another messaging app changes data, not architecture.
The Real Lesson
LINE’s July 1 insight update is good news for teams that care about rich menu performance. The May 26 rate-limit change is a useful boundary marker: do not treat rich menu configuration as live message infrastructure.
If your LINE work is mainly marketing analytics, use the new official insight endpoints. If your work is customer operations, make inbound messages event-driven. And if your team already receives customer messages across LINE, WhatsApp, Zalo, Telegram, TikTok, or X, use a single webhook shape so every platform lands in the same routing pipeline.
Analytics can be polled. Customer messages should arrive.