Formulaire canary
Vérifier que l'endpoint de votre formulaire de contact accepte encore un envoi, sans polluer votre CRM.
Mis à jour le 11 septembre 2026
Sur cette page
/api/contact et /api/lead sont les premières victimes d'un refactor : un fichier de route déplacé, un export renommé, un middleware qui avale désormais les POST. La page qui porte le formulaire répond toujours 200, rien d'autre ne le remarque, et les prospects cessent simplement d'arriver. Le formulaire canary envoie des données visiblement fausses à l'endpoint et lit le code de réponse.
Ce que PostShip vérifie
À chaque passage, PostShip fait un POST sur l'URL de la cible avec :
- le corps
_postship=canary&email=canary@invalid, enapplication/x-www-form-urlencoded; - l'en-tête
X-PostShip-Canary: 1, pour que vous puissiez écarter ces envois de vos statistiques et de votre limitation de débit sans deviner d'après le User-Agent ; - le même délai de 12 secondes et les mêmes 5 redirections au plus que les autres vérifications. Le corps et la méthode sont renvoyés à chaque saut ; chaque saut est vérifié contre les adresses privées.
L'adresse canary@invalid est volontairement impossible à router : le domaine .invalid est réservé précisément pour que rien n'essaie jamais d'y livrer.
Ce que PostShip ne vérifie pas : qu'un prospect a été enregistré. Il faudrait une vraie adresse et une boîte à relever, et cela mettrait des données bidon dans votre CRM. Le canary lit le statut, rien d'autre.
Régler
Projet → URLs → « Ajouter une URL » → sorte « Formulaire (canary) ». L'URL est celle de l'endpoint (https://acme.fr/api/contact), pas de la page qui affiche le formulaire. Puis choisissez ce qu'une réponse saine ressemble :
| Choix | Sens |
|---|---|
| Le formulaire refuse les données bidon (par défaut) | L'endpoint valide ses entrées et répond 4xx à un email invalide. Un 2xx est aussi accepté : beaucoup de formulaires répondent 200 quoi qu'on leur envoie, et les faire échouer serait du bruit. |
| L'endpoint accepte l'envoi et répond OK | L'endpoint doit répondre 2xx. Tout autre statut est un échec. |
Le premier choix est le bon pour un formulaire de contact ordinaire. Le second sert quand l'endpoint est un relais qui doit toujours accepter (un webhook entrant, un formulaire sans validation).
Ce qui déclenche une alerte
| Code | Phrase | Quand |
|---|---|---|
form_5xx | L'envoi du formulaire renvoie une erreur serveur. | Statut 500 ou plus, quel que soit le réglage. |
form_gone | L'endpoint du formulaire a disparu ou n'accepte plus les envois (404 / 405). | 404 ou 405 — la forme exacte que prend un fichier de route déplacé. |
form_not_accepted | L'endpoint devait accepter l'envoi, il l'a refusé. | Réglage « accepte », statut hors 2xx. |
form_not_rejected | L'endpoint du formulaire ne renvoie pas de réponse exploitable. | Réglage « refuse », réponse 3xx sans destination suivable. |
Avec le réglage « refuse », un 2xx et un 4xx sont tous deux verts. L'alerte suit la confirmation du projet et part une fois par panne ; « Rétabli » suit le retour au vert. Un formulaire en échec coûte 10 points au Ship Score.
Limites et plans
Disponible sur tous les plans ; une cible canary compte pour une URL du quota (Free 3, Pro 15, Team 50). La fréquence est celle du cycle : 30 minutes sur Free, 5 minutes sur Pro et Team, plus chaque déploiement.
Dépannage
Pourquoi l'endpoint est en échec avec un 403 ?
Avec le réglage « accepte », tout ce qui n'est pas 2xx échoue — et un 403 vient souvent d'une protection anti-robot (Turnstile, reCAPTCHA) ou d'une vérification d'origine (Origin, jeton CSRF). Passez au réglage « refuse » : le 403 devient une réponse saine, et un 404, 405 ou 5xx reste un échec.
Pourquoi je reçois un email à chaque passage ?
Votre endpoint traite l'envoi avant de valider l'adresse. Rejetez canary@invalid (ou tout ce qui porte X-PostShip-Canary) avant la notification. C'est aussi un bon garde-fou contre les envois de robots.
Le canary peut-il tester un formulaire en GET ou en JSON ?
Non : c'est toujours un POST encodé en formulaire. Pour un endpoint JSON, surveillez-le comme contrat d'API si c'est un GET, ou en cible HTTP avec le statut attendu correspondant.