失敗的 Webhook，Shopify 總共會傳遞 9 次：第一次嘗試加上 8 次重試，最後一次在事件發生後 4 小時。然後就停了。在我們的測試裡，Shopify 沒有再為這些訂單送出任何東西，伺服器恢復後也一樣。訂單存在 Shopify 裡，你的系統卻永遠不會透過 Webhook 得知。
Shopify 的文件給了總數，也就是 4 小時內重試 8 次，但沒有寫每次嘗試發生在什麼時候。所以我們實測了一次。我們在 Shopify 開發商店下了四筆測試訂單，讓接收端持續回 503 將近六小時，並記錄每一個請求。
重點摘要
- Shopify 的傳遞嘗試落在事件發生後大約 2 秒、3 秒、1 分鐘、3 分鐘、8 分鐘、30 分鐘、1 小時、2 小時和 4 小時。四筆訂單都照這個排程走，誤差在 1.4 秒以內。
- Shopify 第九次嘗試之後，什麼都沒有。接收端不到兩小時後就恢復了，四筆訂單卻沒有一筆透過 Webhook 送到。
- 很多指南還在寫 Shopify 會「48 小時內重試 19 次」，這個說法已經過時。
- 在 Shopify 管理介面新增的 Webhook，連續傳遞失敗 36 次後沒有被刪除。管理介面的頁面沒有顯示任何失敗，商店擁有者也沒收到信。
- 服務中斷超過四小時，要撐過去需要兩樣東西：在伺服器當機時儲存事件、回應 Shopify 的機制，以及對照 Admin API 的對帳工作。對在管理介面新增的 Webhook 或小型應用程式來說，改動最小的做法是像 AnyHook 這樣的 Webhook 中繼服務（webhook relay）：你只要換一個網址。
實測的重試排程
| 嘗試 | 訂單成立後經過的時間 | 距離上一次嘗試 |
|---|---|---|
| 1 | 2 秒 | |
| 2 | 3 秒 | 1 秒 |
| 3 | 1 分鐘 | 1 分鐘 |
| 4 | 3 分鐘 | 2 分鐘 |
| 5 | 8 分鐘 | 5 分鐘 |
| 6 | 30 分鐘 | 22 分鐘 |
| 7 | 1 小時 | 30 分鐘 |
| 8 | 2 小時 | 1 小時 |
| 9 | 4 小時 | 2 小時 |
| 之後 | 什麼都沒有 |
時間從 X-Shopify-Triggered-At 起算，這是 Shopify 放在 Webhook 上的時間戳記。
九次嘗試裡有五次，用在最初的八分鐘。這些嘗試能應付短暫的異常，對壞掉的部署幫助不大：等到有人開始看警示，就剩四次嘗試了。
這個排程看起來是固定的。每一步，四筆訂單彼此的差距都在 1.4 秒以內，所以看不出隨機抖動（jitter）。一起失敗的一批訂單，重試時應該也會是同一批：限時搶購的尖峰，會在一分鐘後回來一次，接著是三分鐘後、八分鐘後。
同一個事件的重試，帶的是同一個 ID。我們比對的那筆訂單，X-Shopify-Webhook-Id 在九次嘗試裡完全相同，所以拿它來去重很安全。
關鍵的界線是四小時。端點恢復時，最近四小時內的每筆訂單都還在路上，會在下一次排定的嘗試送達。比這更早的訂單，永遠不會送達。
「48 小時內重試 19 次」已經過時
你現在還是看得到這個數字，連提供 Webhook 服務的公司今年發布的指南也這樣寫。它來自 Shopify 舊的政策。Shopify 在 2024年9月10日改了機制，變成 4 小時內重試 8 次，現行文件的說法也相同。我們的紀錄也一致：最後一次嘗試在第四小時，隔天也沒有再收到任何東西。
如果你的維運手冊或復原計畫假設有兩天，那就差了十二倍。
這些訂單後來怎麼了
在直送的 Webhook 上，全部 36 次傳遞（四筆訂單，每筆九次嘗試）都收到 503。最後一次嘗試的 1 小時 37 分鐘後，接收端重新開始回 200，Shopify 沒有再試。四筆訂單一筆都沒送到。
這次服務中斷沒有任何特別之處。週五晚上部署壞掉、午夜前修好，看起來也是一樣。你會失去哪些訂單，取決於當機多久。在六小時的服務中斷裡，前兩小時的訂單在 Webhook 這條路上就沒了，後四小時的訂單會在下一次排定的嘗試送達，最晚在你恢復後兩小時。這是指 Webhook 撐過服務中斷的情況。透過 Admin API 建立的訂閱可能在過程中被刪除，那麼在你重新建立之前，不會再有任何新的傳遞。
如果這發生在黑色星期五特賣期間，伺服器負載最重、每小時的訂單也最多，最初那幾小時的訂單就得從 Admin API 回填。沒有別的方法能拿回來。步驟在 Shopify 刪除了你的 Webhook 訂閱。
Webhook 還在，也沒有人收到通知
Shopify 的文件說，訂閱只有在透過 Admin API 設定時，才會在連續失敗 8 次後被刪除，警告則會寄到應用程式的緊急開發者電子郵件（emergency developer email）。文件沒有提到在 Shopify 管理介面的「設定 > 通知 > Webhook」（Settings → Notifications → Webhooks）手動新增的 Webhook。這些 Webhook 背後沒有應用程式，而且常常是商店連接 ERP 或倉儲的方式。
所以我們去看了。連續 36 次傳遞失敗之後，隔天：
- Webhook 還列在那裡，沒有任何變化。
- 管理介面的頁面沒有傳遞紀錄，也看不出任何失敗跡象。每一列提供編輯、傳送測試和刪除。
- 商店擁有者的信箱沒有收到任何警告信。
每次傳遞都失敗了一整天的 Webhook，看起來和健康的沒有兩樣。唯一的症狀，是下游少了訂單。透過 Admin API 建立的訂閱，失敗的方式不同：Shopify 會刪除它。
服務中斷超過四小時，怎麼撐過去
你需要一個在伺服器當機時儲存事件、回應 Shopify 的機制，還需要一個對帳工作，處理仍然漏掉的部分。Shopify 自己的文件也建議建立這個工作。下面其中一個選項是我們做的，參考我們的意見時，把這點考慮進去。
| 選項 | 支援管理介面的 Webhook | 最適合 | 要注意的地方 |
|---|---|---|---|
| 對照 Admin API 的對帳工作 | 支援 | 任何少一筆訂單就會虧錢的商店 | 事後才執行，時間由你排定。要自己建立和執行 |
| Amazon EventBridge 或 Google Pub/Sub | 不支援，管理介面的表單只接受網址 | 已經在該雲端上的應用程式 | 只限應用程式的訂閱。消費端、保存期限和警示都要自己做 |
| 小型端點後面接自己的佇列 | 支援 | 想全部自己做的團隊 | 那個端點同樣只有五秒可以回應，而且系統其他部分當機時，它還得撐住 |
| Hookdeck | 支援 | 需要轉換、團隊工作流程和處理大量流量的平台團隊 | 對只要重試和重播的工作來說，功能超出所需 |
| AnyHook | 支援 | 小型團隊和管理介面的 Webhook：換一個網址，不用寫程式，可以免費開始使用 | 傳遞是至少一次（at-least-once），所以還是要去重。Free 方案在 35 分鐘時停止重試，每天超過 1,000 個事件也會拒收 |
怎麼選：
- 你是手動新增 Webhook，或經營小型應用程式，想讓訂單撐過難熬的一晚：在端點前面放一個中繼服務。AnyHook 就是為這種情況做的。換一個網址，處理程式維持原樣。
- 你的平台團隊要處理大量流量：Hookdeck 是更完整的產品。這裡有兩者的比較。
- 你的應用程式已經在 AWS 或 Google Cloud 上：EventBridge 或 Pub/Sub 符合你現有的環境。
- 不管哪一種情況：都要為訂單留一個對帳工作。中繼服務只是把界線從四小時，移到它自己的重試期間和保存期限，界線依然存在。
同一個測試，改走 AnyHook
AnyHook 是 Webhook 中繼服務：把 Webhook 指向它，它會儲存事件、回應發送端，再轉送到你的伺服器，伺服器失敗時會重試。在這次測試裡，每筆訂單也會送到第二個 Webhook，它指向 AnyHook，再由 AnyHook 轉送到同一個接收端：
| 嘗試 | 經過 AnyHook |
|---|---|
| 1 | 2 秒 |
| 2 | 5 分鐘 |
| 3 | 35 分鐘 |
| 4 | 3 小時 35 分鐘 |
| 5 | 21 小時 35 分鐘，送達 |
AnyHook 大約一秒就回 Shopify 200，所以 Shopify 沒有東西要重試，這個排程是 AnyHook 自己對同一個失敗接收端的重試。Shopify 在直送 Webhook 上的嘗試結束很久之後，第五次嘗試碰到接收端已經恢復，送達了還在等待的三筆訂單。第一筆訂單經過 AnyHook 的那一份，早在 35 分鐘時就送到了，原因是我們這邊的失誤，說明在我們怎麼測的。
多這一跳，讓第一次嘗試多花了 0.5–0.9 秒。Shopify 的簽章也撐過了轉送：接收端對轉送過來的請求檢查原本的 X-Shopify-Hmac-SHA256，每一次都通過，所以你現有的驗證程式碼照樣能用。第一次傳遞失敗時，AnyHook 就寄了信，連續失敗五次時又寄了一封。Shopify 什麼都沒寄。
這次測試跑在我們自己的 Enterprise 方案帳號上。每個方案的重試時間點都一樣。不同的是嘗試次數和可重播期間：
| 方案 | 價格 | 嘗試次數 | 最後一次自動嘗試 | 可重播期間 |
|---|---|---|---|---|
| Free | $0，不需信用卡 | 3 | 35 分鐘 | 3 天 |
| Pro | $20/月 | 5 | 21 小時 35 分鐘 | 30 天 |
| Scale | $90/月 | 10 | 5 天 21 小時 | 90 天 |
在 Free 方案，這次測試的結果會不一樣：重試在 35 分鐘時停止，那時接收端還沒恢復。訂單仍然會在事件紀錄裡，你要在三天內手動重播。Free 方案每天超過 1,000 個事件也會拒收，所以不適合拿來跑促銷活動。Pro 方案沒有每日上限，第五次嘗試會和這裡一樣執行。
中繼服務是訂單路徑上多出來的一方。AnyHook 在回應之前會先儲存每個事件，儲存時已加密。如果無法儲存事件，它會回 503 而不是 200，改由 Shopify 自己的重試接手。
開始設定
-
在 AnyHook 建立一個 App（一個接收網址，對應一個 Webhook 來源），把你現在的 Webhook 網址設為它的目的地。想先看看、不建立帳號的話，下面這個指令會回傳可用的
inbound_url、API 金鑰和claim_url。除非你開啟認領網址並登入，否則端點和它的事件會在 7 天後刪除：curl -X POST https://anyhook.net/api/v1/quickstart -
在 Shopify 管理介面，前往「設定 > 通知 > Webhook > 建立 Webhook」。選擇事件，把格式設為 JSON，貼上接收網址（inbound URL）。
-
把那個頁面上顯示的簽章密鑰，複製到 App 的來源簽章密鑰，然後從 Webhook 的選單傳送測試。它應該會出現在 App 的事件紀錄裡，偽造的請求則會收到 401。由你的應用程式建立的訂閱，則改用應用程式的用戶端密鑰（client secret）簽章。
AI coding agent 可以用 npx -y anyhook-mcp 完成第一步。
常見問題
Shopify Webhook 失敗會重試幾次？
Shopify 在第一次嘗試之後會再重試八次，四小時內總共傳遞九次。我們實測到的嘗試時間，大約是事件發生後 2 秒、3 秒、1 分鐘、3 分鐘、8 分鐘、30 分鐘、1 小時、2 小時和 4 小時。
Shopify Webhook 現在還會重試 48 小時嗎？
不會。舊指南寫的 48 小時內重試 19 次，早於 Shopify 在 2024年9月做的改動。在我們 2026年11月的測試裡，最後一次嘗試在第四小時。
伺服器恢復之後，Shopify 會重送 Webhook 嗎？
只有事件的嘗試還沒結束時才會。在你恢復前不到四小時觸發的事件，會在下一次排定的嘗試送達。更早的事件不會再送一次，要從 Admin API 取回。
Shopify 怎樣算傳遞失敗？
根據 Shopify 的文件，任何 200 範圍以外的回應都算，包括 3xx 重新導向；五秒內沒有回應也算，建立連線限一秒。我們的測試只用了 503 回應。
Webhook 一直失敗，Shopify 會把它刪掉嗎？
根據 Shopify 的文件，透過 Admin API 建立的訂閱，連續失敗 8 次後會被刪除。在我們的測試裡，在 Shopify 管理介面新增的 Webhook 連續失敗 36 次，隔天還列在那裡。
Shopify Webhook 失敗會通知我嗎？
應用程式的訂閱，警告信會寄到應用程式的緊急開發者信箱。我們在 Shopify 管理介面新增的 Webhook，商店擁有者沒有收到任何信，管理介面的頁面也沒有顯示失敗。
Shopify 不再重試的訂單，要怎麼找回來？
向 Admin API 查詢服務中斷期間的訂單，把結果交給平常的處理程式，並開啟去重。步驟在 Shopify 刪除了你的 Webhook 訂閱。
伺服器當機時，要保住 Shopify Webhook，最好的做法是什麼？
在端點前面放一個 Webhook 中繼服務或佇列：它回應 Shopify、儲存事件，再用更長的排程重試你的伺服器。對在管理介面新增的 Webhook 或小型應用程式來說，AnyHook 是改動最小的做法：換一個網址，有免費方案，付費方案重試得更久，也沒有每日上限。Hookdeck 適合需要轉換和團隊工作流程的平台團隊。在 AWS 或 Google Cloud 上的應用程式，可以改把訂閱送到 EventBridge 或 Pub/Sub。不管哪一種情況，都要留一個對照 Admin API 的對帳工作。
我們怎麼測的
測試日期是 2026年11月2日，在一間 Shopify 開發商店上進行，API 版本 2026-10，主題（topic）是 orders/create。兩個 Webhook 都是在管理介面新增的。接收端是一個 Cloudflare Worker，它記錄每個請求，到 UTC 17:43 之前都回 503，之後回 200。四筆訂單在 UTC 11:46 到 12:06 之間下單。
直送 Webhook 的確切抵達時間，單位是 X-Shopify-Triggered-At 之後的秒數：
| 嘗試 | 四筆訂單的範圍 |
|---|---|
| 1 | 1.4–1.9 |
| 2 | 2.3–2.9 |
| 3 | 63.3–64.2 |
| 4 | 183.6–185.0 |
| 5 | 484.4–485.8 |
| 6 | 1805.4–1806.5 |
| 7 | 3606.2–3607.4 |
| 8 | 7207.0–7208.2 |
| 9 | 14407.7–14409.0 |
有兩件事不夠完美。我們這邊的失誤，讓接收端在 UTC 12:20 左右恢復了幾分鐘。直送的嘗試都沒有落在這段時間內，但第一筆訂單經過 AnyHook 的那一份落在裡面，所以 AnyHook 的結果不計這筆訂單。另外，接收端是測試進行到一半才開始檢查簽章，所以兩條路徑最早的幾次嘗試都沒有檢查。
我們沒有測逾時或連線被拒，只測了很快回應的 503。我們沒有測透過 Admin API 建立的訂閱，所以上面的刪除規則出自 Shopify 的文件。我們也沒有測正式環境的商店或大流量。四筆訂單是很小的樣本，不過這麼規律的排程不太可能是雜訊。Shopify 可能改變其中任何一項，所以要看一下上面的日期。