重複送達防護

大多數系統在未收到即時回覆時，會重新嘗試觸發 webhook。如果第一次嘗試確實送達，您的 Shopify Flow 工作流程就會針對同一事件執行兩次 - - 導致寄出第二封電子郵件、標籤重複，或是訂單備註被重複記錄。

「防止重複傳送」功能可避免這種情況發生。此功能在每個 Webhook 上預設皆為關閉狀態。

運作原理

如果您的發送系統為每個事件都包含一個唯一識別碼，請在**「進階設定」→「重複送達偵測」**中，為攜帶該識別碼的標頭命名。

	行為
具有特定 ID 的第一個請求	若按常規處理，將觸發 Shopify Flow
請於 24 小時內重複此操作	200 OK 使用 duplicate: true - - 未寄送至 Shopify Flow
一個不同的 ID	已正常處理
請勿包含該標頭的請求	已正常處理
該欄位未填寫	每個請求均已處理 - - 一切如常

常見的標頭名稱：Event-Id、Idempotency-Key、X-Request-Id。比對時不區分大小寫。

# Same Event-Id twice - the second is accepted but not re-sent to Flow
curl -X POST https://your-app-url/webhook/ab12cd34 \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: your-token" \
  -H "Event-Id: evt_12345" \
  -d '{"orderId":"1001"}'

為什麼重複操作仍會傳回 200

非 2xx 狀態碼的回應，正是讓發送者更難重新嘗試的原因。回傳 200 會告知對方事件已安全處理完畢，因此會停止操作；而若在回應正文中包含 duplicate: true，則能在記錄回應時區分這兩種結果。

重複項目出現在哪裡

一則被隱藏的重複貼文：

• 不會建立任何呼叫記錄，因此不會計入您的方案配額
• 在編輯 webhook 時，它確實會出現在「即時請求檢視器」中， 被標記為「已隱藏的重複內容」

這種組合是經過深思熟慮的：您的通話紀錄和通話配額仍保持完好，但通話絕不會看起來像是悄無聲息地消失了。

選擇合適的標題

該 ID 必須在重試過程中保持穩定，且每個事件都必須是唯一的 - - 這就是整個機制。

正確：事件發生時，由發送方生成一次的事件識別碼或冪等鍵。

不正確，且在儲存時遭拒絕：由代理伺服器控制的標頭，例如 X-Forwarded-For、CF-* 或 X-Signature。由於其值會隨每次請求或每次跳躍而改變，因此永遠無法與重複項目匹配 - - 這類情況會靜默失敗，而非明確報錯。

如果去重儲存區短暫無法使用

傳送操作會被處理，而非直接放棄。相較於事件遺失，工作流程重複執行所造成的問題要輕微得多，因此此功能在設計上採用「開放式失敗」機制。