AnyHook 文件

AnyHook 不需要 SDK，也不需要安裝套件：把發送端儀表板裡的 Webhook 網址換掉，你的處理程式就會繼續收到同樣的請求。有一件事要事先規劃：重試和重播帶的是發送端原始的時間戳記，所以發送端的簽章會過期時（Stripe、Slack，以及 /providers 上標有容許時間差的其他服務商），就改為檢查 AnyHook-Signature 來接受這些請求。

最快的方式（不需帳號）：執行 curl -X POST https://anyhook.net/api/v1/quickstart，立刻取得一個可用的接收網址（inbound URL）和 API 金鑰，適合 AI agent 和快速測試。這個端點如果 7 天內沒有透過回傳的 claim_url 認領，就會到期。把發送端指向回傳的 inbound_url，再用 GET /api/v1/events 和 GET /api/v1/events/{id} 讀回事件；回應中的 next_steps 列出了每個指令。

1. 1
   建立帳號

   前往 anyhook.net/sign-up 建立免費帳號。不需信用卡。
2. 2
   建立 App

   一個 App 就是一個接收網址，對應一個 Webhook 來源。新帳號一開始就會看到建立表單：替它取個名字（例如「Stripe Production」），也可以選填你自己的伺服器網址，AnyHook 收到每個事件後會轉送到那裡。留空的話，App 會記錄所有事件，但不轉送。目的地隨時都能新增，Free 方案每個 App 最多 3 個。
3. 3
   把發送端指向 AnyHook

   App 頁面會顯示你的接收網址，以及常見發送端要在哪裡填入它（例如 Stripe → Developers → Webhooks）。把它貼到那裡，取代原本的 Webhook 網址：

   https://in.anyhook.net/{user-slug}/{app-slug}

   這個頁面會持續監看：第一個請求幾秒內就會出現在上面。還沒有東西可以送？在同一頁按下 Send a test event（傳送測試事件）。

每個 App 都有一個專屬的接收網址：

https://in.anyhook.net/{user-slug}/{app-slug}

• user-slug：你的帳號識別碼，可以在儀表板的設定中看到。
• app-slug：每個 App 各不相同，依 App 名稱自動產生，也可以修改。

接收端點接受任何 POST 請求，也會回應設定時的驗證交握：帶有 hub.mode=subscribe 的 GET（Meta 的 hub.challenge 檢查）會自動原樣回傳，即使 App 還沒設定好也一樣。其他方法一律回 405。網頁和一般的 HTML 表單也能 POST 到這裡，詳見程式碼處理程式（code handler）。事件一寫入持久佇列，AnyHook 就回傳 HTTP 200，大約 1 秒，不受目的地端點的速度影響，所以發送端完全不必等它。

AnyHook 會從傳入的標頭自動判斷發送端，並在邊緣節點驗證 payload 的簽章。要啟用驗證，建立 App 時選擇你的 Webhook 服務商，並貼上服務商的 Webhook 簽章密鑰（例如 Stripe 的 whsec_...）。

沒通過檢查的請求會在邊緣節點拒收，不會抵達你的端點。App 頁面會計算數量，每天的前 5 個會以 rejected 狀態連同標頭和主體保存在事件紀錄裡，讓你看得到原因。

AnyHook 採用以佇列為基礎的非同步架構，讓 Webhook 發送端和你的後端彼此解耦：

1. 邊緣節點接收：Cloudflare Workers 接收 POST、驗證簽章，事件持久儲存之後就回 200，大約 1 秒。
2. 佇列：事件發布到持久的訊息佇列（Upstash QStash）。這時發送端的 HTTP 連線已經關閉。
3. 轉送：QStash 把事件交給 AnyHook 的轉送程式，再由它把原始 payload POST 到你的目的地端點。
4. 記錄：每個步驟都會記下來，包括接收的標頭和主體、傳遞狀態、端點回應的狀態碼和主體，以及延遲時間。

直接把約定講清楚，因為對保證含糊其辭的中繼服務，會把這份含糊推給你的程式碼：

1. 至少一次，不是恰好一次。重試就是 AnyHook 的本業，而回應遺失之後的重試，和一次全新的傳遞根本無法區分。偶爾你會收到同一個事件兩次；沒有任何中繼服務能保證不會這樣，宣稱做得到的，說的只是一切順利時的情況。你的處理程式必須冪等，去重的鍵就是我們在 X-AnyHook-Delivery 轉送的事件 ID。
2. 不保證順序。因為有重試和並行傳遞，較晚的事件可能比還在重試中的較早事件先送達。大多數發送端在我們的上游也不承諾順序。依 payload 裡的欄位排序（版本號、updated_at），絕不要依抵達時間。
3. 不要用簽章去重。AnyHook-Signature 每次嘗試都會以新的時間戳記重新簽章，這是刻意的，讓重試永遠不會超出你的容許時間差。同一個事件的兩次傳遞會帶著不同的簽章；不變的是事件的 id。
4. 收下就代表已持久儲存。邊緣節點要等事件儲存之後才回 200，而且在改回 503 之前，佇列後面還有兩個備援儲存。接收網址回 503，代表什麼都沒儲存，這時發送端自己的重試就是安全網；這正是我們寧可回 503、也不假裝成功的原因。

目的地回傳可重試的錯誤或逾時時，AnyHook 會以指數退避自動重試：

哪些回應會觸發重試？

不是所有錯誤都可以重試。AnyHook 會分類端點的回應，避免把嘗試次數或運算額度浪費在再試也解決不了的錯誤上：

每次嘗試都會記錄完整的回應主體和狀態碼。不可重試的 4xx 失敗和可重試的失敗都會計入斷路器，任何類型連續失敗 20 次，斷路器就會跳脫。

失敗通知

AnyHook 只在特定門檻寄出 Email 警示，而不是每個事件都寄，讓你的收件匣不會被淹沒：

• 第 1 次失敗：立即發出警示，附上狀態碼和目的地。
• 連續第 5 次失敗：發出升級警示，附上處理建議。
• 連續第 20 次失敗：斷路器跳脫（見下方），並寄出斷路器警示。

上面每個門檻各寄一封 Email，之後斷路器的每個階段（每次暫停和停用）也各寄一封，絕不會每個事件各寄一封。只要有一次傳遞成功，計數就會歸零。

如果 AnyHook 偵測到同一個目的地連續 20 次傳遞失敗（包括不可重試的 4xx），斷路器就會跳脫，並開始逐步升級：

運作方式

• 照樣接收事件。接收網址始終有效，Stripe、GitHub 等來源的事件照樣接收並儲存。暫停的只有傳遞到目的地這一段。
• 每次暫停結束後，AnyHook 會送出半開啟探測：用下一個事件測試你的目的地。成功的話，斷路器關閉，一切重設。
• 只要成功一次，一切重設：連續失敗次數和跳脫次數都歸零。
• 暫停期間收到的事件會以 circuit_open 狀態儲存，目的地恢復後即可重播。
• 每升級一級，你都會收到 Email 通知，內容包括目的地網址、失敗次數和暫停時間。
• 如果目的地已停用（第 5 次跳脫），必須從儀表板手動重新啟用。

這種逐步升級的做法，讓你的伺服器有時間恢復，也替運算額度省下當機的端點會耗掉的那些重試。

每個抵達接收網址的事件都會被記錄，不論傳遞結果如何。事件紀錄從你把服務商指向 AnyHook 的那一刻開始：在那之前失敗的事件只存在於服務商那裡（Stripe 的情況見如何重播 Webhook）。每筆紀錄包含：

• 完整的接收標頭和主體（和發送端送來的一模一樣）
• 傳遞狀態：queued → success / retrying / failed / rejected / circuit_open / quota_exceeded。rejected 代表 AnyHook 拒收了這個事件（簽章驗證失敗，或目的地網址被封鎖），從未嘗試傳遞，也無法重播。
• 目的地回應的 HTTP 狀態碼和主體（每次嘗試）
• 延遲時間（毫秒）
• 嘗試次數和下次重試時間
• 事件是否為重播（is_replay: true）

事件保存多久取決於方案。Free 方案：3 天，期間內都能重播，之後刪除。Pro 方案：1 年，前 30 天可以重播，之後轉為唯讀的加密封存。Scale 方案：7 年，前 90 天可以重播，之後轉為唯讀的加密封存。Enterprise 方案：彈性。

事件紀錄裡的任何事件，都能在儀表板上一鍵重播。重播會把儲存的 payload 逐位元組原樣送到事件當初的目的地；如果之後你改過那個目的地的網址，就送到新網址。

• 前往 Dashboard → Events
• 找到該事件，按一下 Replay（重播）
• 系統會建立一個帶有 is_replay: true 的新事件，並連結到原始事件

AnyHook 直接就能搭配本機開發，不需要特殊模式或 CLI。有兩種做法：

1. 透過隧道即時轉送

把 App 的目的地設成指向你本機的隧道網址。任何隧道服務都可以：

# ngrok
ngrok http 3000
# → https://abc123.ngrok.io

# cloudflared
cloudflared tunnel --url http://localhost:3000

# localhost.run
ssh -R 80:localhost:3000 nokey@localhost.run

在儀表板把隧道網址填進 App 的目的地。AnyHook 會像轉送到其他端點一樣把 Webhook 轉送過去，重試、紀錄和簽章標頭全都照常運作。

2. 先收集，再重播到 localhost

讓正式環境的真實事件累積在 AnyHook 裡，需要時再把任何一個重播到本機環境。不必手動觸發測試事件，直接用真實的 payload 測試，只要不超過每日重播上限，想測幾次都可以。

• 把目的地切換成隧道網址
• 開啟 Dashboard → Events，在任一事件上按一下 Replay
• 或使用 API：POST /api/v1/events/{id}/replay
• 原始 payload 會逐位元組原樣送到目前的目的地

這在為邊界情況除錯時特別有用：在正式環境的紀錄裡找到出問題的事件，在本機重播，反覆修改直到處理程式正確運作。

所有 Webhook payload 資料在寫入資料庫之前，都會以 AES-256-GCM 加密。範圍包括接收標頭、請求主體，以及每個目的地的簽章密鑰。

加密使用專屬的金鑰（AES_SECRET_KEY），和資料庫憑證分開存放。資料庫外洩時，沒有加密金鑰就只拿得到密文：沒有明文的 Webhook 資料、沒有簽章密鑰，也沒有客戶資訊。

AnyHook 在 Cloudflare 的邊緣節點驗證 Webhook 簽章，在事件進入佇列之前完成。App 有了簽章密鑰後，缺少簽章或簽章無效的請求會以 401 拒收，不會用掉你的配額；沒有密鑰時，請求不經驗證就轉送。

AnyHook 依標頭自動判斷簽章類型。建立 App 並選擇來源類型時，AnyHook 會儲存簽章密鑰（儲存時已加密），並針對該服務商使用正確的演算法。

不支援或自訂的來源

如果你的 Webhook 來源不在支援清單上，建立 App 時選擇 Generic 來源。AnyHook 會：

• 接收每個傳入的 POST 並放進佇列，不檢查傳入的簽章。
• 把請求主體逐位元組原樣連同服務商的原始標頭轉送到你的目的地，每次嘗試另外附上新的 AnyHook-Signature。在我們邊緣節點之前由基礎設施加上的標頭（cf-* 之類）會被移除。
• 附上 AnyHook-Signature 標頭，讓你的端點仍能驗證請求確實經過 AnyHook。

Generic App 不論設了什麼密鑰，都不檢查傳入的簽章。AnyHook-Signature 證明請求經過 AnyHook，卻無法證明是誰送給 AnyHook；如果你需要這一點，就繼續自己檢查發送端的原始標頭（原封不動轉送）。如果發送端用 Standard Webhooks 簽章（webhook-id、webhook-timestamp、webhook-signature，OpenAI 和 Replicate 都是這樣），就改選那個來源：它會在邊緣節點驗證。

每個目的地都有三個選用設定，Pro 以上方案皆可使用。在 App → Destinations → Delivery controls 設定，或用 PATCH /api/v1/apps/{slug} 設定目的地物件。Free 帳號會保有付費期間設定的控制，但無法更改。

{
  "destinations": [{
    "url": "https://api.example.com/hooks/stripe",
    "event_types": ["invoice.*", "checkout.session.completed"],
    "rate_limit": 20,
    "delay_seconds": 5
  }]
}

在 Pro 和 Scale 方案中，App 可以在沙箱裡，對收到的每個事件執行你自己的程式碼，不需要自己的伺服器。儲存程式碼後，App 會多一個執行它的目的地，因此重試、重播、斷路器和事件紀錄都和其他目的地一樣運作，每次執行的主控台輸出和回傳值，就是該次傳遞的回應。可以在 App 的 Code（程式碼）區塊撰寫，或使用下方的端點。常見操作的範本在 /code-templates.md，從 Pipedream 搬過來也有專門的指南。

export default async function (event, { env, store }) {
  // event: { method, headers, body, raw_body, delivery_id, attempt }
  console.log(event.body);
}

• 事件。body 是解析後的 JSON、表單欄位（urlencoded，或 multipart 表單的文字欄位）或原始文字，raw_body 則是收到時的原始文字。method 一律是 POST；查詢字串、路徑和呼叫端的 IP 都不會保存。delivery_id 是事件的 X-AnyHook-Delivery ID，attempt 從 1 開始計數，測試執行時為 0。
• 失敗。拋出錯誤會讓這次傳遞失敗，並依方案的嘗試次數重試（重試排程）。某個事件的執行已經成功時，它的重試不會再執行一次；但如果執行是在某個呼叫已經送出後才失敗，重試就會再執行一次，所以在 API 允許的地方，用 delivery_id 當這類呼叫的冪等鍵。
• Pipedream 步驟。export default defineComponent({ async run({ steps, $ }) {} }) 也能執行：steps.trigger.event 就是上面的事件，$.export 和 $.flow.exit 都能用，每個 data_store prop 都是 App 的儲存區（store），app prop 的 $auth.field 會讀取密鑰 APP_FIELD，其他 prop 則讀取以它命名的密鑰（channelId 讀取 CHANNEL_ID）。哪些無法沿用，列在 Pipedream 指南裡。
• npm 套件。程式碼 import 的套件會在儲存時安裝，固定版本的寫法和 Pipedream 相同（import axios from "axios@1.7.9"），最多 20 個套件。需要安裝新套件的儲存可能要花幾分鐘；安裝失敗就什麼都不會儲存。
• 密鑰。以 env.NAME 或 process.env.NAME 讀取，最多 20 個，名稱只能用英文字母、數字和底線，且不能以數字開頭。PATH, HOME, NODE_OPTIONS, NODE_PATH, PWD 和以 ANYHOOK_ 開頭的名稱由執行環境專用，每個值最多 4,000 個字元。值絕不會離開伺服器。
• 儲存區。store.get、set（{ ttl } 以秒為單位）、has、delete、keys、entries 和 clear 能在事件之間保存狀態，每個 App 一個儲存區：最多 1,000 個鍵，每個鍵最長 256 個字元，每個值以 JSON 計最多 64,000 位元組。匯入時接受 {"entries": {key: value}}，會覆寫已存在的鍵，並且不設 TTL。
• 排程。schedule 是五個 cron 欄位，除非加上 CRON_TZ=Area/City 前綴，否則以 UTC 計。每次觸發都會把一個 anyhook.schedule 事件 POST 到 App 自己的網址，所以同時算一次執行和一個事件，而且只在程式碼開啟時觸發。App 的來源必須是 generic 或 auto，且不設簽章密鑰：替排程用的程式碼另開一個 App。
• Email。每個 App 也能在 {user-slug}.{app-slug}@anyhook.net 收信，信件會變成一個 email.received 事件，主體包含 from、to、subject、message_id、date、size，以及放在 raw 的 MIME 信件。和排程一樣，需要來源為 generic 或 auto、且不設簽章密鑰的 App；超過方案 payload 上限的信件會被退回。
• 網頁和表單。網頁可以用 fetch() 呼叫接收網址：邊緣節點會回應 CORS 預檢請求，每個回應都帶有 Access-Control-Allow-Origin: *。一般的 HTML 表單需要 method="post"。在表單的 action 加上 ?redirect=https://your-site.com/thanks，事件儲存後就會以 303 把訪客導向那裡，前提是這個網址和送出表單的網站是同一個網站；否則訪客會看到一個寫著「Received」（已收到）的簡短頁面。文字欄位會出現在 event.body；上傳的檔案則不會留下。
• 上限。程式碼最多 64,000 位元組，每次執行在 Pro 方案最多 105 秒、Scale 方案最多 285 秒。每次執行保存主控台輸出的最後 16,000 個字元。每月執行次數列在方案表裡，每次執行都計入，包括重試、測試執行、重播和排程觸發。沒有超額計費：超過當月執行次數後，送往程式碼的傳遞會回 429，並被保留（circuit_open），不重試，等到下個月或方案升級後即可重播。
• 測試，以及開啟與關閉。POST .../code/test 會用 App 最新儲存的事件、指定的 event_id，或你傳入的 body 執行已儲存的程式碼，並回傳 log、回傳值和執行時間。它算一次執行，不會傳遞任何東西，但程式碼自己發出的請求都會真的送出。只有程式碼開啟時，事件才會執行它。儀表板儲存的新程式碼預設為關閉，而 PUT .../code 儲存的第一個版本會直接上線，除非你傳入 "enabled": false；之後的儲存則維持目前的狀態。如果還有另一個目的地在處理同樣的事件（例如遷移期間），就用 "enabled": false 儲存，移除那個目的地之後再開啟程式碼。這兩種變更最多需要一分鐘，才會傳到每個邊緣節點。

所有 API 請求都需要在 Authorization 標頭帶上 Bearer token：

Authorization: Bearer ahk_live_xxxxxxxxxxxxxxxx

在 Dashboard → Settings → API Keys 產生 API 金鑰。金鑰的範圍是你的帳號，可以是完整存取或唯讀（建立時選擇），而且隨時都能撤銷。透過 MCP 登入（anyhook.net/mcp）連線的用戶端，可以在你核准的權限內，用它的 OAuth 存取權杖呼叫同樣的端點。

AnyHook 是位於 https://anyhook.net/mcp 的 MCP 伺服器，agent 可以替你建立 App、讀取事件紀錄、重播失敗的事件，在 Pro 和 Scale 方案還能部署和測試 App 的程式碼（anyhook_code_deploy、anyhook_code_test、anyhook_code_get）。Claude Code、claude.ai、Codex和VS Code 只要網址加上瀏覽器登入就能連線，不必複製金鑰：各用戶端的步驟。

Cursor、Windsurf 和 Claude Desktop 使用金鑰。在 Dashboard → Settings → API Keys 建立金鑰後，畫面會顯示下面這段設定，你的金鑰已經填在裡面：

{
  "mcpServers": {
    "anyhook": {
      "command": "npx",
      "args": [
        "-y",
        "anyhook-mcp"
      ],
      "env": {
        "ANYHOOK_API_KEY": "ahk_live_xxxxxxxxxxxxxxxx"
      }
    }
  }
}

Cursor：Settings → MCP → Add new MCP server，或 ~/.cursor/mcp.json。Windsurf：~/.codeium/windsurf/mcp_config.json。Claude Desktop：Settings → Developer → Edit Config。程式碼工具需要 anyhook-mcp 0.4.0 以上版本（npx -y 會自動取得），或改用 https://anyhook.net/mcp 的伺服器。

接著對它說：「幫我的 Stripe Webhook 建立一個 AnyHook App，並給我它的網址。」這些內容，agent 也都能在 /llms.txt 讀到。

查看完整定價 →