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 fatura, quase nenhum as publica.

O essencial Uma API de email finder recebe os dados de uma pessoa que já identificou (em regra, um nome e uma empresa) e entrega 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 fatura ao fim do mês e a arquitetura à volta da API: cobra-se a tentativa ou o resultado verificado, quanto demora uma pesquisa e se bloqueia o processo, a que se compromete a resposta que chega, e se um domínio catch-all sai resolvido ou fica a seu cargo. Há uma quinta pergunta, que só surge com 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 quando há resultado válido, todos os endpoints são assíncronos, os catch-all são verificados em vez de etiquetados, o limite é de 10 pedidos por segundo nos POST e os lotes vão até 5 000 linhas. Leia a linha da cobrança antes da lista de funcionalidades. Pesa 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. Recebe-se um endereço e, com ele, alguma indicação sobre se existe mesmo.

Antes de mais, um esclarecimento, porque quem procura «email API» encontra sobretudo outra coisa: fornecedores de envio e serviços de email transacional. Esses despacham mensagens. Uma API de email finder transforma uma identidade num endereço antes de haver qualquer mensagem.

Os quatro critérios que se seguem resultam de termos construído uma destas APIs e de, pelo caminho, termos lido 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 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ó a partir de volumes a sério; por isso tem uma secção própria, a seguir.

1. Cobra-se a tentativa ou o resultado verificado

Quando se pagam as falhas, cada contacto encontrado custa 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 omite.

Há dois modelos. À tentativa: paga-se por cada pedido. O fornecedor faz o trabalho, não encontra nada de útil e cobra o crédito na mesma. Ao resultado válido: uma falha não custa nada, e só se debita crédito quando sai um endereço que recebe mesmo correio.

A diferença não é coisa de arredondamentos. A maioria dos fornecedores nem sequer publica uma taxa de cobertura, por isso parto de 30% como hipótese de trabalho numa lista B2B fria. Com 30%, quem cobra à tentativa cobra mais do triplo por cada contacto que acaba por ter na mão. Depois, uma parte do que foi encontrado gera bounces, e também isso 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 as pesquisas bem-sucedidas, mas não cobra nada quando o resultado é «unknown».

Os endpoints de pesquisa da Enrow funcionam desta maneira, e a resposta em lote permite auditar a contabilidade. 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 por cada linha sem resultado. O exemplo da documentação submete 3 linhas, encontra 2 e termina com {initial: 3, refunded: 1, final: 2}. Dá para conferir um mês de despesa com as linhas encontradas sem abrir um pedido ao apoio ao cliente.

Uma ressalva, porque aqui é ao contrário. O Email Verifier da Enrow cobra por verificação feita, 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 cobra-se ao resultado válido; verificar, à verificação feita. Convém saber isto antes de mandar um trabalho de limpeza pelo endpoint errado.

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

Há duas filosofias de conceção, e nenhuma está errada.

Algumas APIs respondem de forma síncrona. O Anymail Finder diz que a maior parte das pesquisas individuais obtém resposta em cerca de três segundos. O Hunter transformou o equilíbrio entre rapidez e precisão 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 entregar dados mais exatos. É um parâmetro invulgarmente honesto. A precisão custa milissegundos, e ali é você que decide quantos gastar.

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 por consulta do GET correspondente. A documentação diz que a opção é deliberada: com volumes grandes, quem chama nunca fica bloqueado. Enquanto a pesquisa está em curso, 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 convém depende do contexto da pesquisa. 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 anunciado. O RFC 9110 §15.3.3 trata do segundo caso: um 202 Accepted significa que o pedido foi aceite para um 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 construir o que quer que seja com base num 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 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 com o valor valid ou invalid, e ongoing enquanto a pesquisa está em curso. A documentação di-lo sem rodeios: resultados binários, sem categorias probabilísticas. Junto vêm 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 fica a seu cargo para sempre, e cada comercial que se queixa de um bounce está a queixar-se de um número que foi você a escolher. Se a API devolve valid ou invalid, o limiar é do fornecedor, e é a ele que se pedem contas.

O objeto custom elimina toda uma categoria de código intermédio. O que lá puser, por pedido e por linha em lote, chega intacto na resposta do GET e no webhook. Pode ser o identificador interno do contacto, uma etiqueta de campanha, o ID do registo no CRM, aquilo por que o seu processo se guiar. Dispensa tabelas de correspondência.

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

Um domínio accept-all diz que sim a qualquer endereço que se lhe teste. Caixa real, gralha, disparate completo: tudo é aceite. Não é falha de fornecedor nenhum, está no protocolo. O RFC 5321 §3.5.3 prevê-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 pode ainda gerar um 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 funcionar em accept-all, e apagar tudo o que traz a etiqueta manda para o lixo decisores reais juntamente com as 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á incluída no preço do crédito; não é um extra. A taxa de bounce observada fica abaixo de 1%: é uma média de envios reais, não uma garantia. O mecanismo está explicado no artigo sobre o que é um email catch-all, e os estragos a jusante, no artigo sobre a taxa de bounce.

Endpoints de pesquisa em massa e limites de pedidos

Com volume, o que manda é o tamanho do lote, não o limite por segundo: dez pedidos face a uns 83 minutos de POST.

Um email finder em massa é um endpoint que aceita uma lista inteira de contactos num só pedido e entrega os endereços verificados como um trabalho em lote, em vez de uma chamada HTTP por pessoa. É a diferença entre um processo que termina durante a noite e um que nunca termina.

Os limites por lote e os limites de pedidos variam muito, e interagem entre si.

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ó para submeter, ou seja, uns 83 minutos de POST antes sequer de ir buscar resultados. Em lote, o mesmo trabalho resume-se a dez pedidos. Com os 60 por minuto documentados no Snov, o modo individual exige uma janela de catorze horas.

Com volume, portanto, o tamanho do lote pesa mais do que o limite por segundo. O limite da Enrow é fixo: 10 POST por segundo por chave de API, com os GET fora da contagem e possibilidade de aumento a pedido, através de api@enrow.io. Acima disso não há número publicado, por isso não conte com nenhum ao desenhar a arquitetura.

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 só se o pedido for idempotente, e um POST de pesquisa não o é. Um pedido que esgotou o tempo e é repetido conta como 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, que caducou na revisão 07. O suporte varia muito de fornecedor para fornecedor. O Hunter implementa-o bem (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, e não no Email Finder.

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 aviso nenhum.

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, mas não de todo: uma repetição que encontra o mesmo endereço continua a contar como 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 outro modo, só as descobriria às duas da manhã. Não há cabeçalhos X-RateLimit-*, e um 429 chega como um simples {"message": "Too Many Requests"}. O RFC 6585 §4 torna o Retry-After opcional, a Enrow não o envia, e a documentação deixa a quem integra a tarefa de implementar uma espera exponencial face ao limite fixo. 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 erros que conte com um 404 limpo 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. Não há fluxo OAuth nem bearer tokens, e a documentação di-lo com todas as letras. O URL base é https://api.enrow.io.

Cada POST tem o GET correspondente: /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; tem de ser HTTPS e responder com 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, que traz {reason, success} nos endpoints individuais e a forma simples {message} nos de lote, o que quebra 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, consultado 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, é preciso fixar um commit à mão, e os exemplos em curl e em JavaScript da documentação continuam a ser a alternativa de recurso. A especificação completa está na página da API da Enrow; obter uma chave demora uns trinta segundos e não exige 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, que se instala por npm ou se executa com npx. Disponibiliza 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 ferramentas correspondentes que vão buscar os resultados), com o Claude Desktop, o Cursor e o Windsurf documentados como clientes. Um assistente encontra 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

Muitas das pessoas que precisam destes dados nunca vão abrir um terminal. Para elas, a ferramenta 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. Com um clique, grava a ficha completa 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 segue a da API: um crédito por email verificado, 40 por telemóvel verificado, nada quando não há resultado.

A equipa de RevOps monta o processo automatizado; os comerciais trabalham perfil a perfil. O mesmo saldo de créditos, a mesma verificação, duas interfaces. Há 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 onde procurar. 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 opção 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 faz a pesquisa no momento do pedido, e é daí que vem uma precisão que não se degrada. 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 custa 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 custa 0,25 crédito por endereço verificado, esteja ele ativo 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 com preço de tabela. Uma ferramenta a 0,02 € por pesquisa tentada, com uma taxa de cobertura de 30%, está a custar 0,067 € por contacto encontrado, e isto antes de contar os que geram 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 dá 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 que cobram à tentativa cobram o pedido. Assuma uma taxa de cobertura 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, aí, o processamento em massa é uma 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 primeiro as contas. 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 não custa nada, 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 enquadrar-se aí, mas a avaliação compete a quem enriquece e tem de ficar documentada, com um advogado e não com um artigo de blogue. A Enrow tem a documentação legal dos telemóveis diretos europeus.

Aplique os quatro critérios à sua própria lista. A API da Enrow dá-lhe uma chave em cerca de trinta segundos, e o plano gratuito dá 50 créditos todos os meses, sem cartão.