Comment vérifier des e-mails avec Zapier

Vous pouvez vérifier des e-mails avec Zapier dès aujourd'hui, même s'il n'existe pas encore d'application Zapier native pour Qualisend. L'astuce consiste à cesser de chercher un connecteur de marque et à utiliser plutôt l'action générique Webhooks by Zapier : votre formulaire ou votre CRM déclenche un trigger, Zapier envoie la nouvelle adresse en POST à l'API Qualisend, et une étape Filter ou Paths aiguille selon le verdict — de sorte que seules les adresses deliverable continuent vers votre outil d'e-mailing, tandis que les adresses douteuses sont mises de côté pour examen. Ce guide construit ce Zap de bout en bout.

La réponse courte#

Il n'existe pas d'application native à installer pour l'instant (elle figure à la feuille de route), donc le schéma pris en charge est un Zap en trois étapes : un trigger (nouvel envoi de formulaire, nouveau lead, nouvelle ligne), une action Webhooks by Zapier → Custom Request (POST) qui appelle l'API de vérification avec l'e-mail, et une étape Filter ou Paths qui lit le status renvoyé et décide de la suite. Gardez votre clé d'API dans les en-têtes du webhook — jamais dans un formulaire public — et laissez passer une adresse par défaut si le webhook échoue, afin qu'un incident passager ne fasse jamais perdre un vrai lead.

Deux façons de vérifier des e-mails avec Zapier#

Avant de tout brancher, choisissez le schéma qui correspond au degré de fraîcheur dont vos données ont besoin :

1. En temps réel, par envoi (un Zap). Chaque nouvelle adresse est vérifiée dès son arrivée et aiguillée sur-le-champ. C'est le sujet principal de ce guide et le bon choix lorsque le verdict change la suite des événements — conditionner un e-mail de double opt-in, taguer un lead ou écarter une fausse inscription.
2. Par lots, a posteriori (un CSV). Laissez les envois s'accumuler dans une feuille de calcul ou votre ESP, exportez-les périodiquement, et passez-les dans un traitement de vérification en masse. Plus simple, moins cher par adresse, et mieux adapté lorsque vous avez seulement besoin d'une liste propre avant un envoi plutôt que d'une décision instantanée.

La plupart des équipes finissent par faire les deux : un Zap sur la collecte en direct, plus un nettoyage de liste mensuel pour attraper les adresses devenues obsolètes depuis l'inscription.

Étape 1 : le trigger#

Démarrez le Zap avec ce qui capture l'adresse. Zapier propose des triggers natifs pour la plupart des outils de formulaire et de CRM — « New Submission » dans une application de formulaire, « New Lead » dans un CRM, « New Spreadsheet Row » dans Google Sheets. Quel que soit votre choix, la sortie importante est un champ contenant l'adresse e-mail, que les étapes suivantes référencent sous forme de jeton de fusion comme {{1.email}}.

Exactement la même action webhook fonctionne quel que soit le déclencheur : le schéma de ce guide est donc identique, que vous branchiez Typeform, un CRM ou une feuille de calcul — voyez vérifier des e-mails depuis Typeform pour un pas-à-pas spécifique au trigger qui passe ensuite le relais aux étapes ci-dessous.

Étape 2 : envoyer l'adresse en POST avec Webhooks by Zapier#

Ajoutez une étape d'action et choisissez Webhooks by Zapier, puis l'événement Custom Request. C'est l'étape qui appelle réellement Qualisend. Configurez-la ainsi :

Dans le champ Data, Zapier vous laisse saisir du JSON brut et y insérer le jeton e-mail du trigger. Le corps que vous envoyez se résume à ceci :

{ "email": "{{1.email}}" }

Et la requête que Zapier envoie pour vous ressemble à ceci — les valeurs à trous sont à compléter à partir de la documentation développeur, qui liste l'endpoint exact et montre la requête dans plusieurs langages :

POST https://api.qualisend.com/v1/verify
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{ "email": "jane@example.com" }

Utilisez une clé à portée limitée générée pour ce Zap plutôt qu'une clé à accès complet : ainsi, si l'historique du Zap venait à fuiter, la clé ne pourrait que vérifier, rien d'autre. Ne placez jamais la clé dans le formulaire lui-même ni dans un quelconque champ côté client — elle a sa place uniquement dans les en-têtes du webhook, qui s'exécutent côté serveur au sein de Zapier.

Quand vous cliquez sur Test action, Zapier affiche le corps de la réponse. Vous récupérez un status, un code reason, un score de 0 à 100 et un ensemble de sub_flags. Une adresse deliverable revient à peu près sous cette forme :

{
  "status": "deliverable",
  "reason": null,
  "score": 95,
  "sub_flags": { "disposable": false, "role": false, "free": false, "catch_all": false }
}

Ce sont ces noms de champs sur lesquels l'étape suivante s'appuie pour aiguiller : notez donc la façon dont Zapier les étiquette — il les aplatit généralement en jetons comme status et sub_flags catch_all. Pour une vue d'ensemble de la signification de chaque statut et de la manière dont le pipeline y parvient, voyez comment fonctionne la vérification d'e-mails.

Étape 3 : aiguiller selon le verdict#

Un résultat de vérification sur lequel vous n'agissez pas est un crédit gaspillé. Tout l'intérêt est d'aiguiller les adresses différemment, et Zapier vous offre deux outils pour cela.

Option A — un Filter (le plus simple). Si tout ce que vous voulez, c'est « ne garder que les bonnes adresses », ajoutez une étape Filter by Zapier après le webhook. Réglez la condition sur :

• Status (texte) exactly matches deliverable

Tout ce qui n'est pas deliverable arrête le Zap sur-le-champ, de sorte que seules les adresses confirmées atteignent votre action en aval (ajout à votre ESP, création du contact, envoi de l'e-mail de bienvenue). Simple, mais brutal — cela traite risky, unknown et undeliverable de la même manière, alors que vous voulez souvent les gérer différemment.

Option B — Paths (aiguiller chaque issue). Paths by Zapier — disponible sur les forfaits Zapier payants — vous permet de vous ramifier en branches distinctes, chacune avec sa propre condition et ses propres actions de suivi :

Vous pouvez aussi aiguiller selon les sous-indicateurs. Si votre produit est sensible à sa réputation, ajoutez une condition qui oriente toute adresse dont sub_flags disposable vaut true vers la branche d'examen, même lorsque le statut est par ailleurs bon — la même prudence, sur les adresses jetables, génériques et gratuites, que celle détaillée dans le panorama des adresses génériques, jetables et gratuites. Les Paths s'évaluent de haut en bas : placez donc votre branche la plus stricte en premier.

Ne laissez pas le webhook bloquer un bon lead#

Une règle prime sur toutes les branches : échouer en laissant passer (fail open). Si l'étape webhook échoue — l'API est brièvement lente, une limite de forfait est atteinte, une coupure réseau survient — vous ne voulez pas que le Zap entier meure et avale silencieusement une vraie inscription. Dans Zapier, ouvrez les paramètres de l'action webhook et activez « Continue on error » (parfois présentée comme une option de rejeu automatique / gestion d'erreurs selon votre forfait). Ajoutez ensuite une valeur de repli pour qu'une adresse sans verdict soit traitée comme unknown et conservée pour un examen ultérieur plutôt que supprimée.

Une API de vérification est un filtre de qualité, pas une barrière d'authentification. Bloquer un client payant à cause d'une panne passagère est une issue bien pire que de laisser passer une adresse douteuse et de l'attraper lors de votre prochain nettoyage de liste. Ce même principe du fail-open sous-tend le schéma d'inscription serverless, où un sondage lent ne doit jamais bloquer le formulaire.

Quand un Zap n'est pas le bon outil#

Zapier est de la colle, et la colle a un coût : chaque adresse vérifiée est une tâche, et un webhook par envoi peut devenir coûteux à fort volume ou paraître disproportionné quand vous n'avez pas besoin d'une décision instantanée. Préférez la voie par lots lorsque :

• Vous nettoyez une liste qui existe déjà — des milliers de contacts historiques, pas une collecte nouvelle. Exportez-les et lancez un seul traitement en masse.
• Votre volume est assez élevé pour que la tarification à la tâche fasse mal, et un nettoyage nocturne ou hebdomadaire est suffisamment frais.
• Vous êtes sur le forfait gratuit de Zapier et ne pouvez pas utiliser l'application Webhooks premium.

Dans ces trois cas, laissez tomber le Zap : exportez les envois au format CSV depuis votre outil de formulaire, votre feuille de calcul ou votre ESP, et déposez ce fichier dans le vérificateur en masse de Qualisend. Vous obtenez les mêmes status, score et sous-indicateurs par ligne, téléchargeables sous forme de fichier nettoyé que vous pouvez réimporter. C'est la façon la moins laborieuse de garder une liste en bonne santé et votre taux de rebond au plus bas, sans maintenir la moindre automatisation.

Si vous hésitez entre l'approche par webhook de Zapier et l'appel direct de l'API depuis votre propre backend, la comparaison des API expose les compromis — Zapier l'emporte sur la rapidité de mise en place, une intégration directe l'emporte sur le coût et le contrôle à grande échelle.

Foire aux questions#

Existe-t-il une application Qualisend native pour Zapier ?#

Pas pour le moment. Les intégrations natives de la plateforme Qualisend sont en cours de refonte, il n'existe donc pas encore d'application de marque à rechercher dans l'annuaire Zapier — elle figure toutefois à la feuille de route. En attendant sa sortie, la méthode prise en charge pour vérifier des e-mails avec Zapier consiste à utiliser l'action générique Webhooks by Zapier pointée vers l'API Qualisend, exactement comme le décrit ce guide. L'approche par webhook est par ailleurs plus souple : vous maîtrisez la requête, les en-têtes et la logique d'aiguillage.

Ai-je besoin d'un forfait Zapier payant ?#

Pour le Zap en temps réel, oui, en pratique. Webhooks by Zapier est une application intégrée premium, et les Zaps multi-étapes ainsi que les Paths exigent un forfait Zapier payant : le flux d'aiguillage selon le verdict nécessite donc un forfait payant. Si vous êtes sur le forfait gratuit, optez plutôt pour l'export CSV et la vérification en masse — cela ne demande aucun Zap ni aucune application premium, juste l'envoi d'un fichier.

Quel statut dois-je laisser passer vers mon outil d'e-mailing ?#

Uniquement deliverable pour un filtrage strict. Si vous souhaitez conserver davantage d'adresses, autorisez deliverable ainsi que risky/unknown, mais orientez ces dernières vers un segment distinct et moins prioritaire plutôt que vers votre flux principal — de nombreux résultats risky sont des domaines catch-all qui peuvent malgré tout délivrer. Rejetez toujours undeliverable, et envisagez d'aiguiller aussi selon le sous-indicateur disposable si votre produit est sensible à sa réputation.

Comment tester le Zap avant de l'activer ?#

Utilisez l'action Test intégrée de Zapier sur l'étape webhook avec une adresse connue comme valide et une autre connue comme invalide, et vérifiez que le champ status change comme prévu — assurez-vous ensuite que vos conditions de Filter ou de Paths orientent chacune vers la bonne branche. Pour des vérifications ponctuelles rapides en dehors de Zapier, collez une adresse dans le vérificateur d'e-mails gratuit et comparez le verdict à celui que renvoie votre Zap.

Prêt à le construire ? Récupérez une clé à portée limitée et la forme exacte de la requête dans la documentation développeur, vérifiez n'importe quelle adresse dans le vérificateur d'e-mails gratuit, et démarrez sur le forfait gratuit — 100 crédits suffisent à câbler tout le Zap et à voir une mauvaise adresse se faire filtrer avant même d'atteindre votre liste.