Authentification

Toute personne connaissant l'URL d'un webhook peut lui envoyer une requête ; c'est donc l'authentification qui empêche un inconnu de déclencher vos workflows Shopify Flow. Configurez-la pour chaque webhook, dans la section « Sécurité » de celui-ci.

Les trois méthodes

Méthode	Comment l'appelant prouve son identité	Utilisez-le lorsque
Aucun	Rien	À des fins de test uniquement - jamais en production
Jeton statique	Une clé secrète fixe dans un en-tête de requête	Presque toutes les intégrations (n8n, Make, Zapier, votre propre code)
HMAC SHA-256	Une signature calculée à partir de la requête et d'un secret partagé	L'expéditeur signe ses webhooks (Stripe, GitHub, Slack, …)

Jeton statique

Cliquez sur le bouton « Générer » du webhook pour obtenir un jeton aléatoire sécurisé, ou collez le vôtre. L'appelant l'envoie dans un en-tête :

L'éditeur de webhooks : le nom et l'authentification à gauche, la fiche « Endpoint » avec l'état, l'URL du webhook et l'identifiant du webhook à droite, au-dessus des boutons « Aperçu en direct », « Tester » et « Utilisation » — Un jeton statique : choisissez la manière dont l'expéditeur doit le transmettre, générez ou collez le jeton, puis copiez l'URL du webhook à partir de la fiche « Endpoint ».

bash

curl -X POST https://your-app-url/webhook/ab12cd34 \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: your-token" \
  -d '{"orderId":"1001"}'

Modification du nom de l'en-tête

Certains systèmes ne peuvent envoyer qu'un en-tête qu'ils utilisent déjà. Définissez le nom de l'en-tête d'authentification dans les « Paramètres avancés » et nous lirons le jeton à partir de cet en-tête plutôt que de l'en-tête X-Api-Key :

bash

  -H "X-Custom-Auth: your-token"

La casse des noms d'en-tête n'a pas d'importance. Les noms réservés sont rejetés : Host, Authorization, Cookie, X-Forwarded-*, X-Webhook-*, CF-* et autres noms similaires. Ceux-ci sont définis ou réécrits par les proxys et les CDN ; par conséquent, un jeton lu à partir de l'un d'entre eux pourrait être contrôlé par un attaquant.

Le parcours du jeton

Tous les expéditeurs ne peuvent pas ajouter un en-tête de leur choix. Comment l'expéditeur transmet-il le jeton ? L'onglet « Webhook » propose quatre emplacements :

Choix	L'expéditeur envoie	Utilisez-le lorsque
Dans un en-tête personnalisé	`X-Api-Key: <token>` ou le nom d'en-tête de votre choix	Le comportement par défaut, et ce que font la plupart des intégrations
En tant que jeton au porteur	`Authorization: Bearer <token>`	L'outil comporte un champ « Bearer » ou « API-token »
En tant que nom d'utilisateur et mot de passe	HTTP Basic, avec un nom d'utilisateur de votre choix et le jeton comme mot de passe	Cet outil ne prend en charge que l'authentification de base
Dans l'URL	`?token=<token>` ou le nom de paramètre de votre choix	L'expéditeur ne peut appeler qu'une URL simple et ne peut pas définir d'en-têtes

Authorization Le nom de l'en-tête personnalisé « Bearer » est délibérément réservé : les méthodes « Bearer » et « Basic » sont prises en charge, et les deux sont gérées automatiquement pour vous. Une requête de type 401 utilisant l'une de ces deux méthodes comporte également un en-tête WWW-Authenticate, car de nombreux clients HTTP n'envoient leurs identifiants qu'après avoir reçu une demande d'authentification.

L'option « URL » est la moins sûre des quatre - les URL apparaissent dans les fichiers journaux, les référents et l'historique du navigateur - ; n'utilisez-la donc que lorsque l'expéditeur ne vous laisse pas d'autre choix. L'application affiche l'URL finale contenant le jeton et masque ce paramètre partout où elle enregistre la requête.

HMAC SHA-256

L'expéditeur calcule une signature de la requête à l'aide d'un secret partagé ; nous la recalculons et la comparons. Une requête qui a fait l'objet d'une fuite ne peut pas être réutilisée avec un contenu modifié, car le corps de la requête ne correspond plus à la signature.

Préréglages des fournisseurs

Sélectionnez votre fournisseur de signature dans la rubrique « Fournisseur de **signature **» et nous effectuerons la vérification en utilisant le schéma exact de ce fournisseur : nom de l'en-tête, encodage, éléments signés et durée de validité de la signature. Collez la clé de signature depuis son tableau de bord et le tour est joué.

Il existe 22 fournisseurs intégrés, chacun disposant de son propre guide de configuration : Calendly, Customer.io, GitHub, Lemon Squeezy, Linear, Mollie, Paddle, Paystack, Razorpay, Sanity, Sendcloud, Sentry, Shopify, Slack, Square, Webhooks standard (OpenAI, Supabase), Stripe, Svix (Clerk, Resend), Typeform, Vercel, WooCommerce et Zendesk. Si le vôtre ne figure pas dans cette liste, veuillez décrire comment il s'authentifie à l'aide d'un schéma personnalisé.

Consultez la page Vérification des webhooks signés pour obtenir la liste complète, découvrir l'option personnalisée et utiliser l'outil de vérification des signatures intégré.

Un webhook avec authentification HMAC et Stripe comme fournisseur de signature, présentant le champ « Secret de signature », ce qu’il vérifie et les étapes de connexion à Stripe — Un expéditeur signé, ici Stripe : sélectionnez le fournisseur, collez sa clé de signature, et l'éditeur affiche les éléments cochés ainsi que la procédure à suivre pour l'associer.

HMAC générique

En l'absence de paramètre prédéfini et de schéma personnalisé, nous utilisons notre propre méthode : l'appelant envoie X-Signature, c'est-à-dire le HMAC-SHA256 des valeurs de l'en-tête X-Webhook-*, calculé à l'aide de la clé de signature.

bash

curl -X POST https://your-app-url/webhook/ab12cd34 \
  -H "Content-Type: application/json" \
  -H "X-Webhook-Data: value1value2" \
  -H "X-Signature: <hmac-sha256 of the X-Webhook-* values>" \
  -d '{"data":"payload"}'

À quoi ressemble un refus ?

En cas d'échec de l'authentification, le code d'erreur 401 est renvoyé, accompagné d'un corps JSON indiquant la raison ; consultez Historique et dépannage pour obtenir la liste complète des codes. Les appels rejetés apparaissent toujours dans l'« Inspecteur de requêtes en temps réel » pendant que vous modifiez le webhook, ce qui vous permet de voir exactement pourquoi l'un d'entre eux a échoué.

Roter la clé sans interruption de service

La modification d'un secret en une seule étape implique que toutes les requêtes signées avec l'ancien secret échouent jusqu'à ce que l'expéditeur se soit mis à jour. La rotation du secret via le webhook permet d'éviter cela : elle conserve un deuxième secret valide qui est accepté parallèlement au secret principal, tant pour le jeton statique que pour tous les schémas de signature.

Saisissez le nouveau mot de passe dans le champ « **Deuxième mot de passe valide **», puis enregistrez. Les deux sont désormais acceptés.
Configurez l'expéditeur pour qu'il utilise la nouvelle clé secrète.
Cliquez sur « Promouvoir », ce qui le déplace dans le champ principal et efface le second, puis enregistrez.

Aucune requête n'est rejetée à aucun moment. Le deuxième secret est stocké exactement comme le secret principal et n'est jamais renvoyé par l'API ; celle-ci indique uniquement s'il est défini ou non.

Préserver le secret

Le jeton **n'**est jamais renvoyé par notre API REST ni par notre serveur MCP, quel que soit le niveau d'accès - ils Indiquez uniquement si l'un d'entre eux est défini. Voir API pour développeurs et MCP.
Les données sont chiffrées au repos.
La rotation prend effet immédiatement ; utilisez donc Shopify Flow pour la deuxième séquence secrète indiquée ci-dessus plutôt que en écrasant le champ principal.
L'historique des invocations enregistrées masque l'en-tête d'authentification, les identifiants Basic et le jeton d'URL, Ainsi, une capture d'écran de l'historique ne révèle pas votre secret.

Affiner davantage la recherche

L'authentification permet de vérifier que l'appelant connaît le secret. La vérification de l'origine de l'appel (Listes d'adresses IP autorisées) limite les sources d'où un appel peut provenir et peut être combinée avec n'importe lequel des modes mentionnés ci-dessus.