La API de email finder: las cuatro cosas que la documentación no te cuenta

Todos los proveedores documentan los mismos endpoints; las cuatro respuestas que deciden tu factura, casi nadie las publica.

Lo esencial Una API de email finder coge a alguien que tú ya has identificado (normalmente un nombre y una empresa) y te devuelve su dirección profesional verificada. Los endpoints que documenta cada proveedor son prácticamente los mismos. Lo que casi nadie contesta son las cuatro preguntas que deciden tu factura y tu arquitectura: si se cobra el intento o el resultado verificado, cuánto tarda una consulta y si te bloquea el proceso, a qué se compromete realmente la respuesta, y si un dominio catch-all vuelve resuelto o te lo devuelven sin resolver. Hay una quinta que solo muerde con volumen: qué le hace al límite de peticiones un trabajo de 50.000 filas. Las respuestas de Enrow, para tenerlas de referencia: solo se cobra el resultado válido, todo asíncrono por diseño, catch-all verificadas en vez de etiquetadas, 10 peticiones por segundo en los POST y lotes de 5.000 filas. Lee la línea de facturación antes que la lista de funciones. Mueve el coste real mucho más que el precio que ves.

Una API de email finder es un endpoint HTTP que convierte a una persona en su dirección de trabajo. Le mandas un nombre y una empresa. Te devuelve una dirección, más alguna afirmación sobre si existe de verdad.

Antes de nada, una aclaración, porque quien busca «email API» se topa sobre todo con otra cosa: proveedores de envío y relés transaccionales. Esos sacan correo hacia fuera. Un buscador resuelve una identidad hasta llegar a su dirección, antes de que exista ningún mensaje.

Los cuatro criterios que vienen ahora salen de construir una y de leerme, mientras la construía, la documentación de una docena de competidores. Las listas de endpoints son intercambiables. El modelo de facturación, el contrato de latencia, la forma de la respuesta y el tratamiento de las catch-all no lo son, y los cuatro suelen estar enterrados. El tope por lote también cuenta, solo que a partir de cierto volumen, así que va en su propia sección detrás de ellos.

1. Facturado por intento, o por resultado verificado

Si pagas los fallos, cada contacto encontrado te sale a más del triple de lo que cuesta la búsqueda.

Aquí se decide todo, y es justo la línea que la mayoría de las páginas de precios se salta.

Hay dos modelos. Con el primero se cobra cuando preguntas: el proveedor gasta cómputo, no devuelve nada útil y se lleva el crédito igual. Con el segundo, un fallo sale gratis y solo se te descuenta un crédito cuando vuelve una dirección que llega a la bandeja de entrada.

La diferencia no es un redondeo. La mayoría de los proveedores no publica ninguna tasa de acierto, así que sobre una lista fría B2B parto de un 30 % como hipótesis de trabajo. Con ese 30 %, quien cobra por intento te está facturando más de tres veces cada contacto que de verdad te llevas. Y luego una parte de lo que sí encontró hace bounce, y eso también lo has pagado.

Hay unos cuantos proveedores que lo ponen por escrito, y eso tiene su mérito. Anymail Finder se lleva un crédito solo cuando la dirección está verificada. Findymail igual, un crédito por dirección encontrada. ZeroBounce factura la búsqueda que sale bien y no cobra nada por una que vuelve como desconocida.

Los endpoints de búsqueda de Enrow funcionan igual, y la respuesta de un lote deja la contabilidad auditable. Un GET por lotes devuelve stats.credits_cost con tres números, initial, refunded y final. Los créditos se descuentan cuando arranca el lote y se devuelven por cada fila que vuelve vacía. El ejemplo de la documentación manda 3 filas, encuentra 2 y cierra en {initial: 3, refunded: 1, final: 2}. Cuadras un mes de gasto contra las filas encontradas sin abrir un ticket a soporte.

Una salvedad, porque esta va en tu contra. El Email Verifier de Enrow se cobra por comprobación, 0,25 créditos, y no por resultado válido. Si le metes direcciones muertas, pagas 0,25 por fila igual. Buscar se factura sobre lo que se encuentra; verificar se factura sobre lo que se comprueba. Tenlo claro antes de meter una limpieza de fichero por el endpoint equivocado.

2. La latencia, y si la llamada te bloquea

Dos filosofías de diseño, y ninguna de las dos está mal.

Hay APIs que contestan de forma síncrona. Anymail Finder dice que la mayoría de sus consultas sueltas vuelven en unos tres segundos. Hunter convierte el compromiso en un parámetro, max_duration, entre 3 y 20 segundos, por defecto 10, y su documentación explica que una duración más larga les deja afinar el resultado y devolver datos más precisos. Un mando poco habitual, y honesto. La precisión cuesta milisegundos y te dejan gastarlos.

Enrow tiró por el otro lado. Todos los endpoints son asíncronos. Un POST a /email/find/single te devuelve un id de búsqueda al momento, y el resultado llega por webhook o consultando el GET correspondiente. La documentación dice que eso es a propósito, para que un volumen grande no bloquee nunca a quien llama. Mientras la búsqueda corre, el GET responde {"qualification": "ongoing"}.

La verificación en sí se resuelve en segundos. Solo que tu proceso no se queda esperándola, y el código que espere encontrar la dirección en la respuesta del POST no la va a encontrar ahí.

Cuál te conviene depende de dónde vive la consulta. Dentro de un formulario que una persona está mirando, una llamada síncrona de tres segundos no da ningún problema. Dentro de un proceso nocturno sobre 40.000 filas, una llamada que bloquea es un riesgo. El segundo caso lo cubre el RFC 9110 §15.3.3: un 202 Accepted significa aceptado para un procesamiento que todavía no ha terminado.

Lo que no publica nadie es un p95. Ni Enrow ni ninguno de los de arriba. El marketing dice «en segundos» y nadie se moja con un percentil. Mídelo contra tu propio volumen antes de montar una arquitectura encima de una cifra de landing.

3. Qué te dice de verdad la respuesta

Aquí el mercado se parte en dos escuelas, y elegir la que no te toca cuesta semanas de ingeniería.

La primera te pasa la incertidumbre a ti. El Email Finder de Hunter devuelve un score de 0 a 100, un booleano accept_all, un objeto verification con estado valid, accept_all o unknown, y hasta veinte entradas en sources con la página de la que salió cada mención y sus fechas extracted_on y last_seen_on. Su documentación es franca sobre lo que vale ese score en un dominio que lo acepta todo: estima la probabilidad de que la dirección sea válida. ZeroBounce hace lo mismo con menos grano, devolviendo email_confidence como HIGH, MEDIUM o LOW más uno de los nueve valores de failure_reason.

Sirve si te estás montando tu propia capa de puntuación. El array sources es una herramienta forense seria.

La segunda zanja la pregunta y te da un veredicto. El buscador de Enrow devuelve qualification como valid o invalid, y ongoing mientras la búsqueda corre. La documentación lo dice sin rodeos: resultados binarios, sin categorías probabilísticas. Al lado viajan email, un bloque info con el dominio y el nombre de la empresa, el nombre y el apellido, y el objeto custom que tú mandaste.

La pregunta no es cuál de las dos respuestas trae más datos. Es de quién es el umbral. Si la API te devuelve un 0-100 y un accept_all: true, el umbral es tuyo para siempre, y cada comercial que se queje de un bounce se está quejando de un número que elegiste tú. Si te devuelve válido o inválido, el umbral es del proveedor y a él le pides cuentas.

El objeto custom te quita toda una clase de código de pegamento. Lo que metas ahí, por petición y por fila dentro de un lote, vuelve intacto en la respuesta del GET y en el webhook. El id interno del contacto, la etiqueta de campaña, el id del registro en el CRM, lo que sea que use tu proceso como clave. Sin tabla de reconciliación.

4. Dominios catch-all: resueltos, o devueltos a tu tejado

Un dominio que lo acepta todo dice que sí a cualquier dirección que le sondees. Buzón real, errata, disparate absoluto, todo aceptado. No es un fallo del proveedor, está en el protocolo. El RFC 5321 §3.5.3 lo anticipa: hay circunstancias en las que una dirección parece válida y no se puede verificar razonablemente en tiempo real, y entonces el servidor debería contestar un 252. El §3.3 añade que algunos servidores no comprueban el destinatario hasta que llega el cuerpo del mensaje, con lo cual una dirección aceptada todavía puede hacer bounce más tarde.

Con una sola sonda SMTP no hay manera. Es un hecho del protocolo, no una carencia de la herramienta.

De modo que casi todas las APIs te pasan la ambigüedad. El verificador de Hunter devuelve accept_all, y su propia documentación avisa de que, cuando el servidor SMTP lo acepta todo, las comprobaciones SMTP pueden dar falsos positivos. Honesto, y te deja un montón de filas que nadie quiere firmar.

No tires ese montón. Las listas B2B se cargan justo hacia las empresas con más papeletas de tener un servidor que lo acepta todo, de manera que borrar por la etiqueta se lleva por delante responsables de decisión vivos junto con las filas muertas.

Enrow resuelve las catch-all de forma determinista en vez de marcarlas: pasadas SMTP repetidas desde servidores en regiones distintas, contrastadas con direcciones de control falsas a propósito en ese mismo dominio, dentro de las más de 10 verificaciones que hay detrás de cada resultado. Las catch-all resueltas vuelven como valid y se facturan como encontradas. Las que no se dejan resolver vuelven como inválidas y no cuestan nada. Verificar una catch-all va dentro del precio del crédito, no es un extra. El bounce observado se queda por debajo del 1 %, que es una media de envíos reales y nunca una promesa. La mecánica está en qué es un email catch-all, y el destrozo que provoca aguas abajo, en la tasa de bounce.

Endpoints de búsqueda en masa y límites de peticiones

Con volumen, manda el tamaño del lote, no el tope por segundo: diez peticiones contra unos 83 minutos de POST.

Un buscador de emails en masa es un endpoint que acepta una lista entera de contactos en una sola petición y devuelve las direcciones verificadas como un trabajo por lotes, en lugar de una llamada HTTP por persona. Es la diferencia entre un proceso que termina esta noche y uno que no termina.

Los topes por lote y los límites de peticiones varían muchísimo, y encima se cruzan entre ellos.

Haz la cuenta sobre un trabajo de 50.000 filas. En modo consulta suelta, contra un tope de 10 peticiones por segundo, son 5.000 segundos de envíos, unos 83 minutos de POST antes siquiera de ponerte a recoger resultados. El mismo trabajo en modo lote son diez peticiones. Contra las 60 por minuto que documenta Snov, el modo suelto se te va a una ventana de catorce horas.

O sea que, con volumen, el tamaño del lote pesa más que la cifra por segundo. El tope de Enrow es plano: 10 POST por segundo y por clave de API, los GET sin contar, y se puede pedir una subida escribiendo a api@enrow.io. Por encima de eso no hay ninguna cifra publicada, así que no montes nada dando una por buena.

Reintentos, idempotencia y por qué la facturación te cambia la estrategia

El POST no es idempotente. El RFC 9110 §9.2.2 dice que un cliente puede repetir una petición cuando no le llega respuesta, pero que esa petición debería considerarse idempotente a efectos de reintento, y un POST de búsqueda no lo es. Un tiempo de espera agotado que reintentas es un segundo evento facturable, salvo que el proveedor lo deduplique.

La cabecera a la que echa mano todo el mundo, Idempotency-Key, no es un estándar. Es un borrador del IETF, draft-ietf-httpapi-idempotency-key-header, caducado en la revisión 07. El soporte va por proveedor y es irregular. Hunter la implementa como toca (TTL de 24 horas, huella del cuerpo de la petición, cuatro códigos de error distintos), pero solo en sus endpoints de secuencias y de mensajes. En el Email Finder, no.

Con facturación por intento, eso es un problema de los gordos. La lógica de reintento se convierte en una decisión de gasto, y un backoff agresivo sobre una red inestable te duplica la factura del mes sin hacer ruido.

Cuando solo se cobra el resultado válido, el problema casi desaparece. Un reintento que no encuentra nada no cuesta nada, con lo cual puedes apretar los tiempos de espera sin que eso te encarezca el mes. Casi, no del todo: un reintento que encuentra la misma dirección sigue siendo un resultado encontrado, y Enrow no publica ninguna garantía de deduplicación. Lleva tú el registro de los ids de búsqueda que tengas en vuelo. Cobrar solo lo válido abarata los reintentos, no los regala.

Dos cosas más que Enrow no te da, dichas a las claras porque, si no, te vas a enterar a las dos de la mañana. No hay cabeceras X-RateLimit-*, y un 429 vuelve pelado, {"message": "Too Many Requests"}. El RFC 6585 §4 deja Retry-After como opcional y Enrow no lo manda, de modo que su propia documentación te dice que te montes tú el backoff exponencial contra ese tope plano. Y el 404 no aparece en los códigos de estado documentados (la lista va 400, 401, 402, 429 y 500), con lo cual un gestor de errores que espere un 404 limpio para un id de búsqueda desconocido o caducado no se va a disparar jamás.

Cómo se conecta

La autenticación es una clave de API en una cabecera x-api-key. Ni flujo OAuth ni tokens bearer, y la documentación lo dice con esas mismas palabras. La URL base es https://api.enrow.io.

Cada POST tiene su GET correspondiente: /email/find/single, /email/find/bulk, /email/verify/single, /email/verify/bulk, /phone/single y /phone/bulk, más un GET /account/info que te devuelve en un solo número el saldo de créditos que te queda y las URL de webhook que tengas configuradas.

Seis eventos de webhook cubren esos endpoints. Los de búsqueda suelta llevan el resultado entero, o sea que una integración unitaria bien montada no consulta nunca. Los de lote solo te dicen que el lote ha terminado; las filas y la cuenta de créditos salen del GET correspondiente. La URL del webhook se pone de forma global en la página de integraciones, o petición a petición en settings.webhook, solo por HTTPS, y tiene que contestar un 200.

Errores que merece la pena gestionar: un 401 por clave mala, un 402 por créditos insuficientes y un 429 por el límite de peticiones. Ojo con el 402, porque contesta {reason, success} en los endpoints unitarios y la forma pelada {message} en los de lote, y eso rompe cualquier parser de errores compartido. Ya hay SDK oficiales en siete lenguajes: JS/TypeScript, Python, PHP, Go, Java, Swift y Rust, según docs.enrow.io/sdks/overview el 29 de agosto de 2026. Los siete están en acceso anticipado y se instalan desde el código de GitHub, no desde un registro de paquetes, así que el commit lo fijas tú y los ejemplos en curl y en JavaScript de la documentación siguen siendo el plan B. La especificación completa está en la página de la API de Enrow; sacar una clave son unos treinta segundos, sin llamada comercial.

Si quien llama es un agente de IA y no un servicio, hay un servidor MCP oficial, el repositorio EnrowAPI/enrow-mcp en GitHub, con licencia MIT, que se instala por npm o se lanza con npx. Expone el buscador, el verificador y la consulta de teléfono como herramientas (find_email, find_emails_bulk, verify_email, find_phone y sus equivalentes para recoger el resultado), con Claude Desktop, Cursor y Windsurf documentados como clientes. Un asistente resuelve un contacto en mitad de una conversación, sin escribir una línea de integración.

La Chrome extension: la vía sin código

Mucha de la gente que necesita estos datos no va a abrir un terminal en su vida. Para ellos la superficie correcta es una Chrome extension, no una API.

La extensión de Enrow trabaja desde un perfil de LinkedIn o de Sales Navigator. Un clic escribe la ficha entera en HubSpot, Salesforce o Pipedrive: nombre, email verificado, móvil, empresa y URL de LinkedIn. No una dirección copiada y pegada en un campo, la ficha de contacto completa. La facturación es la misma que en la API, un crédito por email verificado, 40 por móvil verificado y nada sin resultado.

RevOps monta el circuito; los comerciales trabajan perfiles. La misma bolsa de créditos, la misma verificación, dos superficies. Más detalle en cómo buscar emails desde LinkedIn y en el enriquecimiento de datos en HubSpot.

Lo que esta API no va a hacer por ti

No hay ninguna base de datos que puedas consultar. Pídele a Enrow «todos los CTO de Berlín en empresas de más de 200 personas» y no vuelve nada, porque no existe ninguna lista contra la que preguntar. El buscador necesita un nombre completo más el dominio o el nombre de la empresa. El buscador de teléfonos necesita una URL de LinkedIn.

Es un cambio hecho a propósito, y tiene su razón. Quien vende base de datos la refresca en ciclos que se miden en meses, de manera que una parte nada pequeña de lo que vende describe a gente que ya ha cambiado de puesto. Enrow resuelve en el momento de la petición, y por eso la precisión aguanta. Lo que pagas a cambio es que montar la lista pasa a ser cosa tuya. La montas en LinkedIn o en Sales Navigator y luego se la pasas a la API. El envío de campañas es trabajo de Emelia, La Growth Machine o lemlist.

Lo que cuesta cada contacto verificado

Como solo se factura el resultado encontrado, el precio que ves y el coste real son el mismo número. Start son 15 €/mes por 1.000 créditos, o sea 0,015 € por email válido. Pro, 75 €/mes por 10.000, 0,0075 €. Scale, 360 €/mes por 50.000, y la escala mensual sube hasta 200.000 créditos por 1.250 €/mes. Pasa ese último nivel a facturación anual y se queda en unos 0,0056 € por email, la tarifa más barata de toda la tabla. Un móvil son 40 créditos, unos 0,30 € en Pro. La verificación, 0,25 créditos por comprobación, esté viva o muerta la dirección.

Compara eso con quien cobra por intento al mismo volumen mensual y con la misma base de facturación, no el precio que ves contra el precio que ves. Una herramienta a 0,02 € por búsqueda lanzada, con una tasa de acierto del 30 %, te está costando 0,067 € por contacto encontrado, y eso antes de contar los que hacen bounce. Ese es el único número que merece la pena meter en una hoja de cálculo.

Sin coste por usuario, miembros de equipo ilimitados en Pro y en Scale, y los créditos se acumulan de un mes a otro hasta 3 veces tu plan en Pro y 6 veces en Scale. El plan gratuito son 50 créditos gratis cada mes, se renuevan solos y sin pedirte tarjeta.

FAQ

¿Una búsqueda fallida gasta crédito?

Depende del proveedor, y es lo primero que hay que mirar. Enrow, Anymail Finder y Findymail dicen los tres que sus endpoints de búsqueda solo facturan cuando hay resultado; ZeroBounce no cobra nada por una que vuelve como desconocida. Quien cobra por intento te cobra la pregunta. Supón un 30 % de acierto en una lista fría B2B y eso multiplica por más de tres el coste real por contacto, que se come cualquier diferencia de precio de portada.

¿Existe alguna API de email finder gratis?

Planes gratuitos hay. APIs gratis para siempre y con volumen, en general no, porque cada consulta le cuesta al proveedor trabajo SMTP real. Enrow te da 50 créditos gratis cada mes, sin tarjeta y durante el tiempo que quieras: 50 emails verificados o 200 comprobaciones. Suficiente para montar una integración entera y probarla.

¿Cuánto debería tardar en responder una API de email finder?

Una consulta síncrona que pase de unos cinco segundos te da problemas en cualquier cosa que vea el usuario. Hunter te deja ajustarlo con un parámetro max_duration de entre 3 y 20 segundos, y documenta que más duración significa más precisión. En trabajo por lotes lo que importa es el caudal, no la latencia de cada fila. Nadie publica un p95, de modo que mídelo tú contra tu propio volumen.

¿Se puede usar una API de email finder en masa?

Sí, y por encima de unos cientos de filas conviene. Enrow admite hasta 5.000 contactos por lote de búsqueda de emails y 3.000 por lote de teléfonos, y devuelve los resultados por webhook o por GET. La API v2 de Hunter no expone ningún endpoint de búsqueda en masa, con lo cual allí los lotes son una función del panel. Confirma que ese endpoint existe antes de montarle la arquitectura encima.

¿Es seguro reintentar una consulta que se ha quedado sin respuesta?

Técnicamente sí, pero ponle precio primero. El POST no es idempotente según el RFC 9110, y Idempotency-Key es un borrador del IETF caducado con un soporte irregular, de modo que un reintento suele ser un segundo evento facturable. Cuando solo se cobra el resultado válido, un reintento que no encuentra nada sale gratis y apretar los tiempos de espera deja de doler. Aun así, lleva tú el registro de los ids de búsqueda en vuelo.

¿Puedo enriquecer legalmente contactos que no he recogido yo?

En la UE esto se apoya en el artículo 6.1 f) del RGPD, el interés legítimo, junto con el deber del artículo 14 de informar a la persona de que tienes sus datos y la excepción del artículo 14.5 b) para cuando avisar supone un esfuerzo desproporcionado. La prospección B2B suele encajar, pero la evaluación te toca documentarla a ti, y mejor con un abogado que con una entrada de blog. Enrow tiene la documentación legal de los móviles europeos.

Pasa los cuatro criterios por tu propia lista. La API de Enrow te da una clave en unos treinta segundos, y el plan gratuito son 50 créditos gratis cada mes, sin tarjeta.