LINE Loading Animation Not Showing? Check the Chat and Timing

A LINE loading animation appears only in a one-on-one chat between a user and a LINE Official Account, while the user is viewing that chat. Request it with POST /v2/bot/chat/loading/start. If the user is elsewhere, LINE does not send a notification or save the animation for their next visit. A successful request alone therefore cannot prove the user saw it.

Key takeaways

• Use the user’s ID as chatId, not a group ID or a reply token.
• The animation disappears after the requested duration or when a new message from the Official Account arrives.
• Another loading request while it is visible replaces the remaining display duration; it does not report task progress.
• Treat the indicator as optional feedback, separate from webhook acknowledgement, job completion, and sending the answer.

What LINE’s loading animation actually displays

The official loading-animation guide documents a display duration of 5–60 seconds. It supports one-on-one chats, not group or multi-person chats.

There are three separate clocks in an integration:

Clock	What it controls	What it does not establish
Animation duration	How long the visual indicator remains eligible to display	Whether your worker is still running
Application job lifetime	How long your system processes a request	Whether the user is watching the chat
Reply opportunity	Whether the official reply operation can still be used	Whether an animation is visible

Do not make the animation your job monitor. Likewise, a disappearing indicator is not proof that an AI task failed: its timer may have elapsed, or an Official Account message may have arrived.

For actual reply failures, use the separate LINE reply-token and slow-response guide. Calling the loading endpoint does not document any extension or renewal of a reply token.

Make one controlled display request

Prepare a Messaging API channel access token on your backend and a user ID from the intended channel’s one-on-one interaction. Keep the token out of browser code and shared logs.

This illustrative Node.js function uses the endpoint and body fields from the Messaging API reference. Supply your actual channel token and user ID; the example is not a reported integration test.

async function showLoading(channelAccessToken, userId) {
  const response = await fetch(
    'https://api.line.me/v2/bot/chat/loading/start',
    {
      method: 'POST',
      headers: {
        Authorization: `Bearer ${channelAccessToken}`,
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({
        chatId: userId,
        loadingSeconds: 5
      })
    }
  );
  if (!response.ok) {
    throw new Error(`Loading request failed: ${response.status}`);
  }
}

For the first test, keep the chat open on the user’s LINE app and avoid sending another Official Account message during the display interval. Record the HTTP outcome separately from what the tester observes. Do not interpret a successful HTTP result as a read receipt.

The function intentionally does not retry or send an answer. A cosmetic request failure should not automatically create a second business job or delay an already prepared response.

Diagnose an invisible or short-lived indicator

Observation	Check first	Recommended response
Nothing appears in a group	Unsupported chat surface	Do not keep retrying with the group ID
Nothing appears while the user is outside the chat	User is not viewing the target chat	Repeat a controlled test with the chat open
Opening the chat afterward shows nothing	Animations are not deferred notifications	Do not promise an indicator on the next visit
Indicator disappears when an acknowledgement message arrives	Official Account messages end the display	Choose whether text acknowledgement or animation should come first
Indicator lasts longer than expected	Another loading request may have replaced the timer	Inspect calls from all workers and tools
HTTP request fails	Credentials, target, request body, and actual API response	Diagnose the request before changing the UI logic

These are investigation branches, not invented LINE error codes. For overlapping tools, the one Official Account, multiple tools checklist helps identify who owns each request. Avoid independent workers repeatedly refreshing the same visual feedback.

Keep the loading timer outside the business workflow

Recommended application design:

1. Authenticate and durably record inbound work before relying on any UI feedback.
2. Let one job own the response decision. Request a short animation only when useful for an eligible one-on-one interaction.
3. Run the task independently. An animation failure must not discard stored work.
4. When the result is ready, use the appropriate sending operation. Do not wait for the animation to expire before answering.
5. If processing takes longer, use an explicit delayed-response policy rather than an endless loading loop.

If another loading request is made while the animation is visible, LINE says the second request overrides the time until it disappears. That is a display rule, not a mechanism for extending server-side processing or reserving a reply opportunity.

Where UnifyPort fits—and where it does not

UnifyPort’s unofficial interface is a separate connected-account path. Its LINE authorization guide describes QR authorization, not attaching a channel access token to an Official Account.

The current public provider action matrix does not expose this loading-animation operation. Do not invent a typing endpoint or put chatId and loadingSeconds into a normalized send request. UnifyPort’s text-send reference instead uses POST /v1/messages with account_id, to, and message.

Use the official Messaging API when this Official Account animation is a requirement. For a connected-account inbox, show processing state in your own operator interface and use only documented sending capabilities; that local status is not a LINE chat animation.

FAQ

Can I show the animation in a LINE group?

No. LINE documents it for one-on-one chats with an Official Account, not group or multi-person chats.

Will users receive a notification if they are not looking at the chat?

No. The animation request does not notify them, and opening the chat later does not display that earlier request.

Does loadingSeconds extend the reply token?

No such behavior is documented. Keep the visual timer and the reply operation separate.

Why did it stop before the requested duration?

A new message from the Official Account ends the animation. Check that alongside the timer and any competing requests.

Next step and sources

Test the display conditions against the official loading-animation guide. If you use UnifyPort instead, check the provider action matrix before designing a customer-facing control.

Official references checked on 2026-10-20:

• LINE: Display a loading animation
• LINE: Messaging API reference
• UnifyPort: LINE authorization