Email finder API : les quatre points que la doc passe sous silence

Tous les éditeurs documentent les mêmes endpoints ; les quatre réponses qui décident de votre facture, presque aucun ne les donne.

À retenir Une API email finder part d'une personne que vous avez déjà identifiée — un nom, une entreprise — et renvoie une adresse professionnelle vérifiée. Tous les éditeurs documentent à peu près les mêmes endpoints. Presque aucun ne répond aux quatre questions qui décident de votre facture et de votre architecture : la facturation (à la demande ou au résultat vérifié), la durée d'une recherche et le caractère bloquant ou non de l'appel, ce que le payload de réponse garantit vraiment, et le traitement des domaines catch-all (tranchés, ou renvoyés dans votre camp). Une cinquième ne pèse qu'en volume : ce que devient un traitement de 50 000 lignes face aux limites de débit. Les réponses d'Enrow, à titre de repère : facturation au résultat valide uniquement, API entièrement asynchrone par conception, catch-all vérifiés au lieu d'être simplement étiquetés, 10 requêtes par seconde sur les POST, lots de 5 000 lignes. Lisez la ligne « facturation » avant la liste des fonctionnalités. Elle pèse plus lourd sur le coût réel que le prix affiché.

Une API email finder, c'est un endpoint HTTP qui transforme une personne en adresse email professionnelle. Vous envoyez un nom et une entreprise. Vous récupérez une adresse, accompagnée d'une indication, sous une forme ou une autre, sur son existence réelle.

Première mise au point, parce que la requête « email API » ramène surtout autre chose : des plateformes d'envoi et des relais transactionnels. Ceux-là servent à envoyer des emails. Une API de recherche, elle, transforme une identité en adresse avant même qu'un message existe.

Les quatre critères qui suivent viennent de la construction de la nôtre, et d'une douzaine de docs concurrentes lues pendant ce chantier. Les listes d'endpoints sont interchangeables. Le modèle de facturation, le contrat de latence, la forme de la réponse et le traitement des catch-all ne le sont pas, et tous quatre sont en général enfouis quelque part dans la doc. Le plafond des lots compte aussi, mais seulement quand votre volume devient sérieux : il a droit à sa propre section, après les quatre critères.

1. Facturation à la tentative, ou au résultat vérifié

Payez les échecs, et chaque contact trouvé vous revient à plus de trois fois le prix de la recherche.

C'est tout l'enjeu, et c'est la ligne que la plupart des pages de tarifs omettent.

Deux modèles existent. En facturation à la tentative, vous payez au moment de la demande : même si l'éditeur ne renvoie rien d'exploitable, il a mobilisé des ressources et vous débite un crédit. En facturation au résultat valide, un échec ne coûte rien, et le compteur ne bouge que lorsqu'une adresse valide est trouvée.

L'écart est loin d'être négligeable. La plupart des éditeurs ne publient aucun taux de couverture, donc je retiens 30 % comme hypothèse de travail sur une liste B2B froide. À 30 %, un éditeur qui facture à la tentative vous fait payer chaque contact réellement obtenu plus de trois fois son prix. Ensuite, une partie des adresses trouvées génère des bounces, et celles-là aussi, vous les avez payées.

Quelques éditeurs écrivent noir sur blanc qu'ils facturent au résultat, et c'est appréciable. Anymail Finder ne débite un crédit qu'une fois l'adresse vérifiée. Même chose chez Findymail : un crédit par adresse trouvée. ZeroBounce facture une recherche aboutie et ne facture rien quand le résultat est inconnu.

Les endpoints de recherche d'Enrow fonctionnent de la même façon, et la réponse en lot rend la comptabilité vérifiable. Le GET d'un lot renvoie stats.credits_cost sous forme de trois nombres : initial, refunded, final. Les crédits sont débités au lancement du lot, puis recrédités pour chaque ligne sans résultat. L'exemple de la doc porte sur 3 lignes, dont 2 trouvées, et se solde par {initial: 3, refunded: 1, final: 2}. Vous pouvez rapprocher un mois de dépenses des lignes réellement trouvées, sans ouvrir de ticket au support.

Une réserve s'impose, dans l'autre sens cette fois. L'Email Verifier d'Enrow se facture au contrôle, 0,25 crédit, pas au résultat valide. Envoyez-lui des adresses mortes et vous payez quand même 0,25 crédit par ligne. Trouver se paie au résultat ; vérifier se paie au contrôle. Mieux vaut le savoir avant d'envoyer toute une base à nettoyer sur le mauvais endpoint.

2. La latence, et si l'appel bloque

Deux partis pris de conception s'affrontent, et aucun n'est mauvais.

Certaines API répondent en synchrone. Anymail Finder annonce que la plupart des recherches unitaires aboutissent en trois secondes environ. Hunter va jusqu'à exposer l'arbitrage sous forme de paramètre : max_duration, entre 3 et 20 secondes, 10 par défaut, la doc précisant qu'une durée plus longue permet d'affiner les résultats et de renvoyer des données plus exactes. Un réglage d'une honnêteté rare. La précision se paie en millisecondes, et Hunter vous laisse choisir combien en dépenser.

Enrow a choisi l'autre voie. Tous les endpoints sont asynchrones. Un POST sur /email/find/single renvoie immédiatement un identifiant de recherche, et vous obtenez le résultat par webhook ou en interrogeant le GET correspondant. La doc présente ce choix comme délibéré : un gros volume ne doit jamais bloquer l'appelant. Tant que la recherche est en cours, le GET répond {"qualification": "ongoing"}.

La vérification elle-même se fait en quelques secondes. Mais votre traitement ne reste pas bloqué à l'attendre, et un code qui cherche l'adresse dans la réponse du POST ne l'y trouvera pas.

Le bon choix dépend de l'endroit où s'exécute la recherche. Dans un formulaire, sous les yeux d'un utilisateur, un appel synchrone de trois secondes ne pose aucun problème. Dans un traitement de nuit sur 40 000 lignes, un appel bloquant devient un risque. La RFC 9110 §15.3.3 couvre ce second cas : 202 Accepted signifie que la requête a été acceptée pour un traitement qui n'est pas encore terminé.

Ce que personne ne publie, c'est un p95. Ni Enrow, ni les éditeurs cités plus haut. Le marketing dit « en quelques secondes » et personne ne s'engage sur un percentile. Mesurez-le sur votre propre volume avant de bâtir une architecture autour d'un chiffre de landing page.

3. Ce que le payload de réponse vous dit vraiment

Ici, le marché se divise en deux écoles, et se tromper d'école vous coûte des semaines de développement.

Première école : on vous confie l'incertitude. L'Email Finder de Hunter renvoie un score de 0 à 100, un booléen accept_all, un objet verification dont le statut vaut valid, accept_all ou unknown, et jusqu'à vingt entrées sources qui indiquent la page où la mention a été trouvée, avec les dates extracted_on et last_seen_on. Sa doc dit franchement ce que vaut le score sur un domaine accept-all : il estime la probabilité que l'adresse soit valide. ZeroBounce fait la même chose sur une échelle plus grossière, avec un email_confidence à HIGH, MEDIUM ou LOW et l'une des neuf valeurs de failure_reason.

C'est utile si vous construisez votre propre couche de scoring. Le tableau sources est un vrai outil d'enquête.

Seconde école : on tranche la question et on vous rend un verdict. Le finder d'Enrow renvoie une qualification à valid ou invalid, avec ongoing tant que la recherche tourne. La doc l'écrit sans détour : des résultats binaires, aucune catégorie probabiliste. S'y ajoutent email, un bloc info qui contient le domaine et le nom de l'entreprise, le prénom et le nom, et l'objet custom que vous aviez envoyé.

La bonne question n'est pas de savoir quel payload est le plus riche, mais qui fixe le seuil. Si l'API vous renvoie un score de 0 à 100 et un accept_all: true, c'est à vous de fixer ce seuil, pour toujours, et chaque commercial qui se plaint d'un bounce conteste en fait un seuil que vous avez choisi. Si elle renvoie valid ou invalid, le seuil appartient à l'éditeur, et c'est lui qui en répond.

L'objet custom vous épargne une bonne partie de la plomberie. Ce que vous y mettez — par requête, et ligne par ligne dans un lot — revient intact dans la réponse du GET et dans le webhook. Identifiant de contact interne, tag de campagne, identifiant de fiche CRM : tout ce qui sert de clé à votre traitement. Pas de table de rapprochement à maintenir.

4. Domaines catch-all : tranchés, ou renvoyés dans votre camp

Un domaine accept-all répond oui à toutes les adresses que vous testez. Boîte réelle, faute de frappe, suite de caractères absurde : tout est accepté. Ce n'est pas un défaut d'éditeur, c'est prévu par le protocole. La RFC 5321 §3.5.3 envisage ce cas : il existe des cas où une adresse paraît valide sans pouvoir être raisonnablement vérifiée en temps réel, et le serveur doit alors renvoyer un 252. Et le §3.3 note que certains serveurs ne contrôlent le destinataire qu'à l'arrivée du corps du message : une adresse acceptée peut donc être rejetée plus tard.

Un seul test SMTP ne peut pas trancher. C'est une limite du protocole, pas une lacune des outils.

La plupart des API vous renvoient donc l'ambiguïté. Le vérificateur de Hunter renvoie accept_all, et sa propre doc prévient que lorsque le serveur SMTP accepte tout, les contrôles SMTP peuvent produire des faux positifs. C'est honnête, et ça vous laisse sur les bras un paquet de lignes dont personne ne veut.

Ne jetez pas ce paquet. Les entreprises qui peuplent les listes B2B comptent justement parmi les plus susceptibles d'être en accept-all : supprimer ces lignes sur la seule foi de l'indicateur, c'est jeter des décideurs bien vivants avec les lignes mortes.

Enrow tranche les catch-all de façon déterministe au lieu de les étiqueter. Parmi les plus de 10 vérifications qui précèdent chaque résultat figurent plusieurs passes SMTP depuis des serveurs situés dans des régions différentes, comparées à des adresses de contrôle volontairement fausses sur le même domaine. Une adresse catch-all tranchée ressort en valid et se facture comme trouvée. Celle qu'on n'arrive pas à trancher ressort comme invalide et ne coûte rien. Cette vérification est comprise dans le prix du crédit, pas vendue en option. Le taux de bounce observé reste sous 1 %, une moyenne relevée sur de vrais envois, pas une garantie. Le mécanisme est détaillé dans l'article « Qu'est-ce qu'un email catch-all », et les dégâts en aval dans celui sur le taux de bounce.

Bulk email finder : endpoints en lot et limites de débit

En volume, la taille du lot prime sur le plafond par seconde : dix requêtes contre environ 83 minutes de POST.

Un bulk email finder, c'est un endpoint qui accepte une liste entière de contacts en une seule requête et renvoie les adresses vérifiées sous forme de traitement par lot, au lieu d'un appel HTTP par personne. C'est la différence entre une chaîne qui se termine dans la nuit et une chaîne qui ne se termine pas.

Les plafonds de lot et les limites de débit varient énormément d'un éditeur à l'autre, et ils se combinent.

Faites le calcul sur un traitement de 50 000 lignes. En recherches unitaires, avec un plafond de 10 req/s, ça donne 5 000 secondes de soumission, soit environ 83 minutes de POST avant même de commencer à récupérer les résultats. Le même traitement en mode lot, c'est dix requêtes. Avec les 60 requêtes par minute documentées chez Snov, le mode unitaire s'étale sur quatorze heures.

En volume, la taille du lot pèse donc plus lourd que le nombre de requêtes par seconde. Le plafond d'Enrow est fixe : 10 POST par seconde et par clé API, les GET ne sont pas comptés, et une augmentation s'obtient sur demande à api@enrow.io. Aucun plafond supérieur n'est publié : ne bâtissez rien en supposant qu'il existe.

Réessais, idempotence, et pourquoi la facturation change votre stratégie

POST n'est pas idempotent. La RFC 9110 §9.2.2 dit qu'un client peut rejouer une requête quand aucune réponse n'arrive, mais à condition que cette requête puisse être considérée comme idempotente pour les besoins du réessai — ce qu'un POST de recherche n'est pas. Une requête rejouée après un timeout devient un second événement facturable, sauf si l'éditeur la déduplique.

L'en-tête vers lequel tout le monde se tourne, Idempotency-Key, n'est pas un standard. C'est un Internet-Draft de l'IETF, draft-ietf-httpapi-idempotency-key-header, expiré à la révision 07. Sa prise en charge dépend de chaque éditeur et reste inégale. Hunter l'implémente proprement — TTL de 24 heures, empreinte du corps de la requête, quatre codes d'erreur distincts — mais seulement sur ses endpoints sequences et messages. Pas sur l'Email Finder.

En facturation à la tentative, c'est un vrai problème. Votre logique de réessai devient une décision budgétaire, et un backoff agressif sur un réseau instable double la facture du mois sans prévenir.

En facturation au résultat, le problème disparaît en grande partie. Une recherche rejouée qui ne trouve rien ne coûte rien : vous pouvez réessayer agressivement après un timeout sans surveiller le compteur. En grande partie, pas totalement — un réessai qui retrouve la même adresse reste facturé comme un résultat trouvé, et Enrow ne publie aucune garantie de déduplication. Gardez votre propre journal des identifiants de recherche en cours. Le paiement au résultat rend les réessais bon marché, pas gratuits.

Enrow ne fournit pas deux autres choses, et je préfère le dire franchement : sinon, vous le découvririez à deux heures du matin. Il n'y a pas d'en-têtes X-RateLimit-*, et un 429 revient sous la forme d'un simple {"message": "Too Many Requests"}. La RFC 6585 §4 rend Retry-After facultatif, Enrow l'omet, et la doc vous demande donc de construire vous-même un backoff exponentiel calé sur le plafond fixe. Quant au 404, il ne figure pas du tout dans les codes de statut documentés — la liste tient en 400, 401, 402, 429 et 500 — donc un gestionnaire d'erreurs qui attend un 404 en bonne et due forme, pour un identifiant de recherche inconnu ou expiré, ne se déclenchera jamais.

La mise en place

L'authentification, c'est une clé API dans un en-tête x-api-key. Pas de flux OAuth, pas de bearer token, et la doc l'écrit en toutes lettres. L'URL de base est https://api.enrow.io.

Chaque POST a son GET : /email/find/single, /email/find/bulk, /email/verify/single, /email/verify/bulk, /phone/single, /phone/bulk, plus un GET /account/info qui renvoie votre solde de crédits sous forme d'un nombre unique, ainsi que les URL de webhook configurées.

Six événements de webhook couvrent ces endpoints. Les événements de recherche unitaire contiennent le résultat complet : une intégration unitaire bien faite n'a donc jamais besoin d'interroger l'API. Les événements de lot vous indiquent seulement que le traitement est terminé ; les lignes et le décompte des crédits s'obtiennent via le GET correspondant. L'URL de webhook se règle globalement sur la page des intégrations, ou requête par requête dans settings.webhook ; l'URL doit être en HTTPS et répondre 200.

Les erreurs à traiter : 401 pour une clé invalide, 402 pour un solde de crédits insuffisant, 429 pour la limite de débit. Attention au 402 — il renvoie {reason, success} sur les endpoints unitaires et un simple {message} sur les lots, de quoi casser un parseur d'erreurs commun. Des SDK officiels existent désormais, dans sept langages : JS/TypeScript, Python, PHP, Go, Java, Swift et Rust, d'après docs.enrow.io/sdks/overview, consulté le 29 août 2026. Les sept sont en accès anticipé et s'installent depuis les sources GitHub plutôt que depuis un registre de paquets — c'est donc à vous d'épingler un commit, et les exemples curl et JavaScript de la doc restent le filet de secours. La spécification complète est sur la page API d'Enrow ; obtenir une clé prend une trentaine de secondes, sans passer par un commercial.

Si votre appelant est un agent IA plutôt qu'un service, il existe un serveur MCP officiel : le dépôt EnrowAPI/enrow-mcp sur GitHub, sous licence MIT, installable via npm ou exécutable via npx. Il expose la recherche d'email, la vérification et la recherche de numéro sous forme d'outils — find_email, find_emails_bulk, verify_email, find_phone et leurs équivalents de récupération de résultat — et la doc cite Claude Desktop, Cursor et Windsurf comme clients. Un assistant peut trouver les coordonnées d'un contact en pleine conversation, sans une ligne de code d'intégration.

L'extension Chrome email finder : la voie sans code

Beaucoup de gens qui ont besoin de cette donnée n'ouvriront jamais un terminal. Pour eux, le bon outil, c'est une extension Chrome, pas une API.

L'extension d'Enrow part d'un profil LinkedIn ou Sales Navigator. Un clic enregistre la fiche complète dans HubSpot, Salesforce ou Pipedrive : nom, email vérifié, numéro de portable, entreprise, URL LinkedIn. Pas une adresse copiée puis collée dans un champ — toute la fiche contact. La facturation est celle de l'API : un crédit par email vérifié, 40 par numéro vérifié, rien sans résultat.

Les RevOps construisent la chaîne, les commerciaux travaillent profil par profil. Même compteur de crédits, même vérification, deux outils. Le détail figure dans notre guide email finder LinkedIn et dans notre article sur l'enrichissement HubSpot.

Ce que cette API ne fera pas pour vous

Pas de base interrogeable. Demandez à Enrow « tous les CTO de Berlin dans des entreprises de plus de 200 personnes » et vous n'obtiendrez rien, parce qu'il n'y a aucune liste à interroger. La recherche d'email a besoin d'un nom complet et d'un domaine ou d'un nom d'entreprise ; celle de numéro, d'une URL LinkedIn.

C'est un arbitrage assumé, et voici pourquoi. Les éditeurs de bases rafraîchissent leurs données selon des cycles qui se comptent en mois : une part non négligeable de ce qu'ils vendent décrit des gens qui ont déjà changé de poste. Enrow cherche au moment de la demande, et c'est ce qui garantit la précision. Le prix à payer, c'est que le sourcing devient votre affaire. Constituez la liste sur LinkedIn ou Sales Navigator, puis soumettez-la à l'API. Pour les campagnes, tournez-vous vers Emelia, La Growth Machine ou lemlist.

Ce que coûte un contact vérifié

Comme la facturation porte sur le résultat trouvé, le prix affiché et le coût réel sont identiques. L'offre Start coûte 15 €/mois pour 1 000 crédits, soit 0,015 € l'email valide. Pro, 75 €/mois pour 10 000, soit 0,0075 €. Scale, 360 €/mois pour 50 000, et la grille mensuelle monte jusqu'à 200 000 crédits à 1 250 €/mois. Passez ce dernier palier en annuel et vous descendez à environ 0,0056 € l'email, le meilleur tarif de la grille. Un numéro de portable coûte 40 crédits, soit environ 0,30 € sur Pro. La vérification coûte 0,25 crédit par contrôle, que l'adresse soit vivante ou morte.

Comparez avec un éditeur qui facture à la tentative, à volume mensuel égal et sur la même base de facturation, pas en opposant deux prix affichés. Prenez un outil à 0,02 € la recherche tentée, avec un taux de couverture de 30 % : il vous coûte 0,067 € le contact trouvé, avant même de compter les bounces. C'est le seul chiffre qui mérite d'entrer dans un tableur.

Il n'y a pas de facturation par utilisateur, le nombre de membres d'équipe est illimité sur Pro et Scale, et les crédits se reportent jusqu'à 3 fois votre forfait mensuel sur Pro et 6 fois sur Scale. L'offre gratuite, elle, donne 50 crédits renouvelés chaque mois, sans carte bancaire.

FAQ

Une recherche infructueuse consomme-t-elle un crédit ?

Ça dépend de l'éditeur, et c'est la première chose à vérifier. Enrow, Anymail Finder et Findymail écrivent tous les trois que leurs endpoints de recherche ne facturent qu'un résultat trouvé ; ZeroBounce ne facture rien quand le résultat est inconnu. Les outils qui facturent à la tentative, eux, font payer la demande. Partez d'un taux de couverture de 30 % sur une liste B2B froide : la facturation à la tentative multiplie par plus de trois le coût réel par contact, de quoi effacer n'importe quelle différence de prix affiché.

Existe-t-il une API email finder gratuite ?

Des offres gratuites, oui. Des API gratuites en permanence et en volume, en général non, parce que chaque recherche représente pour le fournisseur un vrai travail SMTP. Enrow offre 50 crédits renouvelés chaque mois, sans carte bancaire : 50 emails vérifiés ou 200 vérifications, indéfiniment. De quoi construire une intégration et la tester de bout en bout.

En combien de temps une API email finder doit-elle répondre ?

Un appel synchrone qui dépasse cinq secondes environ pose des problèmes dès qu'un humain attend devant son écran. Hunter vous laisse régler ce curseur avec un paramètre max_duration compris entre 3 et 20 secondes, et précise dans sa doc qu'une durée plus longue donne des données plus exactes. Pour un traitement par lot, c'est le débit qui compte, pas la latence ligne par ligne. Personne sur ce marché ne publie de p95 : mesurez-le sur votre propre volume.

Peut-on utiliser une API email finder en lot ?

Oui, et c'est même conseillé au-delà de quelques centaines de lignes. Enrow accepte jusqu'à 5 000 contacts par lot de recherche d'emails et 3 000 par lot de téléphones, et les résultats vous parviennent par webhook ou via un GET. L'API v2 de Hunter n'expose aucun endpoint de recherche en lot : chez Hunter, le traitement par lot passe par l'interface. Vérifiez que l'endpoint existe avant de bâtir votre architecture dessus.

Peut-on réessayer sans risque une recherche qui a expiré ?

Techniquement oui, mais évaluez d'abord ce que ça coûte. POST n'est pas idempotent au sens de la RFC 9110, et Idempotency-Key est un Internet-Draft de l'IETF expiré dont la prise en charge varie d'un éditeur à l'autre : un réessai est en principe un second événement facturable. En facturation au résultat valide, un réessai qui ne trouve rien ne coûte rien, ce qui permet de fixer des timeouts courts sans risque pour le budget. Gardez quand même la trace des identifiants de recherche en cours.

Ai-je le droit d'enrichir des contacts que je n'ai pas collectés moi-même ?

Dans l'UE, la base juridique est l'article 6(1)(f) du RGPD, l'intérêt légitime, avec l'obligation d'information de l'article 14 et l'exemption de l'article 14(5)(b) quand cette information demande des efforts disproportionnés. La prospection B2B y entre souvent, mais c'est à vous de mener l'analyse et de la documenter — avec un avocat, pas avec un article de blog. Enrow détient la documentation juridique pour les numéros de portable européens.

Testez les quatre critères sur votre propre liste. L'API d'Enrow vous remet une clé en une trentaine de secondes, et l'offre gratuite donne 50 crédits chaque mois, sans carte bancaire.