Protection contre les livraisons en double
La plupart des systèmes réessaient d'envoyer un webhook lorsqu'ils ne reçoivent pas de réponse rapide. Si la première tentative a bien été reçue, votre workflow Shopify Flow s'exécute deux fois pour un même événement : un deuxième e-mail, une balise en double, une note de commande répétée.
La protection contre les envois en double empêche cela. Elle est désactivée par défaut sur tous les webhooks.
Comment cela fonctionne
Si votre système d'envoi inclut un identifiant unique par événement, indiquez le nom de l'en-tête qui le contient dans « Paramètres avancés » -> « Détection des doublons ».
| Comportement | |
|---|---|
| Première requête avec un identifiant donné | Traité normalement, les incendies se propagent |
| Répétez l'opération dans les 24 heures | 200 OK avec duplicate: true - non envoyé à Shopify Flow |
| Un identifiant différent | Traité normalement |
| Demande sans cet en-tête | Traité normalement |
| Champ laissé vide | Chaque demande est traitée - rien ne change |
Noms d'en-têtes courants : Event-Id, Idempotency-Key, X-Request-Id. La correspondance ne tient pas compte de la casse.
# 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"}'Pourquoi la répétition renvoie-t-elle toujours 200 ?
C'est précisément une réponse autre qu'un code 2xx qui complique la tâche de l'expéditeur lorsqu'il doit réessayer. En renvoyant 200, vous lui indiquez que l'événement a été géré en toute sécurité, ce qui lui permet d'arrêter la tentative ; tandis que l'utilisation de duplicate: true dans le corps de la réponse vous permet de distinguer les deux résultats si vous consignez les réponses.
Lorsque des doublons apparaissent
Un doublon supprimé :
- ne crée aucune entrée dans l'historique des appels ; elle n'est donc pas prise en compte dans le calcul de votre forfait
- apparaît bien dans l'Inspecteur de requêtes en direct lorsque vous modifiez le webhook, signalé comme doublon supprimé
Cette combinaison est voulue : votre historique et votre quota restent intacts, mais un appel ne donne jamais l'impression d'avoir disparu sans crier gare.
Choisir l'en-tête approprié
L'identifiant doit rester stable tout au long de la nouvelle tentative et être unique pour chaque événement : c'est là tout le principe du mécanisme.
Valide : un identifiant d'événement ou une clé d'idempotence généré(e) une seule fois par l'expéditeur au moment où l'événement se produit.
Inadmissibles et rejetés au moment de la sauvegarde : les en-têtes contrôlés par un proxy, tels que X-Forwarded-For, CF-* ou X-Signature. Leur valeur change à chaque requête ou à chaque saut ; ils ne correspondraient donc jamais à une répétition, ce qui entraînerait un échec silencieux plutôt qu’un échec signalé de manière explicite.
Si la boutique de déduplication est temporairement indisponible
La transmission est traitée plutôt que rejetée. Une exécution en double du workflow constitue un problème bien moins grave qu'un événement perdu ; c'est donc par conception que cette fonctionnalité privilégie la sécurité.