API de email finder: o que a documentação não diz

Todos os fornecedores documentam os mesmos endpoints; as quatro respostas que decidem a conta, quase nenhum as publica.

O essencial Uma API de email finder recebe uma pessoa que o leitor já identificou — em regra um nome e uma empresa — e devolve um endereço profissional verificado. Os endpoints documentados são praticamente os mesmos de fornecedor para fornecedor. O que quase nenhum responde são as quatro perguntas que decidem a conta ao fim do mês e a arquitetura à volta dela: cobra-se a tentativa ou o resultado verificado, quanto demora uma pesquisa e se ela bloqueia o processo, ao que se compromete a resposta que chega, e se um domínio catch-all sai de lá resolvido ou fica em cima da sua secretária. Há uma quinta pergunta que só aparece a volume — o que um trabalho de 50 000 linhas faz ao limite de pedidos. As respostas da Enrow, para referência: só se debita crédito em resultado válido, todos os endpoints são assíncronos, os catch-all são verificados em vez de etiquetados, 10 pedidos por segundo nos POST, lotes de 5 000 linhas. Leia a linha da cobrança antes da lista de funcionalidades. Mexe mais no custo real do que o preço de tabela.

Uma API de email finder é um endpoint HTTP que transforma uma pessoa num endereço de email profissional. Envia-se um nome e uma empresa. Chega um endereço e, com ele, alguma afirmação sobre se aquilo existe.

Antes de mais, uma desambiguação, porque quem procura «email API» encontra sobretudo outra coisa: fornecedores de envio e relés transacionais. Esses despacham mensagens. Uma API de finder resolve a identidade em endereço antes de existir mensagem nenhuma.

Os quatro critérios que se seguem saíram de construir uma destas APIs e de ler, pelo caminho, a documentação de uma dúzia de concorrentes. As listas de endpoints são intermutáveis. O modelo de cobrança, o contrato de latência, a forma da resposta e o tratamento dos catch-all não são, e os quatro estão quase sempre enterrados no fundo da página. O limite dos lotes também conta, mas só quando o volume é a sério; por isso tem secção própria, a seguir a estes.

1. Cobra-se a tentativa, ou o resultado verificado

Quando se pagam as falhas, cada contacto encontrado sai a mais de três vezes o preço da pesquisa.

É aqui que se joga tudo, e é a linha que a maior parte das páginas de preços salta.

Há dois modelos. À tentativa: paga-se quando se pergunta. O fornecedor gasta computação, não encontra nada de útil e leva o crédito à mesma. Ao resultado válido: uma falha não custa nada, e só se debita crédito quando sai de lá um endereço que chega ao destino.

A diferença não é um arredondamento. A maioria dos fornecedores nem sequer publica uma taxa de descoberta, por isso parto de 30% como hipótese de trabalho numa lista B2B fria. A 30%, quem cobra à tentativa cobra mais de três vezes cada contacto que o leitor acaba por ter na mão. Depois uma parte do que foi encontrado faz bounce, e isso também já estava pago.

Alguns fornecedores põem esta cláusula por escrito, o que já vale alguma coisa. O Anymail Finder só debita crédito depois de o endereço estar verificado. No Findymail é igual: um crédito por endereço encontrado. E o ZeroBounce cobra a pesquisa que resulta, mas não cobra nada quando o resultado é «unknown».

Os endpoints de pesquisa da Enrow funcionam desta maneira, e a resposta em lote deixa a contabilidade auditável. Um GET de lote devolve stats.credits_cost em três números: initial, refunded, final. Os créditos saem do saldo quando o lote arranca e são repostos linha vazia a linha vazia. O exemplo da documentação submete 3 linhas, encontra 2 e fecha em {initial: 3, refunded: 1, final: 2}. Dá para cruzar um mês de despesa com as linhas encontradas sem abrir um pedido de apoio.

Uma ressalva, porque este caso corre ao contrário. O Email Verifier da Enrow cobra por controlo, 0,25 crédito, e não ao resultado válido. Dê-lhe endereços mortos e paga 0,25 por linha de qualquer maneira. Encontrar é ao resultado válido; verificar é ao controlo feito. Convém saber isto antes de mandar um trabalho de limpeza pelo endpoint errado.

2. Latência, e se a chamada bloqueia o processo

Duas filosofias de desenho, e nenhuma delas está errada.

Umas APIs respondem de forma síncrona. O Anymail Finder diz que a maior parte das pesquisas individuais responde em cerca de três segundos. O Hunter transformou o compromisso num parâmetro: max_duration, entre 3 e 20 segundos, 10 por omissão, com a documentação a explicar que uma duração maior lhes permite afinar os resultados e devolver dados mais exatos. É um botão invulgarmente honesto. A precisão custa milissegundos, e ali deixam-no gastá-los.

A Enrow foi pelo caminho oposto. Todos os endpoints são assíncronos. Um POST a /email/find/single devolve de imediato um identificador de pesquisa, e o resultado chega por webhook ou consultando o GET correspondente. A documentação diz que a opção é deliberada: com volumes grandes, quem chama nunca fica bloqueado. Enquanto a pesquisa corre, o GET responde {"qualification": "ongoing"}.

A verificação em si resolve-se em segundos. Só que o processo não fica ali à espera dela, e o código que conta com o endereço dentro da resposta ao POST não o encontra lá.

Qual dos dois serve depende do sítio em que a pesquisa está. Num formulário, com uma pessoa a olhar para o ecrã, uma chamada síncrona de três segundos não incomoda ninguém. Num trabalho noturno sobre 40 000 linhas, uma chamada que bloqueia é um problema à espera de acontecer. O RFC 9110 §15.3.3 trata do segundo caso: um 202 Accepted quer dizer aceite para processamento que ainda não terminou.

O que ninguém publica é um p95. Nem a Enrow, nem os fornecedores acima. O marketing diz «em segundos» e não há quem se comprometa com um percentil. Meça-o no seu próprio volume antes de desenhar o que quer que seja em cima de um número tirado de uma página comercial.

3. O que a resposta lhe diz de facto

É aqui que o mercado se divide em duas escolas, e escolher a errada custa semanas de engenharia.

A primeira escola entrega-lhe a incerteza. O Email Finder do Hunter devolve um score de 0 a 100, um booleano accept_all, um objeto verification com o estado em valid, accept_all ou unknown, e até vinte entradas em sources com a página de onde veio cada menção e as datas extracted_on e last_seen_on. A documentação deles é franca quanto ao score num domínio accept-all: estima a probabilidade de o endereço ser válido. O ZeroBounce faz o mesmo numa escala mais grosseira, com email_confidence em HIGH, MEDIUM ou LOW e um de nove valores em failure_reason.

Serve a quem está a construir a sua própria camada de pontuação. O array sources é uma ferramenta forense a sério.

A segunda escola resolve a questão e entrega um veredicto. A pesquisa da Enrow devolve qualification em valid ou invalid, com ongoing enquanto a pesquisa corre. A documentação di-lo sem rodeios: resultados binários, sem categorias probabilísticas. Ao lado, o email, um bloco info com o domínio e o nome da empresa, o nome próprio e o apelido, e o objeto custom que foi enviado no pedido.

A pergunta a fazer não é qual das respostas é mais rica. É saber quem fica com o limiar nas mãos. Se a API devolve 0-100 e accept_all: true, o limiar é seu para sempre — e cada comercial que se queixa de um bounce está a queixar-se de um número que foi o leitor a escolher. Se a API devolve valid ou invalid, o limiar é do fornecedor, e é a ele que se pedem contas.

O objeto custom elimina uma família inteira de código de cola. O que lá puser, por pedido e por linha em lote, chega intacto na resposta do GET e no webhook. Identificador interno do contacto, etiqueta de campanha, ID do registo no CRM, aquilo por que o seu processo se guiar. Sem tabela de reconciliação.

4. Domínios catch-all: resolvidos, ou deixados nas suas mãos

Um domínio accept-all responde que sim a todos os endereços que lhe sondarem. Caixa real, gralha, disparate completo — tudo aceite. Não é falha de fornecedor nenhum, está no protocolo. O RFC 5321 §3.5.3 antecipa-o: há circunstâncias em que um endereço parece válido mas não pode ser razoavelmente verificado em tempo real, e o servidor deve então devolver um 252. E o §3.3 nota que alguns servidores só verificam o destinatário quando chega o corpo da mensagem, ou seja, um endereço aceite ainda pode fazer bounce mais tarde.

Uma sondagem SMTP não resolve isto. É um facto do protocolo, não uma lacuna de ferramentas.

A maior parte das APIs passa-lhe a ambiguidade para a frente. O verificador do Hunter devolve accept_all, e a documentação deles avisa que, quando o servidor SMTP aceita tudo, as verificações SMTP podem dar falsos positivos. É honesto, e deixa um monte de linhas que ninguém quer assumir.

Não deite fora esse monte. As listas B2B pendem justamente para as empresas com mais probabilidade de correr accept-all, e apagar tudo o que traz a etiqueta manda para o lixo decisores vivos ao lado das linhas mortas.

A Enrow resolve os catch-all de forma determinista em vez de os etiquetar: várias passagens SMTP a partir de servidores em regiões diferentes, cruzadas com endereços de controlo deliberadamente falsos no mesmo domínio, dentro das mais de 10 verificações que estão por trás de cada resultado. Um catch-all resolvido sai como valid e é cobrado como encontrado. O que não se consegue resolver sai como invalid e não custa nada. A verificação dos catch-all está no preço do crédito, não é um extra à parte. O bounce observado fica abaixo de 1% — média de envios reais, não uma garantia. A mecânica está em o que é um email catch-all; os estragos a jusante, na taxa de bounce.

Endpoints de pesquisa em massa e limites de pedidos

A volume, manda o tamanho do lote, não o limite por segundo: dez pedidos contra uns 83 minutos de POST.

Um email finder em massa é um endpoint que aceita uma lista inteira de contactos num só pedido e devolve os endereços verificados como um trabalho em lote, em vez de uma chamada HTTP por pessoa. É a diferença entre um processo que fecha de um dia para o outro e um que não fecha.

Os limites por lote e os limites de pedidos variam muito, e cruzam-se um com o outro.

Faça as contas a um trabalho de 50 000 linhas. Em modo individual, com um limite de 10 pedidos por segundo, são 5 000 segundos só a submeter — uns 83 minutos de POST antes sequer de ir buscar resultados. O mesmo trabalho em lote são dez pedidos. Com os 60 por minuto documentados no Snov, o modo individual dá uma janela de catorze horas.

A volume, portanto, o tamanho do lote pesa mais do que o número por segundo. O limite da Enrow são 10 POST por segundo por chave de API, sem variações, com os GET fora da contagem e um aumento disponível a pedido através de api@enrow.io. Acima disso não há número publicado, logo não desenhe nada a contar com um.

Repetições, idempotência, e porque é a cobrança que decide a estratégia

O POST não é idempotente. O RFC 9110 §9.2.2 diz que um cliente pode repetir um pedido quando não chega resposta, mas que o pedido deve ser considerado idempotente para efeitos de repetição — e um POST de pesquisa não o é. Um tempo esgotado que se repete é um segundo evento a pagar, a não ser que o fornecedor o deduplique.

O cabeçalho a que toda a gente recorre, Idempotency-Key, não é uma norma. É um rascunho do IETF, draft-ietf-httpapi-idempotency-key-header, caducado na revisão 07. O suporte muda de fornecedor para fornecedor e é desigual. O Hunter implementa-o com jeito — TTL de 24 horas, impressão digital do corpo do pedido, quatro códigos de erro distintos —, mas só nos endpoints de sequências e de mensagens. No Email Finder, não.

Quem cobra à tentativa transforma isto num problema a sério. A lógica de repetição passa a ser uma decisão de despesa, e uma política agressiva de repetições numa rede instável duplica a conta do mês sem dar um aviso.

Com cobrança ao resultado válido, o problema quase desaparece. Uma pesquisa repetida que não encontra nada não custa nada, o que permite ser agressivo nos tempos limite sem estar de olho na conta. Quase — e não de todo: uma repetição que encontra o mesmo endereço continua a ser um resultado encontrado, e a Enrow não publica nenhuma garantia de deduplicação. Guarde o seu próprio registo dos identificadores de pesquisa em curso. Cobrar ao resultado válido torna as repetições baratas, não gratuitas.

Mais duas coisas que a Enrow não lhe dá, ditas às claras porque de outra maneira descobre-as às duas da manhã. Não há cabeçalhos X-RateLimit-*, e um 429 chega como um {"message": "Too Many Requests"} pelado. O RFC 6585 §4 torna o Retry-After opcional e a Enrow não o envia, e a documentação manda construir a espera exponencial para o limite fixo, por conta de quem integra. E o 404 nem sequer consta dos códigos de estado documentados — a lista é 400, 401, 402, 429 e 500 —, o que faz com que um tratamento de erro montado sobre um 404 limpinho, para um identificador de pesquisa desconhecido ou expirado, nunca chegue a disparar.

Pôr isto a funcionar

A autenticação é uma chave de API num cabeçalho x-api-key. Sem fluxo OAuth, sem bearer tokens, e a documentação di-lo por essas mesmas palavras. O URL base é https://api.enrow.io.

Cada POST tem um GET a condizer: /email/find/single, /email/find/bulk, /email/verify/single, /email/verify/bulk, /phone/single, /phone/bulk, mais um GET /account/info que devolve o saldo de créditos que resta, num só número, e os URL de webhook configurados.

Seis eventos de webhook cobrem os endpoints. Os eventos de pesquisa individual trazem o resultado completo, portanto uma integração individual bem feita nunca precisa de andar a consultar o GET. Os eventos de lote limitam-se a avisar que o lote terminou; as linhas e a contabilidade dos créditos vêm do GET correspondente. O URL do webhook define-se globalmente na página de integrações ou pedido a pedido em settings.webhook, só em HTTPS, e tem de responder 200.

Erros que vale a pena tratar: 401 para chave errada, 402 para créditos insuficientes, 429 para o limite de pedidos. Atenção ao 402 — responde {reason, success} nos endpoints individuais e a forma simples {message} nos de lote, o que parte qualquer analisador de erros partilhado. Já existem SDK oficiais, em sete linguagens: JS/TypeScript, Python, PHP, Go, Java, Swift e Rust, segundo docs.enrow.io/sdks/overview a 29 de agosto de 2026. Os sete estão em acesso antecipado e instalam-se a partir do código no GitHub, e não de um repositório de pacotes, ou seja, fixa-se um commit à mão e os exemplos em curl e em JavaScript da documentação continuam a ser a saída de recurso. A especificação completa está na página da API da Enrow; uma chave demora uns trinta segundos e não passa por nenhuma chamada comercial.

Se quem chama é um agente de IA e não um serviço, há um servidor MCP oficial: repositório EnrowAPI/enrow-mcp no GitHub, licença MIT, instalado por npm ou executado com npx. Expõe a pesquisa de emails, a verificação e a procura de telefone como ferramentas — find_email, find_emails_bulk, verify_email, find_phone e as contrapartes que vão buscar os resultados —, com o Claude Desktop, o Cursor e o Windsurf documentados como clientes. Um assistente resolve um contacto a meio de uma conversa, sem uma linha de código de integração.

A extensão Chrome de email finder: o caminho sem código

Muita da gente que precisa destes dados nunca vai abrir um terminal. Para essas pessoas, a superfície certa é uma extensão Chrome de email finder, e não uma API.

A extensão da Enrow trabalha a partir de um perfil do LinkedIn ou do Sales Navigator. Um clique escreve o registo completo no HubSpot, no Salesforce ou no Pipedrive: nome, email verificado, telemóvel direto, empresa, URL do LinkedIn. Não é um endereço copiado e colado num campo, é a ficha de contacto inteira. A cobrança acompanha a da API: um crédito por email verificado, 40 por telemóvel verificado, nada quando não há resultado.

O RevOps constrói a linha de produção; os comerciais trabalham perfil a perfil. O mesmo saldo de créditos, a mesma verificação, duas superfícies. Mais sobre isso no guia de encontrar emails no LinkedIn e na página do enriquecimento de dados no HubSpot.

O que esta API não faz por si

Não há base de dados consultável. Peça à Enrow «todos os CTO de Berlim em empresas com mais de 200 pessoas» e não sai nada, porque não existe lista nenhuma para interrogar. A pesquisa de email precisa de um nome completo e do domínio ou do nome da empresa. A de telefone precisa de um URL do LinkedIn.

É uma troca deliberada, e a razão é esta. Os fornecedores de base de dados atualizam em ciclos que se contam em meses, ou seja, uma parte apreciável do que vendem descreve pessoas que já mudaram de emprego. A Enrow resolve no momento do pedido, e é daí que vem a precisão que se aguenta. O que isso custa é passar a construção da lista para o seu lado. Faça a lista no LinkedIn ou no Sales Navigator e depois entregue-a à API. As sequências de envio ficam para a Emelia, a La Growth Machine ou o lemlist.

Quanto custa cada contacto válido

Como só se cobra o resultado encontrado, o preço de tabela e o custo real são o mesmo número. O Start são 15 €/mês por 1 000 créditos, ou seja 0,015 € por email válido. O Pro, 75 €/mês por 10 000: 0,0075 €. O Scale, 360 €/mês por 50 000, e a grelha mensal sobe até aos 200 000 créditos por 1 250 €/mês. Passe esse escalão de topo para anual e o email fica nos 0,0056 €, a tarifa mais baixa da tabela. Um telemóvel direto custa 40 créditos, 0,30 € no Pro. A verificação, 0,25 crédito por controlo, esteja o endereço vivo ou morto.

Compare isso com quem cobra à tentativa para o mesmo volume mensal e na mesma base de cobrança, e não preço de tabela contra preço de tabela. Uma ferramenta a 0,02 € por pesquisa tentada, com uma taxa de descoberta de 30%, está a custar 0,067 € por contacto encontrado, e ainda antes de contar os que fazem bounce. É esse o único número que vale a pena pôr numa folha de cálculo.

Não há custo por utilizador, o Pro e o Scale não limitam o número de pessoas na equipa, e os créditos transitam de mês para mês até 3× o plano no Pro e 6× no Scale. O plano gratuito são 50 créditos todos os meses, recorrentes, sem cartão.

FAQ

Uma pesquisa falhada gasta um crédito?

Depende do fornecedor, e é a primeira coisa a verificar. A Enrow, o Anymail Finder e o Findymail dizem todos que os endpoints de pesquisa só cobram o resultado encontrado; o ZeroBounce não cobra nada quando o resultado é «unknown». As ferramentas à tentativa cobram a pergunta. Assuma uma taxa de descoberta de 30% numa lista B2B fria e o custo real por contacto passa a mais do triplo, o que pesa muito mais do que qualquer diferença de preço anunciada.

Existe alguma API de email finder gratuita?

Planos gratuitos existem; APIs gratuitas para sempre e a volume, em regra não, porque cada pesquisa custa ao fornecedor trabalho SMTP real. A Enrow dá 50 créditos todos os meses, recorrentes e sem cartão: 50 emails verificados ou 200 verificações, por tempo indeterminado. Chega para construir e testar uma integração.

Com que rapidez deve responder uma API de email finder?

Uma pesquisa síncrona que demore mais do que uns cinco segundos cria problemas em qualquer coisa que tenha um utilizador à frente. O Hunter deixa afinar isso com o parâmetro max_duration, entre 3 e 20 segundos, e diz que mais tempo significa mais exatidão. Em trabalho de lote, o que conta é o débito, e a latência por linha é irrelevante. Ninguém publica um p95, portanto meça-o por sua conta.

Dá para usar uma API de email finder em massa?

Dá, e acima de umas centenas de linhas convém. A Enrow aceita até 5 000 contactos por lote de pesquisa de email e 3 000 por lote de telefone, com os resultados a chegar por webhook ou por GET. A API v2 do Hunter não tem endpoint de pesquisa em massa, portanto ali as corridas em massa são funcionalidade do painel de controlo. Confirme que o endpoint existe antes de desenhar a arquitetura à volta dele.

É seguro repetir uma pesquisa que esgotou o tempo?

Tecnicamente é, mas faça-lhe as contas primeiro. O POST não é idempotente segundo o RFC 9110, e o Idempotency-Key é um rascunho do IETF caducado, com suporte desigual entre fornecedores, logo uma repetição costuma ser um segundo evento a pagar. Com cobrança ao resultado válido, uma repetição que não encontra nada sai a zero, o que torna comportáveis os tempos limite agressivos. Ainda assim, guarde o registo dos identificadores de pesquisa em curso.

Posso enriquecer legalmente contactos que não fui eu a recolher?

Na União Europeia isto assenta no artigo 6.º, n.º 1, alínea f) do RGPD, o interesse legítimo, com o dever do artigo 14.º de informar a pessoa de que tem dados dela e a dispensa do artigo 14.º, n.º 5, alínea b) quando essa informação exigir um esforço desproporcionado. A prospeção B2B costuma caber aí, mas a avaliação cabe a quem enriquece e tem de ficar documentada — com um advogado, não com um artigo de blogue. A Enrow tem a documentação legal dos telemóveis diretos europeus.

Passe os quatro critérios pela sua própria lista. A API da Enrow dá uma chave em uns trinta segundos, e o plano gratuito são 50 créditos todos os meses, sem cartão.