Paramètres de la boutique

Comment configurer des webhooks pour envoyer des événements de commande et de session vers une API ou un e-mail ?

Créez et gérez les webhooks du magasin dans Paramètres : choisissez API ou E-mail, sélectionnez l’événement session-created, order-created ou order-updated, utilisez des URLs {{placeholder}}, et découvrez la limite de 20 webhooks, la reprise, et l’e-mail d’échec après 5 erreurs.

Ce que font les webhooks

Un webhook s’abonne à un événement spécifique du magasin. Lorsque cet événement se produit, Storeep envoie immédiatement les données de l’événement à une URL que vous indiquez (type API) ou à une adresse e-mail que vous indiquez (type E-mail). Les webhooks sont souvent utilisés pour des intégrations de suivi de commandes, des synchronisations CRM, des conversions de plateformes publicitaires et des notifications automatisées.

Pour gérer les webhooks, allez dans Paramètres → Webhooks. Vous devez disposer de la permission settings pour consulter ou modifier les webhooks.

Limites des webhooks

Maximum 20 webhooks par magasin. Tenter d’en ajouter un 21e renvoie l’erreur « Vous avez atteint le maximum de 20 webhooks par magasin ».
La liste affiche les webhooks du plus récent au plus ancien, paginée à 40 par page.

Créer un webhook

Cliquez sur Ajouter un nouveau webhook, remplissez les champs ci-dessous, puis cliquez sur Ajouter.

Activer

Coché par défaut. Si coché, le webhook est actif dès que vous l’enregistrez et les événements correspondants sont envoyés. Décochez pour enregistrer le webhook à l’état désactivé, il ne recevra rien. Vous pouvez changer cela à tout moment en modifiant le webhook.

Nom

Obligatoire. Maximum 50 caractères.
Un libellé descriptif affiché dans la liste, par exemple Facebook CAPI commande créée.

Type

API : Storeep envoie une requête HTTP POST contenant les données de l’événement à votre URL.
E-mail : Storeep envoie un e-mail contenant les données de l’événement à votre adresse.

Événement

L’événement du magasin qui déclenche le webhook. Trois événements existent :

Session créée : une nouvelle session visiteur est créée dans votre magasin.
Commande créée : une nouvelle commande est passée.
Commande mise à jour : le statut ou les données d’une commande existante changent.

Important : le type E-mail ne transmet que Commande créée et Commande mise à jour. Si vous choisissez E-mail avec Session créée, le webhook sera enregistré mais n’enverra jamais rien. Utilisez le type API si vous avez besoin de l’événement session.

Format

Une seule option, Json : la charge utile est envoyée sous forme de document JSON.

URL (type API uniquement)

Obligatoire si le type est API. Maximum 500 caractères.
Le champ affiche un préfixe https:// pour vous, saisissez donc uniquement l’hôte et le chemin, par exemple api.example.com/events/order. Si vous collez une adresse complète https:// ou http://, le préfixe est supprimé avant l’enregistrement.
Espaces réservés dynamiques : insérez n’importe quel champ des données de l’événement dans l’URL avec la syntaxe à double accolades {{field_name}}. Exemple : example.com/postback?cid={{fbclid}}&payout={{order_total}}. Les valeurs sont encodées pour l’URL, et un espace réservé dont le champ est absent sera vide. Cela vous permet d’envoyer des données de conversion directement à une plateforme publicitaire sans proxy.
L’adresse est validée après suppression des espaces réservés, donc une URL invalide renvoie « L’url saisie est incorrecte ».

Adresse e-mail (type E-mail uniquement)

Obligatoire si le type est E-mail. Doit être une adresse valide, maximum 127 caractères.

Modifier un webhook

Cliquez sur une ligne pour ouvrir l’éditeur. Tous les champs sont modifiables. Le champ URL est prérempli uniquement si le type enregistré est API, et le champ e-mail uniquement si le type enregistré est E-mail. Cliquez sur Enregistrer pour appliquer. Enregistrer avec Activer décoché désactive le webhook sans le supprimer.

Colonnes de la liste des webhooks

Nom : le libellé avec sa date de création.
URL / E-mail : la destination.
Type : API ou E-mail.
Événement : Session créée, Commande créée ou Commande mise à jour.
Format : Json.
Statut : Activé ou Désactivé.

Supprimer un webhook

Sélectionnez une ou plusieurs lignes et cliquez sur Supprimer les webhooks. La suppression est définitive et arrête tous les envois futurs pour cet abonnement.

Livraison, reprises et e-mails d’échec

Cette section concerne les webhooks de type API. Les webhooks E-mail sont envoyés une seule fois sans reprise ni suivi d’échec.

Comportement de reprise

Chaque requête a un délai d’attente de 5 secondes. Si la cible renvoie une erreur 5xx, 429 (limite de débit) ou est injoignable (erreur de connexion), la livraison est considérée comme un échec temporaire et sera retentée.
Après le premier échec, Storeep retente avec un délai exponentiel jusqu’à 5 reprises : environ 30s, 60s, 120s, 240s puis 480s plus tard. Après la dernière tentative, l’événement est abandonné.
Une réponse 4xx autre que 429 (par exemple 404 ou 403) est considérée comme un échec définitif. Storeep ne retente pas, car une cible erronée ou refusant ne se corrigera pas d’elle-même.
Si vous avez plusieurs webhooks sur le même événement, une reprise ne renvoie qu’aux webhooks ayant échoué. Les cibles ayant déjà répondu avec succès sont ignorées, vous n’aurez donc pas de doublons.

E-mail de notification d’échec

Storeep compte les échecs consécutifs par webhook. Après 5 échecs consécutifs, le propriétaire du magasin reçoit un e-mail intitulé « Action requise : votre webhook Storeep échoue », dans la langue du propriétaire, listant le nom du webhook, la destination, l’événement et le dernier code HTTP.
Vous recevez exactement un e-mail par série d’échecs. Aucun autre e-mail n’est envoyé tant que le webhook n’est pas rétabli.
Dès qu’une livraison réussit à nouveau, le compteur d’échecs est remis à zéro et la notification est réarmée, donc une future série d’échecs pourra à nouveau vous alerter.

Conseils et pièges

Vous pouvez créer plusieurs webhooks pour le même événement, par exemple envoyer Commande créée à la fois à un CRM et à une plateforme publicitaire en deux entrées distinctes.
Si votre cible nécessite une authentification, placez un jeton dans la chaîne de requête de l’URL, soit en dur, soit via un {{placeholder}} issu des données de l’événement, ou placez un proxy qui ajoute l’authentification avant de transférer.
Session créée se déclenche pour chaque session visiteur unique et peut générer un volume élevé sur les magasins fréquentés. Abonnez-vous uniquement si votre cible peut gérer ce flux, et souvenez-vous que cela ne fonctionne qu’avec le type API.