Bloquer les emails jetables dans OpenClaw

OpenClaw facilite la création de workflows automatisés qui traitent des données utilisateurs. Si une étape de votre workflow collecte ou utilise une adresse email - un formulaire de contact, un déclencheur d'inscription, un webhook provenant d'un autre outil - cette adresse peut être jetable. Ce guide montre comment ajouter une vérification d'email jetable directement dans un workflow OpenClaw grâce à l'API Veille.

Pourquoi c'est important dans les workflows automatisés

Lorsqu'un workflow traite une adresse email jetable, plusieurs problèmes peuvent survenir en aval :

Les séquences d'outreach envoient des emails à des boîtes qui n'existent plus, ce qui augmente les taux de rebond.
Les enregistrements CRM se remplissent de contacts qui ne convertiront jamais.
La création de comptes d'essai et les crédits de parrainage sont déclenchés pour de faux comptes.
Les rapports deviennent inexacts car les fausses inscriptions sont comptées comme de vraies pistes.

Détecter le problème au niveau du workflow - avant que ces étapes ne s'exécutent - est plus simple que de nettoyer les données après coup.

Pour en savoir plus sur l'utilisation des emails jetables dans la fraude aux comptes, consultez Comment les emails jetables sont utilisés dans la fraude aux comptes.

Comment fonctionne la vérification

L'API de validation d'emails Veille accepte une seule adresse email et renvoie une réponse structurée qui inclut :

disposable - true si le domaine est un fournisseur d'emails jetables connu
risk_score - un score de 0 (sûr) à 100 (risque élevé)
dns.mx - indique si le domaine dispose d'un serveur de messagerie configuré
smtp_valid - indique si la boîte de réception spécifique peut recevoir des emails

Une seule requête HTTP GET suffit. Aucun SDK, aucune bibliothèque. N'importe quel nœud HTTP d'OpenClaw peut effectuer cet appel.

Configurer le workflow dans OpenClaw

Étape 1 - Déclencheur

Commencez par n'importe quel déclencheur qui fournit une adresse email. Sources courantes :

Soumission de formulaire (webhook ou déclencheur de formulaire natif)
Événement CRM (nouveau contact ajouté)
Webhook depuis un outil tiers tel que Stripe, Typeform ou Notion

La sortie du déclencheur doit inclure un champ email que vous pouvez référencer dans les étapes suivantes.

Étape 2 - Nœud HTTP Request (appel à l'API Veille)

Ajoutez un nœud HTTP Request et configurez-le comme suit :

Champ	Valeur
Méthode	GET
URL	`https://api.veille.io/v1/intelligence/email`
Paramètre de requête - `query`	`{{trigger.email}}` (votre variable email)
En-tête - `x-api-key`	Votre clé API Veille

Le nœud renvoie une réponse JSON. Les champs les plus utiles sont disposable et risk_score.

Étape 3 - Nœud Condition

Ajoutez un nœud Condition après le HTTP Request. Configurez la logique suivante :

IF disposable == true  →  Branche : Bloquer
IF risk_score >= 75    →  Branche : Bloquer
ELSE                   →  Branche : Continuer

Vous pouvez utiliser une seule condition avec une logique OU, ou deux branches séparées selon la façon dont votre version d'OpenClaw gère les conditions.

Étape 4 - Branche de blocage

Dans la branche de blocage, choisissez ce qui arrive aux entrées rejetées :

Arrêter le workflow sans aucune action supplémentaire (option la plus simple)
Ajouter un tag ou une étiquette au contact dans votre CRM pour le marquer comme invalide
Déplacer l'enregistrement dans une liste ou une feuille de calcul séparée pour une révision manuelle
Envoyer une notification interne pour que votre équipe soit informée de l'activité

Étape 5 - Branche de continuation

Dans la branche de continuation, le workflow se poursuit normalement : créer le compte, envoyer l'email de bienvenue, mettre à jour le CRM, notifier l'équipe, ou tout ce que votre flux normal prévoit.

Réponse graduée basée sur le risk_score

Le champ disposable détecte les fournisseurs d'emails jetables connus. Le risk_score ajoute une couverture pour les domaines qui ne figurent sur aucune liste de blocage mais présentent des signaux suspects - domaines récemment enregistrés, serveurs de messagerie manquants, patterns inhabituels.

Une approche graduée basée sur le risk_score :

risk_score	Action
0–49	Continuer normalement
50–74	Continuer, ajouter un indicateur de révision
75–100	Bloquer

Cette approche évite de bloquer systématiquement les cas limites tout en supprimant les risques les plus évidents.

Gérer les adresses de relais de confidentialité

Des services comme Apple Hide My Email, Firefox Relay, SimpleLogin et addy.io génèrent des adresses de transfert qui peuvent paraître inhabituelles. Ces adresses appartiennent à de vrais utilisateurs qui ont choisi de protéger leur vie privée.

Pour éviter de les bloquer par erreur, ajoutez un nœud Condition avant l'appel à l'API Veille qui vérifie si le domaine correspond à un relais de confidentialité connu :

IF email domain is one of:
  privaterelay.appleid.com
  relay.firefox.com
  simplelogin.co
  addy.io
  anonaddy.com
→ Skip the Veille check and go directly to Continue

L'API Veille attribue également de faibles valeurs de risk_score aux adresses des fournisseurs de relais de confidentialité connus. Ainsi, même sans liste d'autorisation manuelle, elles ont peu de chances d'être bloquées par le seuil de score.

Structure complète du workflow

[Trigger: form / webhook / CRM event]
        ↓
[Condition: is domain a privacy relay?]
   YES ↓            NO ↓
[Continue]   [HTTP Request: Veille API]
                     ↓
            [Condition: disposable OR risk_score ≥ 75?]
               YES ↓            NO ↓
            [Block branch]   [Continue branch]

Exemple de réponse API

Lorsque vous appelez l'API Veille pour une adresse jetable, vous recevez une réponse similaire à celle-ci :

{
  "email": "user@mailinator.com",
  "disposable": true,
  "risk_score": 95,
  "role_account": false,
  "dns": {
    "mx": true
  },
  "smtp_valid": false
}

Pour une adresse légitime :

{
  "email": "contact@example.com",
  "disposable": false,
  "risk_score": 12,
  "role_account": false,
  "dns": {
    "mx": true
  },
  "smtp_valid": true
}

Cas d'usage courants dans OpenClaw

Workflow d'enrichissement de leads - un contact est ajouté à votre CRM depuis un formulaire. Avant que le contact entre dans votre séquence d'outreach, vérifiez l'email avec Veille. Seuls les contacts avec disposable: false et risk_score < 75 entrent dans la séquence.

Automatisation des inscriptions à l'essai - un nouvel utilisateur s'inscrit pour un essai gratuit. Le webhook d'inscription déclenche un workflow OpenClaw qui appelle Veille. Si l'email est jetable, l'étape de création du compte est ignorée et l'enregistrement est marqué.

Traitement du programme de parrainage - une demande de parrainage est reçue. Avant que le crédit de parrainage soit appliqué, Veille vérifie l'email. Les emails à risque élevé déclenchent une révision manuelle plutôt qu'un crédit automatique.

Validation de liste d'attente - un workflow par lots s'exécute sur votre liste d'attente avant votre lancement. Chaque email est vérifié via l'API Veille. Les entrées jetables sont déplacées dans une feuille séparée avant l'envoi des invitations.