LINE webhook 的 standby 模式：為什麼沒有 replyToken？

如果 LINE webhook 事件帶有 mode: standby，收到事件不代表你的頻道應該回覆。LINE 的模組頻道文件明確說明：待機頻道不應傳送訊息，其 webhook 事件也不會包含 replyToken。這是 Chat Control 主導權問題，不是 token 過期或 webhook 傳遞失敗的證據。先確認事件模式與串接類型，再決定是否回覆。

重點整理

• webhook 可以成功送達，但接收頻道並不是回覆方。
• 不要因為缺少 replyToken，就自動改用 push 訊息。
• 模組頻道是特定企業串接功能，不是所有機器人都能啟用的一般設定。
• 事件接收、回覆歸屬及傳送結果應分開管理。

LINE webhook 的 active 與 standby 是什麼？

官方模組頻道 Messaging API 指南要求在回覆前檢查 mode。在文件描述的模組連結關係中，只有一個頻道是 active，其餘是 standby。

事件模式	文件定義	應用程式的處理方式
active	接收頻道擁有聊天主導權，可傳送回覆或 push 訊息	繼續確認事件類型及正常傳送條件
standby	接收頻道處於待機，事件沒有 replyToken	可執行獲授權的內部處理，但不向客戶傳送訊息
缺少或無法辨識	尚未確認串接的資料契約	檢查原始事件與解析器，不預設為 active

最後一列是建議的防禦性策略，不是 LINE 另定的模式。active 也不代表所有事件都有回覆 token，或都需要回覆；請查閱 Messaging API 參考文件中的個別事件定義。

這和多個一般工具共用一個 Messaging API channel 是不同問題。多工具串接檢查表處理共用憑證、webhook 管理權及配額；模組架構還要確認：目前由哪個頻道主導回覆？

先確認 Module 文件是否適用

LINE 說明，Module 功能僅供完成指定申請的企業客戶使用。不要假定一般機器人有資格連結模組或呼叫 Chat Control 操作。

Chat Control 指南也提醒：目前提供的模組頻道在連結時會自動取得主導權，稱為 Default Active，通常不需手動控制。因此，看到這份文件不代表每個 webhook 處理器都應加入取得或釋放主導權的呼叫。

先確認實際架構：

1. 記錄請求對應的 Official Account、接收頻道及服務商串接。
2. 向整合負責人確認是否有模組頻道。
3. 檢查安全保存的原始事件，不只看轉換後的佇列資料。
4. 比對解析前後的 mode 與 replyToken 是否存在。
5. 主導權不符預期時，請模組服務商調查，不要無據更換 token 或 webhook URL。

一般紀錄不應包含頻道憑證或回覆 token。診斷資料只需記錄 token 是否存在，不必留下其值。

先判斷缺少，再調查過期

token 缺少、token 過期與傳送回應遺失，需要不同處理方式。

觀察結果	應調查的項目	不應採取的動作
原始事件為 standby 且沒有 token	聊天主導權及預期回覆方	自行產生 token 或自動改發 push
原始事件有 token，背景工作卻沒有	解析、序列化及佇列欄位對應	透過更改主導權修復資料轉換錯誤
active 事件沒有 token	個別事件結構與串接情境	假定所有 webhook 都能回覆
有 token，但回覆失敗	實際 API 回應、使用紀錄與處理延遲	將所有失敗歸因於 standby
傳送請求逾時	結果是否仍未知	立刻用另一種操作傳送相同答案

若確實收到 token，只是太晚使用或重複使用，請參考 LINE 回覆 token 排障指南。這和「事件原本就不提供 token」是不同的處理路徑。

將觀察事件與回覆權限分開

建議接收端先完成正常的簽章驗證與持久化。LINE 的 webhook 接收指南說明接收與重新傳遞機制。不要刻意讓有效的 standby 傳遞失敗，期待下一次重送會授予主導權。

接收後，先分類，再建立傳送工作：

• **Standby：**只保留獲授權內部處理所需的資料，並記錄已抑制對客戶的回覆。
• **Active 且事件可回覆：**由一個業務操作評估回覆，並管理去重與傳送結果。
• **契約不明：**暫停自動傳送並交由負責人調查，不默認為 active。

這些是應用程式內部決策，不是額外的 LINE 欄位或 API 狀態。保留收到事件時的 mode；不能因後續事件是 active，就把舊 standby 事件改成 active，或認為已取得回覆舊訊息的新許可。

對於延後執行的工作，傳送前應遵循目前的回覆歸屬策略。若無法確認歸屬，暫緩傳送並人工核查，不要換一種訊息操作。單靠事件去重，無法決定多個工具中誰該回覆。

建議驗收包含：standby 訊息不觸發傳送、active 且可回覆事件、解析器遺失 token、重複傳遞，以及排隊期間回覆歸屬變得不明。這些是測試建議，不是正式環境測試成果。

UnifyPort 的適用位置與界線

UnifyPort 的非官方介面是獨立的帳號串接路徑。LINE 授權參考文件描述 QR Code 登入，以及非同步提供的 QR URL 和 PIN。這不是模組連結流程，也不會取得 Official Account 的聊天主導權。

在此獨立路徑中，使用文件定義的標準化 message.received 事件。Webhook 傳遞契約說明設定 signing_secret 後的簽章驗證。不要將 LINE 原生的 mode 或 replyToken 假設套入這個結構，也不要把 UnifyPort 傳送描述成恢復 Official Account 缺少的 token。

若發送身分必須是 LINE Official Account，應繼續使用官方 Messaging API，並與模組服務商確認主導權。改用另一個已連結帳號，不是 standby 的自動補救方式。

常見問題

standby 代表 webhook 離線嗎？

不是。事件可能已正常送達。standby 描述接收頻道的聊天主導權，不是伺服器連線狀態。

缺少 replyToken，可以直接改發 push 嗎？

不能把它當成 standby 的自動補救方式。LINE 要求待機接收方不要傳送訊息；問題是誰應回覆，不只是使用哪種方法。

active 一定會提供 replyToken 嗎？

不會。仍須確認個別事件是否支援回覆。active 本身不會讓所有事件都可回覆。

所有 LINE 機器人都需要 Chat Control 呼叫嗎？

不需要。Module 有特定申請要求，現行指南也說明 Default Active 行為。加入控制操作前，請先確認實際架構。

下一步與參考資料

將安全保存的事件與官方模組頻道指南比對，並明確指定負責回覆的元件。若需求是獨立帳號串接，請查看 UnifyPort LINE 授權契約。

官方資料核對日期：2026-10-27。

• LINE：從模組頻道使用 Messaging API
• LINE：聊天主導權控制
• LINE：Messaging API 參考文件
• LINE：接收訊息