重複配送防止

ほとんどのシステムでは、すぐに応答が得られない場合、Webhookを再試行します。もし最初の試行が実際に届いていた場合、1つのイベントに対してShopify Flowワークフローが2回実行されてしまいます。その結果、2通目のメールが送信されたり、タグが重複したり、注文メモが重複して追加されたりすることになります。

重複配信防止機能により、そのような事態を防ぎます。この機能は、すべてのWebhookにおいて、デフォルトではオフになっています。

仕組みについて

送信システムにイベントごとの一意のIDが含まれている場合は、**「詳細設定」→「重複配信の検出」**で、そのIDを格納するヘッダーに名前を付けてください。

行動
指定されたIDを持つ最初のリクエスト 通常通り処理すると、Shopify Flowが実行されます。
24時間以内に再度行ってください 200 OK duplicate: true を使用 - Shopify Flow には送信されません
別のID 通常通り処理されました
そのヘッダーを含まないリクエスト 通常通り処理されました
この欄は空欄のままです すべてのリクエストが処理されましたが、何も変わりません

一般的なヘッダー名:Event-Id、Idempotency-Key、X-Request-Id。大文字と小文字は区別されません。

bash
# 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」を含めることで、レスポンスをログに記録する際、2つの結果を区別できるようになります。

重複が発生する箇所

非表示にされた重複:

  • 呼び出し履歴のエントリは作成されないため、ご利用プランのカウントには含まれません
  • Webhookを編集中には、Live Request Inspectorに表示されますが、 「非表示の重複」としてマークされています

この組み合わせは意図的なものです。利用履歴や上限に不審な記録が残ることはありませんが、通話履歴がこっそりと消えてしまったように見えることもありません。

適切なヘッダーの選び方

IDは再試行を通じて一貫性が保たれており**、イベントごとに一意である**必要があります。これこそが、この仕組みのすべてです。

適切:イベントが発生した際に、送信者が一度だけ生成するイベントIDまたはイデポテンシーキーです。

不正であり、保存時に拒否されます:X-Forwarded-For、CF-*、X-Signature などのプロキシ制御ヘッダーです。これらの値はリクエストごと、あるいはホップごとに変化するため、リピートと一致することは決してなく、明示的なエラーではなく黙って失敗します。

重複排除ストアが一時的に利用できない場合

配信は、単に破棄されるのではなく、処理されます。ワークフローの実行が重複することは、イベントの消失に比べてはるかに軽微な問題であるため、この機能は設計上、安全側を優先するように動作します。