重复配送防护

大多数系统在未收到快速响应时会重试 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 在重试过程中必须保持稳定，并且每个事件的 ID 必须是唯一的 - - 这就是整个机制。

正确：事件发生时由发送方生成一次的事件 ID 或幂等键。

无效，且在保存时被拒绝：由代理控制的头部，例如 X-Forwarded-For、CF-* 或 X-Signature。这些头部的值会随每次请求或每次跳转而变化，因此永远无法与重复项匹配 - - 它们会静默失败，而非发出明确错误提示。

如果去重存储暂时不可用

该交付操作会被处理，而非被丢弃。工作流程重复执行的问题远比事件丢失要小得多，因此该功能按设计采取“容错”策略。