Vérifier les e-mails des formulaires HubSpot en temps réel

Un formulaire HubSpot est une machine à capturer des contacts : chaque soumission crée ou met à jour une fiche de contact, renseigne des propriétés, et peut inscrire ce contact dans un workflow. Ce qu'il ne fait pas, c'est vous dire si l'adresse saisie par quelqu'un est réellement réelle. Le champ e-mail de HubSpot effectue un contrôle de format — il confirme la présence d'un @ et d'un domaine — mais il ne peut pas voir que la boîte est morte, jetable, ou une coquille de gmail.com. Ce guide présente deux méthodes concrètes pour vérifier les e-mails des formulaires HubSpot avec Qualisend : en temps réel, avec un workflow Operations Hub qui envoie en POST chaque nouvelle adresse à l'API Qualisend, et en masse, en exportant les contacts vers un CSV. Aucune ne nécessite de connecteur natif — il n'y en a pas encore — juste les actions de workflow intégrées de HubSpot ou son bouton d'export.

La réponse courte#

Choisissez la voie qui correspond au moment où vous avez besoin de la réponse :

• Temps réel — inscrivez les nouveaux soumissionnaires du formulaire dans un workflow. Une action de code personnalisé ou de webhook appelle l'API Qualisend avec l'e-mail, et un embranchement écrit le verdict dans une propriété de contact, puis dirige ou supprime l'enregistrement selon le status renvoyé.
• En masse — exportez vos contacts vers un CSV, passez-les dans la vérification en masse de Qualisend, et supprimez les adresses non délivrables avant votre prochain envoi.

Pourquoi le champ de formulaire de HubSpot ne peut pas confirmer une boîte mail#

Le champ email de HubSpot valide le format — il vérifie que la chaîne ressemble à une adresse avant de laisser le formulaire se soumettre. C'est le même type de contrôle qu'effectue une regex, et il échoue pour les mêmes raisons : le format n'est pas la délivrabilité. jane@gmial.com passe le contrôle de format. throwaway@mailinator.com aussi, et une adresse à l'air bien réelle sur un domaine fermé l'an dernier également.

Rien de tout cela n'est détecté avant l'envoi — et à ce stade, une adresse morte est un rebond dur qui grignote votre taux de rebond et votre réputation d'expéditeur. La vraie vérification ajoute les couches que HubSpot ne peut pas fournir : une recherche DNS/MX et une sonde SMTP de la boîte mail, plus des signalements pour les adresses jetables, génériques (role) et catch-all. Si ce pipeline est nouveau pour vous, ce que vérifie réellement la vérification d'e-mails est l'introduction idéale.

Deux façons de vérifier les e-mails des formulaires HubSpot#

La contrainte importante d'abord : un formulaire HubSpot standard ne peut pas bloquer un mauvais e-mail en cours de soumission. Il n'existe aucun moyen pris en charge d'appeler une API externe entre le clic sur « Soumettre » et la création de l'enregistrement ; la vérification en temps réel a donc lieu juste après la soumission, à l'intérieur d'un workflow — et non comme un verrou en ligne. Cela façonne les deux voies ci-dessous.

Voie 1 : le temps réel avec un workflow Operations Hub#

Créez un workflow basé sur les contacts et réglez le déclencheur d'inscription sur « Soumission de formulaire », restreint au formulaire qui vous intéresse. Chaque nouveau soumissionnaire circule désormais dans le workflow, où vous effectuez l'appel de vérification et agissez sur le résultat.

Il y a deux façons de réaliser cet appel — choisissez celle qui convient à votre portail et à votre stack.

Option A — une action de code personnalisé (autonome). Si vous êtes sur Operations Hub Professional ou Enterprise, une action de code personnalisé exécute du Node.js (ou du Python) directement à l'intérieur du workflow. Ajoutez la propriété email du contact inscrit comme propriété d'entrée, stockez votre clé comme un secret nommé QUALISEND_API_KEY, et appelez Qualisend depuis l'action :

// HubSpot custom-code action (Node.js) — input property: email, secret: QUALISEND_API_KEY
const QUALISEND_ENDPOINT = "https://api.qualisend.com/v1/verify"; // confirm the path in /developers

exports.main = async (event, callback) => {
  const email = event.inputFields.email;

  const res = await fetch(QUALISEND_ENDPOINT, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.QUALISEND_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ email }),
  });

  // Fail open — never block a real lead on a transient API error.
  if (!res.ok) return callback({ outputFields: { email_status: "unknown" } });

  const { result } = await res.json();
  callback({
    outputFields: {
      email_status: result.status, // deliverable / risky / undeliverable / unknown
      email_score: result.score,
    },
  });
};

L'action expose email_status et email_score en sorties. Faites-la suivre d'une étape Copier la valeur de propriété qui écrit email_status dans une propriété de contact personnalisée, puis utilisez un embranchement si/alors pour router en fonction de celle-ci — la raison même pour laquelle vous avez lancé le contrôle.

Option B — une action de webhook vers votre propre fonction. Vous préférez garder la logique dans votre propre base de code, ou vous n'êtes pas sur un palier avec code personnalisé ? Ajoutez une action de webhook qui envoie en POST vers une petite fonction serverless que vous contrôlez. La fonction récupère l'e-mail, appelle Qualisend, et réécrit le verdict sur le contact via l'API CRM de HubSpot. C'est la même forme côté serveur que le modèle de vérification à l'inscription : la clé d'API ne quitte jamais le serveur, et vous agissez sur le résultat. Le code d'endpoint du tutoriel Node.js ou du tutoriel Python s'insère presque tel quel — seul le parsing de la charge utile est spécifique à HubSpot.

Dans les deux cas, la requête sous-jacente est la même, et les valeurs à remplacer sont à compléter à partir de la documentation développeur :

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

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

Une adresse délivrable revient ainsi — un status, un score de 0 à 100, une reason, et un ensemble de sub_flags :

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

Deux règles rendent cela robuste. Utilisez une clé à portée restreinte générée pour ce workflow plutôt qu'une clé à accès complet, ainsi si elle fuite un jour d'un journal, elle ne peut que vérifier — rien d'autre. Et échouez en mode ouvert (fail open) : si Qualisend expire ou que la limite de l'offre est atteinte, traitez l'adresse comme unknown et conservez le contact plutôt que de laisser tomber un vrai prospect à cause d'un incident passager — ce que fait précisément l'embranchement !res.ok ci-dessus.

En aval, le verdict n'est qu'un embranchement. Renseignez une propriété personnalisée « Statut de l'e-mail » à partir de la sortie, puis laissez votre workflow décider : un contact deliverable poursuit dans la séquence de nurturing ; un contact undeliverable ou disposable voit son suivi retenu, est signalé pour revue, ou est passé en non-marketing afin d'être exclu des listes et envois actifs. Le workflow, c'est la plomberie ; le routage vous appartient.

Voie 2 : vérifier en masse un export CSV#

Si vous avez déjà des milliers de contacts, ou si vous préférez nettoyer selon un calendrier plutôt que d'effectuer des contrôles par soumission, procédez par lots — et cette voie ne nécessite aucun workflow, elle fonctionne donc aussi en dessous des paliers Operations Hub. Dans HubSpot, ouvrez Contacts, choisissez une liste ou un filtre, et Exportez vers un CSV. Vous obtiendrez une ligne par contact avec l'e-mail dans sa propre colonne.

Ensuite :

1. Envoyez le CSV vers la vérification en masse de Qualisend et laissez-la exécuter le pipeline complet — MX, SMTP, et les signalements jetable/générique/catch-all — sur chaque ligne.
2. Téléchargez le fichier annoté. Chaque adresse revient avec un status, une reason, et un score de 0 à 100.
3. Supprimez les adresses non délivrables de retour dans HubSpot : importez les résultats pour renseigner votre propriété « Statut de l'e-mail », puis excluez tout ce qui n'est pas délivrable de vos listes actives et de vos envois marketing.

Le traitement en masse est le bon outil pour un arriéré, mais c'est du nettoyage, pas de la prévention : une adresse que vous attrapez ici est généralement déjà présente dans votre base depuis un moment. Associez un passage en masse périodique au workflow en temps réel pour que les nouvelles mauvaises adresses soient signalées dès leur arrivée.

Agir sur le verdict#

Quelle que soit la voie qui renvoie le résultat, la forme est la même — un status, une reason, un score, et les sous-signalements. Associez chacun à une action :

Si vous pesez l'approche par workflow de HubSpot face à un appel direct à l'API depuis votre propre backend, le même compromis s'applique que pour n'importe quelle couche de liaison : les workflows l'emportent sur la rapidité de mise en place, une intégration directe l'emporte sur le coût et le contrôle à l'échelle. Le même modèle de webhook alimente aussi les guides frères pour Zapier et Typeform si une partie de votre entrée vit en dehors de HubSpot.

Foire aux questions#

Existe-t-il une intégration native Qualisend pour HubSpot ?#

Pas pour le moment. Les intégrations natives de Qualisend avec les plateformes sont en cours de refonte, il n'y a donc pas encore d'app de marque à installer dans le HubSpot Marketplace — c'est prévu dans la feuille de route. En attendant sa sortie, la méthode prise en charge pour vérifier les e-mails des formulaires HubSpot est une action de code personnalisé ou de webhook dans un workflow, pointée vers l'API Qualisend, exactement comme le décrit ce guide. Cette approche est aussi plus souple : vous contrôlez la requête, les embranchements, et la propriété de contact dans laquelle le verdict est enregistré.

Ai-je besoin d'Operations Hub pour vérifier les e-mails des formulaires HubSpot ?#

Pour le workflow en temps réel, en pratique oui. Les workflows requièrent un palier Professional, et les actions de webhook et de code personnalisé exigent spécifiquement Operations Hub Professional ou Enterprise. Si votre portail est sur un palier inférieur, utilisez plutôt la voie de l'export CSV et de la vérification en masse — elle ne nécessite ni workflow ni code personnalisé, juste un export et un envoi de fichier, si bien qu'elle fonctionne sur toute offre permettant d'exporter des contacts.

Puis-je bloquer un mauvais e-mail avant que le formulaire soit soumis ?#

Pas de façon fiable. Un formulaire HubSpot standard n'offre aucun moyen pris en charge d'appeler une API externe en cours de soumission pour empêcher la création de l'enregistrement ; la vérification en temps réel s'exécute donc juste après la soumission, à l'intérieur du workflow. En pratique, cela convient : vous vérifiez en quelques secondes et agissez avant que l'adresse ne reçoive le moindre message — vous retenez l'e-mail de bienvenue, taguez le contact, ou le dirigez vers une revue plutôt que de bloquer le formulaire lui-même.

En quoi est-ce différent du nettoyage de ma liste HubSpot existante ?#

Vérifier à l'entrée empêche de nouvelles mauvaises adresses d'entrer ; nettoyer votre liste existante retire celles qui s'y trouvent déjà. Ce guide porte sur la première approche — attraper chaque soumission dès son arrivée. Pour la seconde, vous effectuez un passage ponctuel (ou planifié) sur l'ensemble de votre base, en décidant quoi supprimer et comment réengager les contacts inactifs. La routine complète, y compris la place de chaque statut, se trouve dans comment nettoyer une liste d'e-mails. La plupart des équipes font les deux.

Prêt à tout câbler ? Récupérez une clé à portée restreinte et le format exact de la requête dans la documentation développeur, testez une seule adresse dans le vérificateur d'e-mails gratuit, ou commencez avec les 100 crédits gratuits de chaque offre pour tester le workflow de bout en bout avant de l'activer.