LINE Reply Token Expired? Handle Slow Replies Without Duplicate Sends
A LINE Messaging API replyToken is single-use and must be used within one minute after receiving the webhook; use beyond that interval is not guaranteed. If an AI task or queue delays the response, do not keep resending the token or automatically switch to push after a timeout. First separate a token that was never used from a reply whose outcome is unknown, then make an explicit sending decision.
Key takeaways
- A reply token is a short-lived response opportunity, not a recipient ID or reusable credential.
- Webhook redelivery does not create a second independent reply opportunity.
- A send timeout means an unknown outcome, not proof that nothing was sent.
- Push is a separate operation with recipient and message-count rules—not a token refresh.
What LINE actually guarantees about reply tokens
The Messaging API reference defines POST /v2/bot/message/reply. Its request uses the event’s replyToken and a messages array. Tokens can only be used once and should be used as soon as possible. LINE explicitly warns that the time limit can change; do not design a worker to wait until the last second.
This also means an immediate “We’re checking” reply consumes the token. The later answer cannot reuse it. If several message objects belong in the immediate response, LINE’s sending guide permits up to five in one reply request; that is not permission for five separate requests with the same token.
Keep three values separate:
| Value | Purpose | Not a substitute for |
|---|---|---|
| Channel access token | Authenticate the channel’s API request | A fresh reply token |
replyToken | Reply to the triggering event | A permanent user address |
| Recipient identifier | Address an eligible push destination | Permission to reuse the reply operation |
If you are actually handling a LINE MINI App notification, stop here and use the service messages vs Messaging API comparison. A service notification token belongs to a different API contract.
Diagnose the failed reply before choosing a fallback
These are recommended application checks, not additional LINE error codes.
| Evidence | Likely boundary to investigate | Safe next action |
|---|---|---|
| Worker starts long after webhook receipt | Queue delay or slow generation | Do not rely on the old token; evaluate a separate delayed response |
| Another worker already received a successful reply response | Single-use token consumed | Stop the duplicate job |
| HTTP request timed out after dispatch | Acceptance is unknown | Preserve uncertainty; do not immediately push the same answer |
| The same webhook arrives again | Duplicate intake | Look up the original event’s processing and send state |
| Request fails even with a newly received event | Payload, channel credentials, token selection, or another API error | Inspect the actual response and request context rather than calling every failure expiry |
Record receipt time, worker-start time, dispatch time, returned HTTP status, and whether an earlier attempt succeeded. Keep tokens and authorization headers out of general logs. Retain protected token material only as needed for the short-lived operation.
An error alone does not tell you whether your other worker already sent the answer. Likewise, rotating a channel access token cannot make a consumed reply token reusable.
Redelivery is not a token-refresh service
LINE’s webhook receiving guide says redelivery preserves the webhook event ID and reply token; deliveryContext.isRedelivery changes. Use webhookEventId to detect duplicate events, with the channel identity in your application’s key.
The reference allows a redelivered webhook’s reply token to be used within one minute after that redelivery, subject to exceptions: it cannot be used if already used, or if 20 minutes have passed since the event occurred. This is a recovery allowance, not a scheduled reply window or a reason to reject webhooks deliberately.
Store the event durably and acknowledge intake independently of slow work. A repeated webhook must consult the existing job rather than start another AI generation and another send. Persist send state too: deduplicating event receipt alone does not protect a job that is retried after a worker crash.
Choose the slow-response path before starting the task
For a quick answer, let one worker own the event and dispatch the reply promptly. For work that may outlast the reply opportunity, decide in advance whether to send a short acknowledgement and deliver the result later, or send only the later result.
Use the following application design:
- Claim the event once. Associate the channel and
webhookEventIdwith one business operation. A unique record or transactional claim prevents two workers from independently sending. - Save the sending decision. Distinguish an immediate reply from a later push. An acknowledgement is a completed reply, not a reservation of the token.
- Track the outcome honestly. Separate not attempted, accepted, rejected, and unknown in local state. These are application labels, not LINE response fields. A process crash after dispatch can leave the outcome unknown.
- Gate delayed sends. Recheck whether the result is still relevant, whether someone already answered, and whether the recipient meets LINE’s current push conditions. Require an explicit decision for an unknown earlier outcome.
- Persist the push as a new operation. If push is chosen, use its own request and safeguards. It does not alter the previous reply’s result.
LINE’s pricing documentation distinguishes message counts: reply messages are not counted toward the subscription-plan message count, while push messages are. Check the applicable plan rather than assuming fallback has the same accounting.
For supported push retries, follow the X-Line-Retry-Key guide. LINE’s retry documentation lists push, multicast, narrowcast, and broadcast—not reply—as supported methods. Adding that header to a reply request does not extend its token or deduplicate a later push against it.
Keep the UnifyPort reply contract separate
UnifyPort’s unofficial interface is a separate connected-account path, not a repair mechanism for a LINE Official Account reply token. Its text-message reference uses POST /v1/messages with account_id, to, and message. The provider support matrix documents LINE text sending, but the token-based quoted-reply operation is currently WhatsApp-only.
Do not put LINE’s replyToken into UnifyPort’s reply_to.reply_token. Similar names do not mean interchangeable credentials. For an ordinary response to a stored normalized event, use the documented account and conversation identifiers and check the actual send result. No cross-API idempotency or token recovery is implied.
Stay with the official Messaging API when the sender must be your LINE Official Account. Changing the integration identity is not a safe automatic fallback for an uncertain official send.
FAQ
Can I refresh an expired LINE reply token?
Do not treat it as a refreshable access credential. New qualifying events carry reply opportunities; redelivery follows the limited rules above. Neither supplies unlimited retries for the same business answer.
Can I send an acknowledgement now and the final answer with the same token?
No. The first accepted reply consumes the single-use token. Plan the later response separately and check push eligibility and message counts.
Should every reply timeout trigger a push message?
No. The reply may already have been accepted. An automatic push can duplicate it. Preserve the unknown outcome and require a deliberate fallback policy.
Next step and sources
Review one slow-response workflow against the LINE Messaging API reference. Test duplicate delivery, two competing workers, acknowledgement followed by a delayed result, and a lost HTTP response with local mocks. These are proposed tests, not reported production results. For the separate connected-account route, start with the UnifyPort text-send contract.
Official references checked on 2026-10-04:
Turn messaging integration into a stable product pipeline.
Start by sending through one API, then bring every inbound message back into your business system with standard events.