Historique et dépannage
Chaque requête qui parvient à un webhook est enregistrée, qu'elle soit acceptée ou rejetée. L'historique est le premier endroit où il faut chercher lorsque quelque chose ne s'est pas produit.
Lecture d'une invocation
Ouvrez l'historique et cliquez sur une entrée. Vous obtiendrez l'horodatage, le statut, l'expéditeur, la durée, le payload, les en-têtes de requête (masqués), la chaîne de requête et, en cas d'échec, l'erreur ainsi que chaque tentative de réessai.
| Statut | Signification |
|---|---|
| En attente | Accepté et mis en file d'attente, pas encore transmis à Shopify Flow |
| Succès | Shopify Flow a accepté le déclencheur |
| Échec | Échec définitif de la livraison : la page de détails en explique la raison |
La colonne « Invoked by » vous indique d'où provient un appel : User (un système externe), Flow (une action Shopify Flow appelant le webhook), Test (le bouton « Test ») ou CURL.
Les refus et ce que chacun d'entre eux signifie
Une requête rejetée n'est jamais transmise à Shopify Flow. Le corps de la réponse contient une code lisible par machine :
| Code | HTTP | Qu'est-ce qui a mal tourné ? | Corriger |
|---|---|---|---|
webhook_not_found |
404 | Code court inconnu | Vérifiez l'URL ; il se peut que le webhook ait été supprimé |
webhook_disabled |
400 | Le webhook est désactivé | Activez-le sur la page des webhooks |
unauthorized |
401 | Jeton manquant ou incorrect | Vérifiez le jeton et le nom de l'en-tête |
missing_signature |
401 | Mode HMAC, sans en-tête de signature | Envoyez l'en-tête de signature attendu par votre préréglage |
invalid_signature |
401 | La signature ne correspondait pas | Vérifiez que le secret de signature est correct et que le corps du message n'a pas été modifié pendant la transmission |
auth_not_configured |
401 | Le mode d'authentification est activé, mais aucun jeton n'a été enregistré | Enregistrez un jeton sur le webhook |
invalid_json |
400 | Le corps du message n'est pas au format JSON valide | Envoyez un JSON valide, ou définissez le type de contenu (Content-Type) correspondant réellement au contenu de votre corps de message (les données de formulaire et le XML sont également pris en charge) |
invalid_body |
400 | Il n'a pas été possible de lire un formulaire ou le corps XML, ou bien le corps correspond à la chaîne littérale null. |
Envoyez un objet JSON ou un corps de message dont le type de contenu correspond à celui-ci |
mapping_field_missing |
400 | Un champ mappé est absent de la payload | Envoyez le champ ou désactivez son mappage |
unexpected_fields |
400 | Le corps comporte des champs qui ne sont pas mappés | Mettez-les en correspondance, supprimez-les ou activez l'option « Autoriser le corps de requête personnalisé » |
ip_not_allowed |
403 | L'adresse de l'appelant ne figure pas sur la liste blanche d'adresses IP du webhook | Voir Listes d'adresses IP autorisées |
invalid_proxy_signature |
401 | L'adresse proxy de l'application a été appelée directement, et non via le domaine de votre boutique | Utilisez l'URL du webhook exactement telle qu'elle s'affiche dans l'application - voir CORS, l'URL du proxy de l'application et les requêtes du navigateur |
payload_too_large |
413 | Payload de flux supérieure à 50 Ko | Envoyez moins de données ou désactivez les boutons de commande relatifs aux données de requête |
quota_exceeded |
400 | Limite du forfait atteinte | Voir Forfaits et utilisation |
Inspecteur des demandes en temps réel
Lorsque vous avez un webhook ouvert dans l'éditeur, l'inspecteur affiche les requêtes qui arrivent en temps réel, y compris celles qui ont été rejetées, avec la raison correspondante. C'est de loin le moyen le plus rapide de déboguer un expéditeur : lancez une requête et observez-la aboutir.
Les doublons supprimés apparaissent également ici, accompagnés d'une mention indiquant qu'il s'agit de doublons - voir Protection contre les livraisons en double.
Rediffusion
Toute invocation antérieure peut être relancée à partir de sa page de détails. La relance consiste à renvoyer la même payload via le même webhook.
Il est particulièrement efficace dans deux domaines :
- Créer un workflow Flow. Enregistrez les événements sur le déclencheur Webhook, puis reproduisez un véritable Appelez cette fonction afin que Shopify Flow mémorise les noms réels de vos champs.
- Récupération après une interruption du workflow. Corrigez le workflow, puis relancez les événements qui se sont exécutés. même si c'était une erreur.
Les rediffusions sont signalées comme telles dans l'historique et ne sont pas prises en compte dans votre forfait.
Situations courantes
Des appels sont reçus, mais le workflow ne s'exécute pas. Cela est presque toujours dû à la condition relative à l'identifiant du webhook. Un workflow déclenché par un webhook reçoit des événements provenant de tous les webhooks dont vous disposez ; il nécessite donc une condition correspondant à l'identifiant spécifique du webhook concerné - voir Créez votre premier webhook.
Le workflow s'exécute deux fois. Soit deux workflows utilisent le déclencheur « Webhook » sans conditions distinctes, soit votre expéditeur effectue une nouvelle tentative. L'historique vous indique de quel cas il s'agit : deux entrées signifient que deux requêtes ont été reçues. Activez l'option Protection contre les livraisons en double.
Il n'y a absolument rien dans l'historique. La requête ne nous est jamais parvenue. Vérifiez l'URL et le code court, et assurez-vous que l'expéditeur ne rencontre pas de problème de TLS ou de DNS de son côté.
Le statut reste bloqué sur « En attente ». La livraison est réessayée avec un délai d'attente ; en cas d'échec définitif, le statut passe à « Échec » avec indication du motif. Si le statut reste « En attente » pendant une durée inhabituellement longue, veuillez vérifier status.codecreationlabs.cloud.