Stripe · Shopify · GitHub · 還有 19 個
Stripe 送出了。你漏接了。它還在這裡。
把 Webhook 指向 AnyHook，我們再轉送給你。每個事件都在同一份紀錄裡，不論你的伺服器有沒有回應，任何一個都能按一下再送一次。
在邊緣節點驗證 22 個來源的簽章。加上簽章密鑰，偽造的請求就永遠到不了你的伺服器。
- Stripe
- GitHub
- Shopify
- Slack
- LINE
- Discord
- Twilio
- Sentry
- Linear
- Vercel
- Paddle
- Clerk
- Lemon Squeezy
- Intercom
- HubSpot
- Resend
- WooCommerce
- PayPal
- SendGrid
- Svix
- Meta
- Xero
發送端不等了。你的處理程式執行了兩次。
Shopify 等 5 秒。訂單出貨要 12 秒。
換一個網址。
不用 SDK。做完工作再回 200，當機就會變成重試。
每個事件都看得到。
收到了什麼、伺服器回了什麼、下次何時重試。修好 bug，按下 Replay（重播）。
{
"id": 820982911946154508,
"name": "#1042",
"total_price": "129.00",
"financial_status": "paid"
}{ "ok": true }給 AI agent 用的 API。
在 Claude、Codex 或 VS Code 加入一個網址並登入。你的 agent 就能透過 MCP 或一般的 REST，設定、檢查並重播你的 Webhook。
我們的伺服器昨晚掛了，Stripe 的付款一直沒進來。幫我搞定。
{ "count": 12, "events": [{ "eventType": "invoice.paid", "status": "failed", "outboundStatus": 503 }, …] }{ "replayed": true, "appSlug": "stripe-payments", "response": { "replayed": 12, … } }{ "events": [{ "eventType": "invoice.paid", "isReplay": true, "status": "success", "outboundStatus": 200 }, …] }你的端點整晚都回 503，這段期間 AnyHook 把 12 個事件全都保存了下來。我已經重播，每一個都拿到了 200。
MCP https://anyhook.net/mcp·REST Authorization: Bearer ahk_live_…
流量一目了然，全部由你掌控。
一個事件，在 AnyHook 內經過四站。
拿掉各家 SDK。只檢查一個標頭。
22 個來源在邊緣節點驗證，每次傳遞都用同一種方式簽章。
import { verifyWebhook } from "anyhook-verify";if (!(await verifyWebhook(req, secret)))return new Response(null, { status: 401 });
你的伺服器當機了。
不會遺失任何事件。
每個事件都會保存。重試會自動進行，剩下的用 Replay 送出。
為開發者而做。
同一個 Webhook 中繼服務，三種團隊最先遇到的情境。
發送端會重試。 你的 agent 執行了兩次。
發送端大約 1 秒就收到 200。你的 agent 依方案有 60–300 秒可用。
定價很簡單。
從免費開始。付費方案依事件保存多久、有多少個 App（一個接收網址，對應一個 Webhook 來源）送事件進來計價。付費方案採超額計費，不會在你不知情時遺失任何事件。
- 保存期限3 天
- 事件數每月 10,000 個
- 傳遞逾時60 秒
所有上限
- App 數1
- 每個 App 的目的地數3
- 傳遞嘗試次數3
- payload 上限512 KB
- 超額計費無
- 傳遞控制不包含
- 警示Email
- 保存 3 天
- 每日上限 1,000 個事件
- Email 警示
- 保存期限1 年
- 事件數每月 50,000 個
- 傳遞逾時120 秒
所有上限
- App 數10
- 每個 App 的目的地數20
- 傳遞嘗試次數5
- payload 上限2 MB
- 超額計費$0.15 / 1,000 個
- 傳遞控制篩選、速率限制、延遲傳遞
- 警示Email + Slack / Discord
- 每個事件保存 一年
- Slack / Discord 警示、事件篩選
- 超額計費，最高到你設定的上限
- 保存期限7 年
- 事件數每月 250,000 個
- 傳遞逾時5 分鐘
所有上限
- App 數50
- 每個 App 的目的地數50
- 傳遞嘗試次數10
- payload 上限4 MB
- 超額計費$0.17 / 1,000 個
- 傳遞控制篩選、速率限制、延遲傳遞
- 警示Email + Slack / Discord
- 保存 七年，可偵測竄改
- 沒有每日上限
- 自訂網域即將推出
- 保存期限彈性
- 事件數彈性
- 傳遞逾時彈性
所有上限
- App 數彈性
- 每個 App 的目的地數彈性
- 傳遞嘗試次數彈性
- payload 上限客製
- 超額計費客製
- 傳遞控制包含
- 警示Email + Slack / Discord
- SSO 與資安審查
- 專人導入協助
- 客製路由選項
Pro 方案加上 一年的事件保存、Slack 或 Discord 警示、事件篩選，以及超額計費，事件不會被丟棄。
常見問題與解答。
先回應，再處理。Slack 等你回 2xx 的時間是 3 秒，Shopify 是 5 秒，GitHub 是 10 秒。呼叫模型通常更久，所以發送端會重試，你的機器人就執行了兩次，最後 Slack 或 Shopify 還會把 Webhook 停用。
把 Webhook 指向 AnyHook，發送端大約 1 秒就會收到 200。接著，處理程式完成呼叫的時間是 Free 方案 60 秒、Pro 方案 120 秒、Scale 方案 5 分鐘，失敗會重試。不用自己建佇列。
可以。但你要承擔的是這些：
可靠性：持久佇列、死信處理、退避狀態機。漏掉一個邊界情況，就會同一筆訂單出貨兩次，或默默遺失一個事件。大多數團隊都是在正式環境、凌晨 2 點才發現這些 bug。
安全性：每家服務商的簽章方式都不同。Stripe 是 HMAC-SHA256 加時間戳記，GitHub 是 hex 編碼的 HMAC-SHA256，Shopify 是 Base64 編碼的 HMAC-SHA256。你得為每家服務商各維護一個驗證程式，還要處理金鑰輪替和加密儲存。漏掉一家，就等於接受沒有簽章的流量。
可觀測性：除錯就是在一次次的 Lambda 呼叫之間 grep CloudWatch。沒有可搜尋的事件紀錄，不能重播，也沒有完整的 payload 紀錄。
成本：基礎設施每月 $50–$200。真正的成本是每月 $3,000–$5,000 的工程師時間：值班、遷移、為卡住的重試除錯。AnyHook Pro 方案每月 $20，而且零維護。
兩段不同的連線。Stripe 計時的是連到你的公開網址的那段連線。把它指向 AnyHook，Stripe 等的就是我們的邊緣節點，它大約 1 秒就會回 2xx，那時你的程式根本還沒開始執行。
「傳遞逾時」是我們的傳遞計時：我們等你的端點回應多久（Free 方案 60 秒、Pro 方案 120 秒、Scale 方案 5 分鐘）。大多數端點回應的時間都遠低於這個上限。更久的工作就回傳 202 Accepted，再以非同步處理。
Zapier/Make 是低程式碼的自動化平台：視覺化編輯器、拖放式流程。AnyHook 是給開發者用的中繼服務：你的 Webhook、你的端點、你的程式碼、你的基礎設施。
要寫程式處理 Webhook？用 AnyHook。在 n8n、Make 或 Zapier 裡建流程？把 AnyHook 放在工作流程的 Webhook 觸發器前面：服務商送到 AnyHook，AnyHook 再轉送到觸發器的網址；工作流程停擺時進來的事件，會等著重播，不會就此消失。
我們回 200 給發送端之前，事件就已經寫進持久佇列。如果我們的轉送服務當機，事件會在佇列裡等待，恢復後再送出：發送端早就拿到 200 了。
如果邊緣節點完全無法儲存事件（佇列和兩個備援都無法使用），就會改回 503，讓發送端自己的重試接手。沒保存下來的事件，AnyHook 不會回 200。
服務可用率公開在 status.anyhook.net。
可以：AnyHook 就是為這種情況設計的。不論你的 agent 要跑多久，我們都大約 1 秒就回應 Stripe。
你的端點應該立刻回傳 202 Accepted，再以非同步處理。AnyHook 的傳遞逾時（Free 方案 60 秒、Pro 方案 120 秒、Scale 方案 5 分鐘）只適用於最初那一趟 HTTP 往返。
伺服器不再回應時，每個發送端會怎麼做。
它們最後都會放棄，只是放棄的方式各不相同。以下是各家公開的規則、你還能復原的期限，以及期限一過就拿不回來的東西。
- Stripe 停用了你的 Webhook 端點：照這個步驟復原Stripe 停用了你的 Webhook 端點，而 30 天的復原期限比聽起來短。處理順序：重新啟用，再從 Events API 回填。
- Shopify 刪除了你的 Webhook 訂閱。原因全在那 5 秒。Shopify 給你的端點五秒，在四小時內重試八次，然後移除訂閱。不會丟出任何錯誤，訂單就這樣不再進來。
- GitHub Webhook 收不到：你只有一次嘗試和三天GitHub 不會重試失敗的 Webhook 傳遞，一次都不會。傳遞紀錄只保存三天，之後一次出錯的部署，就讓你永久失去那些事件。
- WooCommerce 的 Webhook 不會在下單當下送出WooCommerce 用 Action Scheduler 把 Webhook 排入佇列，它靠 WP-Cron 執行，而 WP-Cron 要有人造訪網站才會跑。連續失敗超過五次，Webhook 就會被停用。
全部 28 篇指南，包括 Slack、Twilio、HubSpot、n8n，以及同一個 Webhook 收到兩次的那幾篇。
還在本機串接？隧道網址每次重啟都會變，而服務商完全不必知道這件事。
同樣的狀況，只是另一端換成模型：callback 要你在幾秒內回應，處理程式的模型呼叫卻要更久。