Watch-IP

Repérez les e-mails d'inscription jetables, mal saisis ou sans serveur de messagerie

Offrez à votre formulaire d'inscription une vérification précoce de chaque adresse : syntaxe, domaines jetables/temporaires connus, présence d'un serveur de messagerie pour le domaine, fautes de frappe probables et adresses génériques — sous la forme d'un verdict accept, review ou reject accompagné de ses motifs. Appelez POST /v1/email/validate depuis le JavaScript de votre formulaire, ou vérifiez des listes en masse depuis votre backend ou le tableau de bord.

Requête et authentification

Envoyez un corps JSON { "email": "user@example.com" } à POST /v1/email/validate avec une clé publiable restreinte par origine dans l'en-tête X-Api-Key — le même type de clé et le même modèle d'origines autorisées que GET /v1/geo, ce qui permet de l'appeler directement depuis un formulaire d'inscription pendant la saisie ou à la soumission. Côté serveur, votre clé secrète donne accès à POST /v1/email/batch (jusqu'à 100 adresses par requête), aux tâches de liste asynchrones jusqu'à 100 000 adresses (API ou page Email lists du tableau de bord, CSV en entrée et en sortie) et à POST /v1/signup/check, qui combine la vérification d'e-mail avec les indicateurs réseau de l'IP d'inscription en un seul score.

Lisez le verdict, puis les motifs

verdict est l'issue la plus sévère : reject pour une syntaxe invalide, un domaine inexistant, un domaine sans serveur de messagerie ou un domaine jetable ; review pour une faute de frappe présumée, une adresse générique comme info@, un domaine avec seulement un serveur de messagerie implicite, ou une recherche DNS non aboutie ; sinon accept. reasons énumère chaque condition rencontrée, pour que votre formulaire affiche un message précis — et lorsque didYouMean est renseigné, proposez la correction plutôt qu'une erreur.

Quand l'appeler

Appelez-la à la perte de focus ou à la soumission plutôt qu'à chaque frappe — vérifier une adresse encore incomplète à chaque caractère ajoute des requêtes sans signal utile et peut faire clignoter un message d'erreur pendant que le visiteur tape encore. Chaque appel compte comme une requête.

En cas d'échec de la requête

Échouez en mode ouvert : laissez l'inscription se poursuivre si la requête réseau échoue ou expire, plutôt que de bloquer chaque visiteur à cause d'une panne côté client. Côté serveur, une recherche DNS qui échoue est signalée par le motif dns_unavailable (verdict review), jamais par une erreur ou un reject. Conservez ce que le visiteur a déjà saisi afin qu'une vérification échouée ne lui fasse jamais perdre sa saisie.

Comment les domaines jetables sont détectés

Les domaines jetables/temporaires connus proviennent de la fusion de trois listes open source maintenues par la communauté (voir sources de données), actualisées toutes les quelques heures, avec une liste d'autorisation afin qu'une mauvaise entrée en amont ne puisse jamais signaler un grand fournisseur. Les sous-domaines d'un domaine listé correspondent aussi. Les nouveaux domaines jetables qu'aucune liste ne connaît encore sont souvent repérés grâce à leur serveur de messagerie : les services jetables font pointer de nombreux domaines vers les mêmes quelques hôtes, et un domaine dont le serveur de messagerie dessert des domaines listés est signalé avec disposableSource : mx_host. Un fournisseur très récent sur un nouveau serveur de messagerie peut encore passer inaperçu.

Usage et quota

Chaque adresse vérifiée compte comme une requête sur le plafond mensuel partagé de votre forfait — une vérification unitaire, chaque adresse d'un lot, chaque adresse distincte d'une tâche de liste — aux côtés de votre autre trafic, avec la même limite de débit par minute. Il n'y a ni forfait ni prix e-mail distinct. La limite de débit par minute compte les appels HTTP, pas les éléments : un lot de jusqu'à 100 IP ou adresses e-mail compte pour une seule requête, tandis que chaque élément compte toujours séparément dans le plafond mensuel de requêtes.

Ce que cela ne vérifie pas

Chaque vérification porte sur le domaine ou l'adresse. Watch-IP ne contacte jamais le serveur de messagerie du destinataire : un résultat n'établit donc pas que la boîte aux lettres existe, que le courrier y parviendra ni qu'elle appartient à la personne qui s'inscrit. Un verdict accept signifie « aucun problème détecté », pas une adresse dont le fonctionnement est confirmé — utilisez un e-mail de confirmation pour cela.

Champs de la réponse

syntaxValid
Indique si l'adresse est syntaxiquement valide.
isDisposable
Indique si le domaine correspond à un fournisseur jetable/temporaire connu, directement, via un domaine parent ou via son serveur de messagerie. Toujours false lorsque syntaxValid vaut false.
disposableSource
list, parent_domain ou mx_host — pourquoi isDisposable vaut true ; null sinon.
mx
Le statut du serveur de messagerie du domaine (found, implicit, none, null_mx, no_domain ou unknown) et son hôte MX principal.
didYouMean
Une correction probable de faute de frappe, comme gmial.com → gmail.com, ou null.
isRoleAccount / isFreeProvider
Indicateurs d'adresse générique (admin@, info@, noreply@…) et de fournisseur de messagerie grand public. Le fournisseur gratuit est purement informatif.
normalizedEmail / canonicalEmail
L'adresse en minuscules, et la même sans +tags (ni points Gmail) pour repérer les comptes en double.
verdict / reasons
accept, review ou reject, plus chaque code de motif rencontré — voir la référence pour la liste complète.

Agir selon le verdict

JavaScript du formulaire d'inscription

async function checkEmail(email) {
  const response = await fetch('https://api.watch-ip.com/v1/email/validate', {
    method: 'POST',
    headers: { 'X-Api-Key': 'YOUR_PUBLISHABLE_KEY', 'Content-Type': 'application/json' },
    body: JSON.stringify({ email }),
  });
  if (!response.ok) return { state: 'unknown' }; // fail open — ne bloquez pas l'inscription en cas d'erreur réseau

  const result = await response.json();
  if (result.didYouMean) return { state: 'suggest', suggestion: result.didYouMean };
  if (result.verdict === 'reject') return { state: 'reject', reasons: result.reasons };
  return { state: 'ok' }; // accept ou review : laissez passer l'inscription et signalez-la côté backend
}

Affichez un message distinct par motif — invalid_syntax, disposable_domain et no_mail_server appellent des corrections différentes de la part du visiteur — et proposez didYouMean comme correction en un clic.

Questions fréquentes

Vérifie-t-il que la boîte aux lettres existe ?

Non. Elle vérifie la syntaxe, les listes et les enregistrements DNS de serveur de messagerie du domaine, ainsi que la forme de l'adresse. Elle ne contacte jamais le serveur de messagerie et ne confirme pas que la boîte aux lettres individuelle existe — un reject pour no_mail_server concerne le domaine entier.

Un accept prouve-t-il que l'e-mail fonctionne ?

Non. accept signifie qu'aucune vérification n'a détecté de problème, pas que l'adresse recevra forcément du courrier ni qu'elle appartient à la personne qui s'inscrit. Utilisez un e-mail de confirmation si vous en avez besoin.

Les utilisateurs peuvent-ils contourner la validation navigateur ?

Oui. Toute vérification côté navigateur, y compris celle-ci, peut être contournée en désactivant JavaScript ou en appelant directement votre point de terminaison d'inscription. Appliquez toute décision importante sur votre backend — POST /v1/signup/check est conçu pour cela.

Puis-je nettoyer une liste existante ?

Oui. Envoyez un CSV depuis la page Email lists du tableau de bord, ou soumettez jusqu'à 100 000 adresses à POST /v1/email/jobs avec votre clé secrète, puis téléchargez un CSV de résultats avec un verdict et des motifs par ligne. Les doublons ne sont facturés qu'une fois, et les envois et résultats sont supprimés après 7 jours.

Comment les requêtes sont-elles comptabilisées ?

Une requête par adresse vérifiée, imputée au plafond mensuel partagé de votre forfait. Les doublons d'une tâche de liste comptent une seule fois ; une vérification d'inscription compte comme une requête.

Pages associées