Webhook Tester

Webhook 測試器是一個臨時公共位址，它會記錄傳送到它的每一個 HTTP 請求，讓你看清 Webhook 傳送方到底投遞了什麼。在下方建立一個鉤子，你就會得到一個有效期 30 分鐘的唯一 URL：把 Stripe、GitHub、付款服務商、監控服務或你自己的程式碼指向它，觸發事件，每一次投遞都會落在這裡——方法、路徑與查詢參數、標頭、請求內文和來源位址——供你在接上真正的處理器之前仔細檢查。

最後更新:

本服務儲存什麼——以及它絕不做什麼

建立一個鉤子只會在 SysOSX 檢查伺服器上儲存鉤子 id、它的建立與過期時間，以及建立者的位址。每個被擷取的請求儲存到達時間、方法、帶查詢字串的路徑、原樣傳送的標頭、最多 256 KB 的請求內文（超出部分會被截斷並標記），以及傳送方位址。一個鉤子最多保存 50 個請求；之後的投遞會被拒絕，直到鉤子過期。所有內容在鉤子建立 30 分鐘 後刪除，或在你按下刪除按鈕時立即刪除。接收器只負責接收：它從不擷取、跟隨或重播任何內容——被擷取的請求不會觸發任何出站呼叫。相鄰的偵錯工具請看 HTTP 狀態鏈追蹤器，完整工作流程請讀 無需管道工程，偵錯 Webhook。

為什麼沒有接收器時偵錯 Webhook 這麼彆扭

Webhook 是別人的伺服器按他們的時間表、因你無法控制的事件——付款成功、推送落地、警報觸發——來呼叫你的伺服器。這種形態正是 Webhook 難以偵錯的原因。傳送方無法存取你的筆記型電腦，所以本地開發需要隧道或公共預發布機器，才能看到一次真實投遞；事件可能很難觸發第二次，所以你確實得到的那一次投遞最好被完整擷取；而當某些東西失敗時，傳送方的儀表板通常只顯示你的端點回傳的狀態碼，而不是它實際傳送了什麼。簽名標頭在嗎？請求內文是文件承諾的 JSON 形狀，還是表單編碼？重試傳送的是同一個事件 id 嗎？如果你的處理器在記錄日誌之前就拒絕了請求——而簽名和解析類 bug 恰恰主導著 Webhook 偵錯——這些問題僅憑處理器日誌都無法回答。

臨時接收器把管道工程從這個循環中去掉。你不必為了看清到達了什麼就部署一個寫了一半的處理器，而是建立一個接受一切、如實記錄並展示給你的位址：按到達順序和原始大小寫呈現的標頭、在任何解析器有機會拒絕它之前的原始請求內文、傳送方有時藏參數的查詢字串，以及確切的方法——因為有些服務商用 POST 投遞，有些用 PUT，還有少數用 GET 做健康檢查。當螢幕上有一條真實擷取的投遞時，你可以按照真相而不是文件來撰寫處理器，從實際負載建立測試夾具，並把失敗的重試與原始投遞並排對比。然後刪除鉤子，把服務商指向你的真實端點，再觸發一次事件，看著你自己的處理器應答它。30 分鐘是刻意設短的：足夠完成一次偵錯工作階段，又短到不讓一個被遺忘的、裝滿擷取負載的測試位址長期留在網際網路上。

常見問題

一個鉤子能活多久，能擷取多少？

鉤子從建立起存活 30 分鐘，然後鉤子及它擷取的一切會被自動刪除。它最多保存 50 個請求；超出後的投遞會以 429 回應被拒絕，直到鉤子過期。每個請求內文最多儲存 256 KB——更長的請求內文會被截斷，擷取記錄會被標記為已截斷，讓你知道看到的不是全部。

誰能看到我的鉤子擷取的內容？

任何擁有鉤子 URL 的人。URL 中的 id 是唯一的憑證：它同時授權傳送請求和讀取擷取內容，之上沒有帳戶也沒有密碼。這正是本工具即開即用的原因，也是你應該把 URL 當作密碼的原因——不要公開張貼它，也不要把攜帶金鑰或個人資料的生產流量指向這樣一個共享查看器。

接收器會回覆傳送方、跟隨連結或重播請求嗎？

不會。接收器對每次被接受的投遞只回覆一個小的 200 JSON 確認，表示它已到達，除此之外什麼都不做：它從不擷取負載中出現的 URL，從不跟隨重新導向，也不提供重播或轉發。接收和檢查就是全部服務，這能防止被擷取的負載變成出站流量。

我可以用它測試哪些傳送方？

任何能向公共 URL 傳送 HTTP 請求的東西：Stripe、GitHub、Shopify、付款和表單服務商、監控和 CI 服務、物聯網裝置，或你自己用 curl 寫的程式碼。建立鉤子，把 URL 貼到服務商的 Webhook 設定（或你的腳本）裡，觸發事件，幾秒內就能看到投遞到達這裡。事後記得從服務商那裡移除測試 URL，或把它指向你的真實處理器。