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