DÉMONSTRATION PERSONNELLE · API SIMULÉE
Une entrée invalide ne devient pas un faux succès.
J’ai exécuté ce workflow dans une instance n8n locale le 11 septembre 2026. Une entrée valide crée un contact fictif ; trois entrées invalides sont refusées sans appel API ; une panne simulée rend HTTP 503.
Webhook → validation → API → réponse
Exécution réelle, données fictives. Aucun outil client connecté.
| Cas | HTTP | Appels API | Attendu |
|---|---|---|---|
| Données valides, nom normalisé | 201 | 1 | Conforme |
| Nom vide refusé | 400 | 0 | Conforme |
| Statut inconnu refusé | 400 | 0 | Conforme |
| Nom absent refusé | 400 | 0 | Conforme |
| Panne API signalée | 503 | 1 | Conforme |
Deux appels API au total. Un seul contact fictif créé.
Inspecter et reproduire
Réponses HTTP enregistrées (JSON) · Workflow n8n inactif (JSON) · Serveur API simulée et cinq tests
Sur une instance n8n 2.38.7 d’essai, importer le workflow puis l’activer sur le port local 18765. Le script de test Node démarre l’API sur 127.0.0.1:18766 et appelle le webhook local. Exécuter node test.mjs avec Node 24. Arrêter l’instance après essai. Les deux ports doivent être libres.
Limites de cette preuve
Pas de connexion CRM réelle, d’authentification client, d’idempotence ni de disponibilité de production démontrée. Ne pas exposer ce webhook sans authentification. Les cinq exécutions n8n ont terminé leur branche de réponse ; cela ne signifie pas cinq créations réussies.
Résultats conservés du 11/09/2026, non réexécutés lors de leur mise en ligne le 19/09. n8n et ses dépendances conservent leurs licences respectives.