Ouvrez la section “Clés API & Webhooks” puis l’onglet “Webhooks” (ou “Webhook” selon l’interface). Vous devriez voir un champ URL et la liste des événements récents.

Collez l’URL complète de votre endpoint : commencez par https:// si possible. Vérifiez l’absence d’espaces ou de caractères non valides. Si votre endpoint nécessite un chemin précis, incluez-le.
Note technique : le champ d’URL est maintenant validé côté interface pour correspondre au schéma en base de données — le schéma (http:// ou https://) doit être présent, aucun espace n’est autorisé, et la longueur maximale acceptée par l’interface est étendue (jusqu’à 2048 caractères pour les URLs longues). Le backend accepte désormais des URLs plus longues et complexes (reliquat de requêtes longues ou parametrées). :

Si votre endpoint attend un header d’authentification ou un token, configurez-le côté destinataire. Notez : l’interface peut ne pas envoyer d’en-têtes personnalisés automatiquement — configurez la protection côté serveur (ex. clé dans header). :

Avant d’enregistrer, testez que l’URL est joignable (ouvrir l’URL dans un onglet ne suffit pas toujours — utilisez un outil de test webhooks ou envoyez une requête d’essai depuis votre environnement de test). Si votre URL contient de longs paramètres ou des chaînes encodées, vérifiez aussi que le serveur destinataire accepte ces longueurs et formats. :

Après vérification, gardez la page ouverte et passez à la sélection des événements (voir workflows ci‑dessous). La sauvegarde finale est traitée dans la section « Sauvegarder la configuration ».

Repérez la ligne ou le champ contenant l’URL actuelle et cliquez sur modifier (ou placez le curseur dans le champ). :

Remplacez l’URL par la nouvelle, vérifiez le format (HTTPS recommandé) et corrigez tout slash en doublon. Rappel : l’interface appliquera les mêmes validations que la base (présence du schéma, pas d’espaces, longueur maximale étendue — jusqu’à 2048 caractères); adaptez l’URL en conséquence. :

Utilisez un événement connu dans la liste des événements récents (sélectionnez-le et copiez son payload) pour simuler un envoi vers la nouvelle URL. :

Regardez la colonne statut et le message d’erreur (le cas échéant) pour confirmer que le nouvel endpoint répond comme attendu. :

Cliquez sur “Enregistrer” pour appliquer la modification. Notez que la sauvegarde provoque le rechargement de la configuration applicative (voir avis ci‑dessous).

La page affiche des événements récents regroupés par date. Parcourez la liste pour repérer les types d’événements pertinents. :

Si votre cas d’usage nécessite de reproduire un incident ancien, utilisez le bouton “Charger plus” (ou équivalent) pour récupérer des événements plus anciens. :

Activez uniquement les catégories nécessaires (ex. paiements, abonnements, erreurs). Moins d’événements = moins de trafic et plus de lisibilité. :

Certaines catégories proposent des sous-événements (ex. types d’actions précises). Cochez ou décochez au niveau fin pour éviter l’envoi d’informations redondantes. :

Après avoir défini la sélection, sauvegardez (voir section suivante). Vérifiez ensuite le flux d’événements entrants côté destinataire. :

Lorsque vous modifiez à la fois l’URL et la sélection d’événements, gardez en tête que les validations d’URL (schéma, longueur, caractères) sont appliquées côté UI avant enregistrement pour éviter des erreurs au moment du sauvegarde. :

Dans la liste d’historique, cliquez sur un événement pour l’afficher. Vous verrez le payload et, le cas échéant, le message d’erreur renvoyé par le destinataire. :

Les payloads peuvent contenir des champs JSON encodés sous forme de chaînes. Utilisez l’option “nettoyer” (cleanJson) ou collez le texte dans un éditeur JSON pour dé‑double‑encoder les champs. Cela rend le payload lisible et exploitable. :

Cliquez sur “Copier le payload” pour récupérer le JSON formaté (ou sur “Copier le message d’erreur” si vous déboguez une erreur). :

Utilisez un outil de test (webhook tester en ligne, client HTTP, ou votre environnement de pré-prod) et collez le payload pour simuler l’envoi. Vérifiez la réponse HTTP et les logs côté destinataire. :

Les statuts ont des repères visuels : vert = réussite, bleu = redirection/info, jaune = client error, rouge = erreur serveur. Utilisez ces indices pour prioriser le dépannage.

Relisez l’URL, la sélection d’événements et vos tests précédents. Assurez‑vous que l’URL ne crée pas de boucles (ex. renvoi vers la même application). Note technique : la structure du champ en base de données a été mise à jour pour accepter des URLs plus longues et complexes — l’interface applique donc les mêmes validations avant l’enregistrement (schéma requis, pas d’espaces, longueur maximale étendue). :

Appuyez sur le bouton d’enregistrement. Un indicateur de chargement s’affiche pendant l’opération. :

Une notification confirme la sauvegarde (ex. “Modification du webhook enregistrée”). La configuration applicative est alors rechargée pour prendre effet. :

Après le rechargement, contrôlez l’historique des événements récents pour vérifier que les envois se poursuivent vers la nouvelle URL et que les codes de statut sont corrects. :

Si vous travaillez en équipe, prévenez les personnes impactées du bref reload et des changements appliqués.