Webhook 整合指南

概述

當您在機器人流程中透過 Webhook 呼叫外部服務時，若因以下原因造成請求逾時（Timeout）：

就可能導致 Webhook 在規定的等待時間內未收到回應，進而產生逾時錯誤。

例如：流程中呼叫建立訂單的 API，若該 API 需要等待完整建立流程執行完畢才回傳結果，就很容易導致 Webhook 請求超出等待上限。

本篇將說明幾個改善 Webhook 整合效能與穩定性的方式，協助避免因單一請求包辦過多處理而導致的逾時問題。

當你在機器人流程中呼叫 Webhook 時，流程將暫停等待 Webhook 回應完成，期間內的顧客訊息將不會被進一步觸發處理。

舉例來說：當顧客表達想查找資料，並透過 Webhook 呼叫外部服務進行處理，此時若回應時間較長，而顧客在等待期間持續補充訊息，這些訊息將不會被即時傳遞或處理，恐導致上下文斷裂、回應不連貫。

若欲整合第三方大型語言模型（LLM），請務必考量上述限制，評估是否符合您對即時互動與對話完整性的需求。

為避免 Webhook 在單一呼叫中執行過多需要等待的操作（如建立訂單、串接外部系統），導致請求逾時，建議採用以下處理方式：

將多個處理步驟進行拆解，改為分段執行：

透過這樣的設計方式，能夠有效避免一次性同步處理過多邏輯造成的超時問題，同時保留流程控制與後續銜接能力。

在上述流程中，若您希望讓顧客感受到流程正在進行、非系統延遲，也可以加入訊息提示節點來優化體驗：

這樣的設計不僅能減少用戶等待期間的不確定感，也有助於降低因等待造成的反覆提問或中斷操作。

若你的外部系統回應時間不固定，建議可以進一步設計一組「回應結果判斷邏輯」，提升流程彈性與反應效率：

📌 實作方式：

{
  "result": "success",
  "order_id": "123456"
}

在流程中插入一個條件判斷節點，根據回傳結果中的 result 值進行判斷：
- 若為 success，則直接進入後續回應流程，顯示結果或通知用戶
- 若為 pending / null / failed，則走原本的等待＋重查路徑（如等待 20 秒後再次呼叫 webhook 查詢）

這樣的設計方式能夠有效減少不必要的等待時間，讓成功的流程能夠立即結束並回應用戶，而失敗或尚未完成的情況，則透過等待與補查機制再進一步處理。

整體來說，這種做法提供了更大的彈性來應對外部系統回應時間不穩定的狀況，同時也實現了流程穩健、不中斷、可預期的整合體驗，是實務上非常推薦的進階整合策略之一。

Webhook 的使用受到以下限制規則影響：包括每分鐘觸發次數上限、單次請求的等待時間上限，以及同時最大處理中的請求數（併發限制）等。

若您將 Webhook 應用於高頻率請求的情境，需特別留意可能產生的排隊效應。例如：若每筆請求平均回應時間接近 15 秒，排隊中的其他請求也將被迫依序等待前一筆處理完成，進而導致級聯延遲效應，使整體回應效率大幅下降。

因此，我們仍建議您依照標準流程設計 webhook 結構，採取快速回應、背景處理等方式優化整合效率。

LINE Reply Token 限制：若您整合的是 LINE 官方帳號，請注意其 Reply Token 有效時間僅約 30 秒。Webhook 若未能於此時間內完成回應，將無法透過即時回覆完成互動，需額外透過推播訊息補發，可能產生額外費用與使用體驗落差。
轉換率與使用者體驗損失：延遲的互動回應將直接影響使用者在銷售流程中的停留與行動，可能導致：使用者中途離開或放棄填寫表單、客服回應滿意度降低、實際轉換率與營收流失
平台可信度下降與技術懲罰風險：部分第三方平台（如 slack、Facebook、Stripe 等）為確保整體服務品質，會對 webhook 回應時間設有嚴格要求。若整合方未能於規定時限內完成回應，平台可能視為服務不穩定，進而觸發技術層面的懲罰機制，例如降低 webhook 通知頻率、暫停事件發送等。
級聯延遲效應：當 webhook 回應時間過高（如需 40 秒以上）時，將產生排隊等待效應，造成後續訊息處理延遲。尤其在 webhook 同時僅允許有限數量併發處理的情境下，若有多位使用者同時互動，系統將依序排隊處理，導致第二位、第三位顧客的訊息可能被延遲數十秒甚至超過一分鐘。明顯影響整體回應即時性，降低使用者體驗，並進一步放大平台回應逾時與轉換率流失的風險。

...等，我們建議務必優化整合架構、採快速回應機制，否則後續若導致訊息遺失、互動錯誤或平台懲罰。

Last updated 6 days ago