Activer et tester un webhook

Avant de commencer, réunissez :

• une URL de réception publique, qui accepte les requêtes POST et répond immédiatement ;
• la clé de l’événement que vous voulez recevoir (voir le catalogue des événements) ;
• dix minutes.

Étape 1 : obtenir une URL de réception

Outil no-code (Make, Zapier)

C’est le chemin le plus simple, et celui que suivent la plupart des marchands Ciklik.

• Ajoutez un module « Custom webhook » dans un nouveau scénario Make.
• Copiez l’URL que Make vous donne.
• Faites-la activer par Ciklik pour la clé d’événement voulue (voir l’étape 2 ci-dessous).
• Une fois le premier envoi reçu, cliquez sur le bouton « Redetermine data structure » du module webhook dans Make : les champs de l’événement deviennent alors utilisables dans la suite de votre scénario.

Le même principe vaut pour Zapier : créez un déclencheur « Catch Hook » et suivez les mêmes étapes.

Votre serveur

Une adresse de votre application qui accepte le POST JSON et répond immédiatement suffit. Pour construire cette URL de réception, votre développeur trouvera le contrat complet de la requête dans Comprendre un envoi de webhook et les erreurs à éviter dans Bonnes pratiques et dépannage.

Outil de capture

Un service public de type webhook.site permet de voir à quoi ressemble un envoi en deux minutes, sans rien coder.

Attention

L’URL générée par ces outils est publique : toute personne qui la connaît peut lire les données de vos clients. N’utilisez cette méthode qu’avec un compte de test, jamais en production.

Étape 2 : faire activer l’événement

1. Choisissez la clé de l’événement dans le catalogue.
2. Transmettez la clé et l’URL de réception à l’équipe Ciklik, ou déclarez-les vous-même par l’API.
3. Attendez la confirmation : l’activation devient effective en moins d’une minute.

Il n’y a pas d’écran en libre-service

Il n’existe pas de page dans votre tableau de bord pour lister ou modifier vos webhooks vous-même. Deux règles à connaître :

• une seule URL de réception par événement : une nouvelle URL remplace la précédente, sans avertissement ;
• votre URL ne doit jamais rediriger, même d’HTTP vers HTTPS ou pour ajouter une barre oblique finale. Sur une redirection, le contenu de l’envoi est perdu.

Étape 3 : déclencher un premier envoi

Faites ces tests sur un compte client de test, jamais sur un client réel.

Ce que vous faites	Événement	Délai
Créer un compte client de test	created_user	immédiat
Créer une adresse pour ce compte	created_address	immédiat
Modifier l’adresse de ce compte de test	updated_address	immédiat
S’inscrire à la newsletter avec une adresse e-mail de test	created_optin	environ 10 secondes
Passer une commande	created_checkoutorder, puis created_checkouttransaction, puis created_checkoutinvoice	environ 10 secondes pour la commande et la transaction, 15 secondes pour la facture

Passer une commande exige un paiement réel : utilisez un coupon à 100 % si vous ne voulez pas débiter une carte.

Un geste, plusieurs envois

Modifier une adresse déclenche aussi un envoi par expédition récente et par commande en cours de création : c’est normal. Voir Événements : clients, adresses et inscriptions.

Lire ce que vous recevez

Voici le contenu réel de deux premiers envois, sur un compte de test.

created_optin.json

{
    "email": "claire.martin@example.com",
    "tenant_id": 1,
    "valid": true,
    "list_id": "9f2c4e7a1b",
    "changed": []
}

created_user.json

{
    "id": 1,
    "email": "claire.martin@example.com",
    "uuid": "cus_Qx7hR3eaEowcv1DX",
    "refp": "https://boutique.example.com/formules?refp=CLAIRE2026",
    "has_active_subscription": false,
    "info": null,
    "changed": []
}

• Les champs sont à la racine : il n’y a pas d’enveloppe.
• changed est vide sur une création.
• Le nom de l’événement n’est pas dans le contenu : c’est l’URL de réception qui l’identifie.
• Le reste du contrat (types de champs, cas des modifications, formats de dates et de montants) est décrit dans Comprendre un envoi de webhook.

Si vous ne recevez rien

Vérifiez dans l’ordre :

1. votre URL répond bien à une requête POST envoyée depuis l’extérieur ;
2. elle ne redirige pas ;
3. elle n’exige ni mot de passe ni filtrage par adresse IP ;
4. son certificat est valide et émis par une autorité reconnue : un certificat auto-signé fait échouer l’envoi sans laisser de trace ;
5. moins de 60 secondes se sont écoulées depuis l’activation : la configuration est mise en cache une minute.

Si tout cela est en ordre et que rien n’arrive toujours, passez à Bonnes pratiques et dépannage.