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 : facturé sur la demande ou sur le résultat vérifié, combien de temps prend une recherche et si l'appel bloque, ce que le payload de réponse engage vraiment, et si un domaine catch-all revient tranché ou renvoyé dans votre camp. Une cinquième ne fait mal qu'en volume : ce qu'un traitement de 50 000 lignes fait aux limites de débit. Les réponses d'Enrow, pour situer : facturation sur résultat valide uniquement, tout est asynchrone par conception, les catch-all sont vérifiés au lieu d'être étiquetés, 10 requêtes par seconde sur les POST, des 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, plus une forme d'affirmation 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à font sortir du courrier. Une API de recherche, elle, transforme une identité en adresse avant même qu'un message existe.

Les quatre critères qui suivent sont sortis de la construction de la nôtre, et de la lecture d'une douzaine de docs concurrentes 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 les quatre sont en général enterrés quelque part. Le plafond des lots compte aussi, mais seulement quand votre volume devient sérieux : il a droit à sa propre section, juste après.

1. Facturé à 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 sautent.

Deux modèles existent. En facturation à la tentative, vous payez au moment où vous demandez : l'éditeur dépense de la ressource, ne renvoie rien d'exploitable, et prend un crédit quand même. En facturation au résultat valide, un échec ne coûte rien, et le compteur ne bouge que lorsqu'une adresse qui fonctionne revient.

L'écart n'est pas une erreur d'arrondi. La plupart des éditeurs ne publient aucun taux de découverte, donc je retiens 30 % comme hypothèse de travail sur une liste B2B froide. À 30 %, un éditeur qui facture à la tentative vous fait payer plus de trois fois chaque contact que vous obtenez réellement. Ensuite, une partie de ce qu'il a trouvé bounce, et ça aussi vous l'avez payé.

Quelques éditeurs mettent la facturation au résultat noir sur blanc, et ça vaut quelque chose. Anymail Finder ne prend un crédit qu'une fois l'adresse vérifiée. Findymail pareil : un crédit sur une adresse trouvée. ZeroBounce facture une recherche aboutie et ne facture rien sur un résultat 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. Un GET en 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 rendus pour chaque ligne vide. L'exemple de la doc soumet 3 lignes, en trouve 2, et se solde à {initial: 3, refunded: 1, final: 2}. Vous rapprochez un mois de dépense des lignes réellement trouvées, sans ouvrir de ticket au support.

Une réserve, parce qu'elle joue dans l'autre sens. 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 par ligne. Trouver se paie au résultat ; vérifier se paie au contrôle. À savoir avant d'envoyer un nettoyage de base sur le mauvais endpoint.

2. La latence, et si l'appel bloque

Deux partis pris de conception, et aucun des deux n'est faux.

Certaines API répondent en synchrone. Anymail Finder annonce que la plupart des recherches unitaires reviennent 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 leur 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 coûte des millisecondes, et ils vous laissent les dépenser.

Enrow a pris l'autre route. Tous les endpoints sont asynchrones. Un POST sur /email/find/single renvoie immédiatement un identifiant de recherche, et le résultat arrive par webhook ou en interrogeant le GET correspondant. La doc dit que c'est un choix assumé, pour qu'un gros volume ne bloque jamais l'appelant. Pendant que la recherche tourne, le GET répond {"qualification": "ongoing"}.

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

Le bon choix dépend de l'endroit où vit la recherche. Dans un formulaire qu'un humain regarde, 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 accepté pour un traitement qui n'est pas 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 coupe 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 portent la page où la mention a été trouvée, avec les dates extracted_on et last_seen_on. Leur doc est franche sur 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.

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. À côté, email, un bloc info qui porte 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. C'est de savoir qui porte le seuil. Si l'API vous renvoie un 0-100 et un accept_all: true, ce seuil est à vous pour toujours, et chaque commercial qui se plaint d'un bounce se plaint d'un nombre que vous avez choisi. Si elle renvoie valid ou invalid, le seuil appartient à l'éditeur, et c'est lui que vous tenez responsable.

L'objet custom supprime toute une catégorie de code de 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, 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 dans le protocole. La RFC 5321 §3.5.3 l'anticipe : 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 bouncer plus tard.

Un seul test SMTP ne peut pas trancher. C'est un fait de protocole, pas une lacune d'outillage.

La plupart des API vous repassent 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 listes B2B penchent vers les entreprises les plus susceptibles d'être en accept-all : supprimer sur la foi du drapeau, 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 : plusieurs passes SMTP depuis des serveurs situés dans des régions différentes, confrontées à des adresses de contrôle volontairement fausses sur le même domaine, au sein des plus de 10 vérifications qui précèdent chaque résultat. Un catch-all tranché revient valid et se facture comme trouvé. Celui qu'on n'arrive pas à trancher revient invalide et ne coûte rien. Cette vérification est comprise dans le prix du crédit, ce n'est pas une option payante. Le bounce observé reste sous 1 %, moyenne relevée sur de vrais envois et pas une garantie. Le mécanisme est détaillé dans qu'est-ce qu'un email catch-all, les dégâts en aval dans 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 contre 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. Contre les 60 par minute documentées chez Snov, le mode unitaire vous ouvre une fenêtre de 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 chiffre n'est publié au-delà, donc ne construisez 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. Un timeout que vous rejouez devient un second événement facturable, sauf si l'éditeur le déduplique.

L'en-tête vers lequel tout le monde se tourne, Idempotency-Key, n'est pas un standard. C'est un draft IETF, draft-ietf-httpapi-idempotency-key-header, expiré à la révision 07. Le support dépend de chaque éditeur et reste inégal. 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 s'évapore en grande partie. Une recherche rejouée qui ne trouve rien ne coûte rien : vous pouvez être agressif sur les timeouts sans surveiller le compteur. En grande partie, pas totalement — un réessai qui retrouve la même adresse reste 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.

Deux autres choses qu'Enrow ne vous donne pas, dites franchement parce que sinon vous les découvrirez à 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 branché sur un 404 bien propre, pour un identifiant de recherche inconnu ou expiré, ne se déclenchera jamais.

Le câblage

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, avec les URL de webhook configurées.

Six événements de webhook couvrent ces endpoints. Les événements de recherche unitaire transportent le résultat complet : une intégration unitaire bien faite n'a donc jamais besoin d'interroger quoi que ce soit. Les événements de lot vous disent seulement que le traitement est terminé ; les lignes et le décompte des crédits viennent du 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 ; HTTPS obligatoire, et elle doit répondre 200.

Les erreurs qui méritent un traitement : 401 pour une clé invalide, 402 pour un solde de crédits insuffisant, 429 pour la limite de débit. Attention au 402 — il répond {reason, success} sur les endpoints unitaires et la forme {message} toute simple sur les lots, ce qui cassera un parseur d'erreurs mutualisé. 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 au 29 août 2026. Les sept sont en early access et s'installent depuis les sources GitHub plutôt que depuis un registre de paquets — vous épinglez donc un commit vous-même, 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, installé par npm ou lancé 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 — avec Claude Desktop, Cursor et Windsurf documentés comme clients. Un assistant résout 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, la bonne surface, c'est une extension Chrome, pas une API.

L'extension d'Enrow part d'un profil LinkedIn ou Sales Navigator. Un clic écrit 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 des profils. Même compteur de crédits, même vérification, deux surfaces. Le détail est dans le guide email finder LinkedIn et du côté de 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 rien ne revient, parce qu'il n'y a aucune liste à interroger. Le finder a besoin d'un nom complet et d'un domaine ou d'un nom d'entreprise. Le finder de téléphone a besoin d'une URL LinkedIn.

C'est un arbitrage assumé, et voici pourquoi. Les éditeurs de bases rafraîchissent sur 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 résout au moment de la demande, et c'est ce qui tient la précision. Le prix à payer, c'est que le sourcing devient votre affaire. Constituez la liste sur LinkedIn ou Sales Navigator, puis passez-la à l'API. Pour les campagnes, allez chez 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 le même nombre. Start, c'est 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 tombez autour de 0,0056 € l'email, le meilleur tarif de la grille. Un numéro de portable coûte 40 crédits, environ 0,30 € sur Pro. La vérification, 0,25 crédit par contrôle, que l'adresse soit vivante ou morte.

Comparez ça à un éditeur qui facture à la tentative, au même volume mensuel et sur la même base de facturation, pas prix affiché contre prix affiché. Prenez un outil à 0,02 € la recherche tentée, avec un taux de découverte de 30 % : il vous coûte 0,067 € le contact trouvé, avant même de compter ceux qui bounceront. C'est le seul nombre qui mérite d'entrer dans un tableur.

Pas de facturation par utilisateur, un nombre illimité de membres d'équipe sur Pro et Scale, et des crédits qui se reportent jusqu'à 3 fois votre plan sur Pro et 6 fois sur Scale. L'offre gratuite, elle, donne 50 crédits chaque mois, de façon récurrente, 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 que sur un résultat trouvé ; ZeroBounce ne facture rien sur un résultat inconnu. Les outils à la tentative, eux, facturent la demande. Partez d'un taux de découverte de 30 % sur une liste B2B froide et l'écart multiplie par plus de trois le coût réel par contact, de quoi écraser n'importe quel écart 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 coûte au fournisseur du vrai travail SMTP. Enrow donne 50 crédits chaque mois, de façon récurrente et sans carte : 50 emails vérifiés, ou 200 contrôles de vérification, 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 documente qu'une durée plus longue renvoie des données plus exactes. Sur du 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, avec les résultats renvoyés par webhook ou en interrogeant un GET. L'API v2 de Hunter n'expose aucun endpoint de recherche en lot : chez eux, le traitement par lot passe par l'interface. Vérifiez que l'endpoint existe avant de construire votre architecture autour.

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

Techniquement oui, mais chiffrez-le d'abord. POST n'est pas idempotent au sens de la RFC 9110, et Idempotency-Key est un draft IETF expiré dont le support varie d'un éditeur à l'autre : un réessai est normalement un second événement facturable. En facturation au résultat valide, un réessai qui ne trouve rien ne coûte rien, ce qui rend les timeouts agressifs abordables. 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, ça repose sur 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 l'analyse vous revient et se documente — avec un avocat, pas avec un article de blog. Enrow détient la documentation juridique pour les numéros de portable européens.

Passez 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.