LINE Webhook standby Mode: Why replyToken Is Missing

If a LINE webhook event has mode: standby, receiving it does not mean your channel should answer. LINE’s module-channel documentation says a standby channel should not send messages, and its webhook events do not contain replyToken. This is a Chat Control ownership condition—not evidence of token expiry or failed webhook delivery. Inspect the event’s mode and the integration type before attempting a reply.

Key takeaways

• A standby event can be successfully received while the channel is not the responder.
• Do not turn a missing replyToken into an automatic push-message fallback.
• Module channels are a specific corporate integration feature, not a generic setting for every bot.
• Keep event intake, responder ownership, and send outcomes as separate application decisions.

What LINE webhook active and standby mean

The official module-channel Messaging API guide instructs integrations to inspect mode before responding. In the documented module arrangement, only one of the attached channels is active; the others are standby.

Event mode	Documented meaning	Application decision
active	The receiving channel has chat initiative and can send replies or push messages	Evaluate the event type and normal sending conditions before replying
standby	The receiving channel is waiting; its events lack replyToken	Receive and process permitted internal work, but suppress customer-facing sends
Missing or unfamiliar	Your integration has not established the expected contract	Investigate the original payload and parser; do not assume active

The last row is a recommended defensive policy, not an additional LINE mode. Likewise, active does not mean every event type carries a reply token or requires a response. Check the event definition in the Messaging API reference.

This is not the same question as connecting several ordinary tools to one Messaging API channel. The multiple-tools checklist covers shared credentials, webhook ownership, and quotas. A module-channel arrangement adds a different question: which channel currently has the initiative to answer?

Confirm that Module documentation applies

LINE describes Module functions as available to corporate customers who have completed the prescribed applications. Do not design an ordinary bot around an assumed entitlement to attach a module or call Chat Control operations.

The Chat Control guide also warns that the currently offered module channel automatically acquires initiative when attached, described as Default Active, and normally needs no manual initiative control. Therefore, discovering this documentation is not a reason to add acquire/release calls to every webhook handler.

First identify your actual arrangement:

1. Record which Official Account, receiving channel, and vendor integration the request belongs to.
2. Confirm with the integration owner whether an attached module is involved.
3. Inspect a securely retained original event rather than only a transformed queue record.
4. Compare mode and replyToken presence before and after your parser.
5. Ask the responsible module provider to investigate unexpected ownership; avoid changing tokens or webhook URLs without evidence.

Keep channel credentials and reply tokens out of routine logs. Diagnostic records can note token presence without retaining its value.

Diagnose absence before investigating expiry

A missing token, an expired token, and a lost send response lead to different actions.

Observation	What to investigate	What not to do
Original event has mode: standby and no token	Chat initiative and the expected responder	Manufacture a token or send push automatically
Original event contains a token, but the worker sees none	Parser, serialization, and queue mapping	Change channel ownership to fix a data transformation bug
Active event has no token	The specific event schema and integration context	Assume every webhook must be replyable
Token exists but the reply fails	The actual API response, token use, and processing delay	Label every failure as standby
Send request timed out	Whether acceptance is unknown	Immediately send the same answer through another operation

When a real token was received but used too late or more than once, continue with the LINE reply-token troubleshooting guide. That is a different recovery path from an event that intentionally had no token.

Separate observation from permission to answer

Recommended receiver design starts with the normal verified, durable intake path. LINE’s webhook receiving guide covers reception and redelivery. Do not deliberately fail a valid standby delivery in the hope that another attempt will grant chat initiative.

After intake, classify the event before creating any outbound task:

• Standby: retain only the data needed for authorized internal processing; record that an outbound response was suppressed.
• Active and replyable: allow one business operation to evaluate a response, with duplicate protection and send-result tracking.
• Unknown contract: pause automatic sending and request investigation without silently converting the event into an active one.

These are application decisions, not extra LINE fields or API statuses. Preserve the mode observed with the event. Do not rewrite an old standby event as active simply because a later event is active, or treat it as newly granted permission to answer an old message.

For delayed work, coordinate with the integration’s current responder policy before dispatch. If ownership is uncertain, hold the send for review rather than choosing a different messaging operation. Event deduplication alone does not settle which tool should answer.

Proposed acceptance tests should cover a standby message with no send, an active replyable event, a parser that drops a token, duplicate delivery, and a queued answer whose responder ownership becomes uncertain. These are test scenarios, not reported production results.

Where UnifyPort fits—and where it does not

UnifyPort’s unofficial interface is a separate connected-account route. The LINE authorization reference documents QR login, with QR URL and PIN material delivered asynchronously. It is not a module attachment flow and does not claim an Official Account’s chat initiative.

For that separate route, use the documented normalized message.received event. The webhook delivery contract specifies signature verification when signing_secret is configured. Do not copy LINE’s native mode or replyToken assumptions into this schema, and do not describe a UnifyPort send as recovery of an Official Account’s missing token.

Keep the official Messaging API and the responsible module provider when the sender must remain the LINE Official Account. A different connected-account identity is not an automatic fallback for standby.

FAQ

Does standby mean my webhook is offline?

No. The event may have arrived correctly. Standby describes the receiving channel’s chat initiative, not your server’s connectivity.

Can I use push because replyToken is missing?

Not as a standby fallback. LINE says the standby receiver should not send messages; the issue is responder ownership, not just the reply method.

Does active guarantee a replyToken?

No. Check whether that event type supports replies. Active mode alone does not make every event replyable.

Should every LINE bot implement Chat Control calls?

No. Module access has specific application requirements, and LINE’s current guidance describes Default Active behavior. Confirm the actual integration before adding ownership controls.

Next step and sources

Compare a securely captured event with the official module-channel guide, then document which component owns the response. For the independent connected-account path, review the UnifyPort LINE authorization contract.

Official references checked on 2026-10-27:

• LINE: Using the Messaging API from a module channel
• LINE: Control chat initiative
• LINE: Messaging API reference
• LINE: Receive messages