LINE replyToken 過期怎樣處理？避免延遲回覆重複發送
LINE Messaging API 的 replyToken 只可使用一次，必須在收到 webhook 後一分鐘內使用；超過一分鐘不保證有效。如果 AI 生成或排隊令回覆延遲，不要反覆提交同一 token，也不要在請求逾時後立即自動改發 push。先分清「token 尚未使用」和「回覆已發出但結果未明」，再決定下一次發送。
重點
- 回覆 token 是短暫的回覆機會，不是收件人 ID 或可重複使用的憑證。
- webhook 重投不會帶來第二次獨立回覆機會。
- 請求逾時表示結果未明，不代表訊息沒有發出。
- push 是獨立操作，有自己的收件人條件及訊息計數規則，不是 token 續期。
LINE 對回覆 token 的實際規定
Messaging API reference 定義 POST /v2/bot/message/reply，請求使用事件內的 replyToken 及 messages 陣列。token 只可用一次，應盡快使用。LINE 亦提醒有效時間可能改變，因此不要刻意等到最後一秒才發送。
即時回覆「正在查詢」也會消耗 token，之後的正式答案不能繼續用它。官方發送指南 允許一次回覆請求包含最多五個訊息物件，但不代表同一 token 可分五次呼叫。
| 值 | 用途 | 不能取代甚麼 |
|---|---|---|
| Channel access token | 驗證 channel 的 API 請求 | 新的回覆 token |
replyToken | 回覆觸發事件的用戶操作 | 長期用戶地址 |
| 收件人識別碼 | 指定符合條件的 push 目標 | 再次使用回覆操作的權限 |
若你處理的是 LINE MINI App 通知，請先看服務訊息與 Messaging API 比較。服務通知 token 屬於另一套 API 契約。
先查清失敗邊界，再決定補發
以下是建議的應用程式檢查項目，不是新增的 LINE 錯誤碼。
| 證據 | 要檢查的邊界 | 安全的下一步 |
|---|---|---|
| webhook 到達很久後 worker 才開始 | 佇列積壓或生成緩慢 | 不依賴舊 token，另行評估延遲發送 |
| 另一個 worker 已收到成功回覆 | 單次 token 已消耗 | 停止重複工作 |
| HTTP 請求發出後逾時 | 是否受理未明 | 保留未明狀態，不立即 push 相同答案 |
| 相同 webhook 再次到達 | 重複接收 | 查詢原事件的處理及發送狀態 |
| 新收到的事件也回覆失敗 | 請求內容、channel 憑證、token 選取或其他 API 錯誤 | 檢查實際回應，不把所有錯誤都當成過期 |
記錄 webhook 接收時間、worker 開始時間、請求發出時間、HTTP 狀態及之前是否成功。不要把 token 或授權標頭寫入一般日誌；只按短期操作需要保留受保護的 token 資料。
單次錯誤不能告訴你另一個 worker 是否已回覆。重新發出 channel access token，也不能令已消耗的回覆 token 再次有效。
webhook 重投不是 token 更新服務
LINE 的接收訊息指南 說明，重投保留 webhook 事件 ID 及回覆 token，只有 deliveryContext.isRedelivery 改變。應用程式可使用 channel 身分及 webhookEventId 作為去重鍵。
參考文件允許在收到重投 webhook 後一分鐘內使用其 token，但有例外：token 已用過，或距事件發生已過二十分鐘時，不能使用。這是復原情境的有限機會，不是可預約的回覆時段，更不是故意拒收 webhook 的理由。
先持久保存事件，再獨立確認接收；耗時工作放到後續處理。重複 webhook 應查找已有工作，而不是再次啟動 AI 生成及發送。發送狀態亦要持久保存：只對接收事件去重，不能保護 worker 故障後重跑的發送工作。
啟動慢工作前先選定回覆路徑
快速答案由一個 worker 負責並盡快回覆。可能超出回覆時限的工作，則提前決定是先簡短確認收到、稍後再發結果，還是完成後才發結果。
建議流程如下：
- 事件只認領一次。 把 channel 及
webhookEventId關聯至一個業務操作，以唯一紀錄或交易式認領避免兩個 worker 各自發送。 - 保存發送決策。 區分即時 reply 及後續 push。確認收到是一個完整回覆，不是保留 token 等待稍後使用。
- 如實記錄結果。 本地狀態區分未嘗試、已受理、已拒絕及結果未明。這些是應用程式標籤，不是 LINE 回應欄位。請求發出後程序故障，也可能留下未明結果。
- 檢查延遲發送條件。 再確認答案是否仍適用、是否已有客服回覆，以及收件人是否符合 LINE 現時 push 條件。先前結果未明時，必須明確決定是否繼續。
- 把 push 保存為新操作。 使用獨立請求及保護措施；它不會改變之前 reply 的結果。
LINE 計費文件 區分訊息計數：reply 不計入訂閱計劃訊息數，push 則計入。請核對適用計劃，不要假設備用發送與原回覆的計數方式相同。
支援的 push 重試請參照 X-Line-Retry-Key 指南。官方重試文件 列出 push、multicast、narrowcast 及 broadcast，不包括 reply。為 reply 加上此標頭，既不能延長 token 效期，也不能令後續 push 與先前 reply 一同去重。
不要混用 UnifyPort 的回覆契約
UnifyPort 的非官方接口連接訊息帳戶，是獨立接入路徑，不是 LINE 官方帳戶回覆 token 的修復機制。文字訊息文件 使用 POST /v1/messages，請求包含 account_id、to 及 message。平台支援矩陣 列出 LINE 文字發送能力，但以 token 進行的引用回覆操作現時只支援 WhatsApp。
不要把 LINE 的 replyToken 放入 UnifyPort 的 reply_to.reply_token。名稱相似不表示憑證可互換。對已保存的標準化事件發送普通回覆，應使用文件規定的帳戶及對話識別碼，並檢查實際發送結果；這不代表跨 API 去重或 token 復原。
若發送者必須是 LINE 官方帳戶，請繼續使用官方 Messaging API。更換接入身分不能成為官方發送結果未明時的自動補救措施。
常見問題
過期的 LINE 回覆 token 可以更新嗎？
不要把它當成可更新的 access token。新的合資格事件會提供回覆機會，重投則受上述有限規則約束。兩者都不容許同一業務答案無限重試。
可以先確認收到，再用相同 token 發送正式答案嗎？
不可以。首次被受理的回覆會消耗單次 token。後續答案須獨立規劃，並檢查 push 收件人條件及訊息計數。
每次 reply 逾時都應改發 push 嗎？
不應該。reply 可能已被受理，自動 push 可能造成重複。保留結果未明狀態，並制定明確的備用發送規則。
下一步與參考資料
按 LINE Messaging API reference 檢查一個慢回覆流程，以本地模擬測試重複投遞、兩個 worker 競爭、確認收到後的延遲答案，以及 HTTP 回應遺失。這些是建議測試，不是已取得的正式環境成果。若選擇獨立的訊息帳戶路徑，請從 UnifyPort 文字發送契約 開始。
官方資料核對日期：2026-10-04。
令訊息接入變成一條穩定嘅產品管線。
先用統一嘅 API 跑通發送，再用標準事件將所有入站訊息接返去業務系統。