Webhook2026年10月14日9 分鐘
你的 Webhook 處理程式呼叫 LLM，發送端先掛斷了。
Slack 等 3 秒，Shopify 等 5 秒，GitHub 等 10 秒。呼叫 LLM 更久，發送端會掛斷。先回應再處理，或交給中繼服務代收。
最新
14
2026.10
開發 AnyHook 的團隊寫下的正式環境筆記：傳遞、重試、簽章驗證、除錯與重播。
ngrok 每次重啟都給你新網址，你只好再貼一次到 Stripe 或 Shopify。在服務商那邊放一個永久網址，再把它指向今天還活著的隧道。
談冪等性，通常只談到資料庫多一列。預約排程的 Webhook，結局卻是兩個人同時來赴 10:00 的約。
GitHub 不會重試失敗的 Webhook 傳遞，一次都不會。傳遞紀錄只保存三天，之後一次出錯的部署，就讓你永久失去那些事件。
HubSpot 不保證順序，文件也寫明 eventId 不保證唯一。你在 Stripe 的 event.id 上養成的直覺，在這裡全都失靈。
漏掉 access.granted，使用者會開單反映。漏掉 access.revoked，沒有人會發現：從外面看一切正常。可用性本身就是一種存取控制。
名義賣方（merchant of record）金流的回應時限更緊，重試曲線也更密。獨立開發的 SaaS 改用 Paddle 或 Lemon Squeezy 時，哪些事會跟著變。
Slack 要求三秒內回 2xx，一小時內有 95% 的傳遞失敗，就會停用你的事件訂閱。這是使用者會親眼看到的 Webhook 失敗。
Twilio 是唯一讓你設定連線逾時、讀取逾時、總時間、重試次數和重試原則的主要發送端。五個沒人轉的旋鈕。
沒有 Node crypto、CPU 時間以毫秒計、waitUntil 不持久。接收端換成 Worker 後有哪些不同，來自 AnyHook 自己的入口服務。
WooCommerce 用 Action Scheduler 把 Webhook 排入佇列，它靠 WP-Cron 執行，而 WP-Cron 要有人造訪網站才會跑。連續失敗超過五次，Webhook 就會被停用。
多數主要服務商採至少一次（at-least-once）傳遞：重複一定會發生，不是例外。四種冪等做法，依保護程度由低到高排序。
十次有九次是 Test URL：它只在你看著畫面時接收。其餘原因是回應模式、原始請求主體已被解析，或事件遺失。
Shopify 給你的端點五秒，在四小時內重試八次，然後移除訂閱。不會丟出任何錯誤，訂單就這樣不再進來。
Stripe 停用了你的 Webhook 端點，而 30 天的復原期限比聽起來短。處理順序：重新啟用，再從 Events API 回填。
簽章驗證莫名失敗、waitUntil 的工作憑空消失、冷啟動吃掉回應時限：無伺服器上會踩到的坑，以及怎麼處理。
輪詢浪費請求，但出問題時能優雅降級。Webhook 有效率，卻會無聲地失敗。另外談多數認真的整合最後都會做的混合架構。
網路上有一半的服務仍然用 Email 回覆：驗證碼、收據、通知。一次免金鑰的呼叫，就能給 AI agent 一個真正的收件匣，收到的信會變成它讀得回來的 Webhook 事件。
一個 catch-all 地址、一個 Worker 的 Email 處理程式，大約六十行：寄到你網域的每一封信，都會變成送進現有 HTTP 管線的 JSON POST。
存放在可修改資料庫裡的 Webhook 紀錄只是一面之詞，不是證據。AnyHook 的事件紀錄如何變得可驗證：每個 App 一條雜湊鏈、每日封緘、公開錨點。
如果測試用驗證程式檢查的同一套公式產生簽章，兩者可能一起錯，測試卻照樣全綠。改用服務商的 SDK 交叉驗證。
AI agent 能呼叫 API，接收事件卻是缺少的另一半。agent 需要 Webhook 網址時會卡在哪裡，以及 agent 能自己操作的服務該長什麼樣子。
Webhook 傳遞除錯：整合突然失效時，該在標頭、狀態碼、時間和 payload 裡找什麼。
為什麼單純的指數退避會引發驚群效應、隨機抖動怎麼解決它，以及正式環境等級的重試排程實際長什麼樣子。
伺服器當機了三個小時，Stripe、GitHub、Shopify 仍持續送出 Webhook。漏掉的事件怎麼重送：沒有中繼服務和有中繼服務的做法。
ngrok 很適合本機開發，但它不是正式環境的策略。離開隧道之後，staging、正式環境和兩者之間的灰色地帶，你需要的是這些。
Stripe 會重試失敗的 Webhook，最長 3 天。重試排程怎麼運作、端點當機時什麼會壞掉，以及該怎麼設計。
跨服務商驗證 Webhook 簽章：常見的錯誤、時間戳記的容許時間差怎麼運作，以及為什麼重試會弄壞簡單的實作。