Tester les webhooks

1. Envoyer un événement de test

Depuis le tableau de bord (Paramètres → Développeurs → Webhooks → Envoyer un événement de test) ou via l'API :

curl -X POST https://api.nembol.com/rest/v1/webhook_endpoints/{id}/test \
  -H "Authorization: Bearer $NEMBOL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "type": "order.created" }'

La réponse vous indique immédiatement si votre endpoint a répondu, et avec quel statut :

{ "delivered": true, "response_status": 200 }

Les événements de test sont de vraies livraisons, avec la même enveloppe et la même signature (votre code de vérification est donc lui aussi testé). data.object est un échantillon de la forme réelle pour le type demandé (une commande, une annonce, un produit…), construit à partir de données fictives (TEST-SKU-1, commande TEST-1001, des identifiants qui n'existent nulle part), et data.test vaut true. Votre gestionnaire s'exécute de bout en bout exactement comme pour un vrai événement : vérifiez data.test avant d'écrire quoi que ce soit dans votre propre système. Un type inconnu répond 422.

2. Développement local

Votre machine de développement n'est pas accessible depuis Internet. Plusieurs options :

• Pointez un endpoint de webhook vers un service de capture (par ex. webhook.site) pour inspecter les contenus et les en-têtes. C'est parfait pour regarder, mais cela ne peut pas vérifier les signatures à votre place.
• Créez un tunnel vers localhost avec ngrok http 3000 (ou cloudflared) et enregistrez l'URL du tunnel comme endpoint en mode test. C'est la boucle complète de bout en bout : vérification de la signature, votre gestionnaire, votre 2xx.

3. Clés en mode test et webhooks

Les endpoints de webhook créés avec une clé nbl_test_ ne reçoivent que des événements synthétiques (envois de test et opérations simulées), jamais le trafic de production. Les endpoints live ne reçoivent que des événements réels. Gardez les deux séparés dans votre configuration.

4. Checklist avant la mise en production

• La vérification de signature est activée (et elle échoue si vous modifiez un octet).
• Le gestionnaire répond 2xx en < 10 s ; le travail lourd se fait en asynchrone.
• Un event.id en double est sans effet (les livraisons sont « au moins une fois »).
• Les valeurs de type inconnues reçoivent un accusé de réception, pas une erreur.
• Une tâche de réconciliation parcourt GET /events pour tout ce qui a été manqué.

Dernière mise à jour le 20 octobre 2026