Você pode verificar e-mails com o n8n hoje mesmo, sem esperar por um nó de marca —
o nó genérico HTTP Request do n8n chama a API da Qualisend sem problema
nenhum, e como o n8n é open-source e auto-hospedável, todo o fluxo roda em uma
infraestrutura que você controla, com a chave de API guardada no próprio cofre de
credenciais do n8n. O formato é sempre o mesmo trio de nós: um trigger captura
o endereço, um nó HTTP Request o envia via POST para a Qualisend, e um nó
IF ou Switch lê o status retornado e direciona cada desfecho. Este guia
constrói esse fluxo de trabalho de ponta a ponta.
A resposta curta#
Ainda não existe um nó nativo da Qualisend no n8n (ele está no roadmap), então o
padrão suportado é um fluxo de trabalho com nós genéricos: um trigger (webhook,
formulário, nova linha, agendamento), um nó HTTP Request que envia o e-mail via
POST para a API de verificação com a sua chave em uma credencial armazenada, e um
nó IF ou Switch que ramifica com base em result.status. Mantenha a chave
em uma credencial do n8n — nunca colada diretamente no nó ou em um campo público —
e, por padrão, deixe um endereço passar caso a chamada HTTP dê algum erro, para que
uma falha passageira nunca descarte silenciosamente um cadastro real.
Duas formas de verificar e-mails com o n8n#
Antes de montar qualquer coisa, escolha o padrão que corresponde ao quão recente os dados precisam ser:
- Em tempo real, por registro (um fluxo ao vivo). Cada novo endereço é verificado no momento em que chega e direcionado na hora. Este é o assunto principal deste guia e a escolha certa quando o veredicto muda o que acontece a seguir — barrar um e-mail de boas-vindas, marcar um lead ou pular um cadastro falso.
- Em lote, depois do fato (um CSV). Deixe os registros se acumularem em uma planilha, banco de dados ou CRM, exporte-os periodicamente e passe-os por um job de verificação em massa. Mais simples, mais barato por endereço e uma opção melhor quando você só precisa de uma lista limpa antes de um envio, em vez de uma decisão instantânea.
A maioria das equipes acaba fazendo os dois: um fluxo ao vivo na captação, além de uma limpeza de lista periódica para pegar endereços que ficaram obsoletos desde o cadastro. Se o próprio pipeline de verificação for novo para você, como funciona a verificação de e-mails explica o que a API está de fato fazendo por trás dessa única requisição.
Passo 1: o nó de trigger#
Comece o fluxo de trabalho com aquilo que captura o endereço. O n8n oferece muitas opções, e todas elas alimentam os mesmos nós downstream:
- Um nó Webhook, caso um formulário ou app envie as submissões via POST para uma URL que você controla.
- Um nó n8n Form Trigger, caso você queira que o próprio n8n hospede o formulário de captação.
- Um trigger de app — um nó do Typeform, Google Sheets, Airtable ou HubSpot — que dispara em uma nova submissão ou linha.
- Um nó Schedule Trigger alimentando a leitura de um banco de dados ou planilha, caso você prefira varrer os registros em pequenos lotes em intervalos definidos.
Se o seu trigger for uma ferramenta de formulário específica, o passo a passo por plataforma para verificar e-mails do Typeform se conecta aos mesmos passos de HTTP Request e IF/Switch abaixo — só o nó de trigger muda.
Independentemente do que escolher, a única coisa que importa é que o endereço de
e-mail chegue no JSON do item para que os nós posteriores possam referenciá-lo —
comumente como {{ $json.email }} (ajuste a chave para corresponder à saída do seu
trigger; um payload de Webhook pode expô-lo como {{ $json.body.email }}, e um nó
de formulário sob o rótulo do campo que você definiu). Use o botão Execute step
do n8n no trigger para ver o caminho exato antes de construir o próximo nó.
Passo 2: chame a API da Qualisend com o nó HTTP Request#
Adicione um nó HTTP Request depois do trigger. É esse o nó que de fato chama a Qualisend. Configure-o assim:
| Campo | Valor |
|---|---|
| Method | POST |
| URL | seu endpoint de verificação — ex.: https://api.qualisend.com/v1/verify (confira a referência da API para o caminho exato) |
| Authentication | Generic Credential Type → Header Auth, com uma credencial armazenada contendo Authorization: Bearer YOUR_API_KEY |
| Send Body | On, JSON |
| Body | uma única chave email mapeada para o endereço do trigger |
Defina o corpo JSON usando uma expressão para que o endereço do trigger flua direto:
{ "email": "{{ $json.email }}" }
A requisição que o n8n dispara em seu nome fica então assim — os placeholders são seus para preencher a partir da documentação para desenvolvedores, que lista o endpoint exato e mostra a requisição em várias linguagens:
POST https://api.qualisend.com/v1/verify
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
{ "email": "jane@example.com" }
Crie a chave como uma credencial restrita, apenas de verificação, em vez de uma
chave de acesso total, para que, se o JSON do fluxo de trabalho ou um log algum dia
vazar a referência, ela aponte para uma chave que só pode verificar, nada mais. No
n8n, essa chave pertence a uma credencial Header Auth — o n8n armazena as
credenciais separadamente do fluxo de trabalho e as criptografa em repouso (em
instâncias auto-hospedadas, sob a sua N8N_ENCRYPTION_KEY), de modo que o segredo
nunca aparece nos parâmetros do nó, nos fluxos exportados ou nos logs de execução.
Quando você roda o nó com Execute step, o n8n mostra o corpo da resposta. Sob
result você recebe um status, um código de reason, um score de 0 a 100 e um
conjunto de sub_flags. Um endereço deliverable volta mais ou menos assim:
{
"result": {
"status": "deliverable",
"reason": null,
"score": 95,
"sub_flags": { "disposable": false, "role": false, "free": false, "catch_all": false }
}
}
Esses nomes de campos são aquilo sobre o que o próximo nó ramifica, então observe
que o status fica em {{ $json.result.status }} e um sub-flag em
{{ $json.result.sub_flags.disposable }}. O mesmo padrão de requisição no
servidor sustenta o guia de cadastro serverless
— o n8n está simplesmente hospedando a chamada para você, em vez de uma função que
você mesmo faz o deploy.
Passo 3: ramifique conforme o veredicto com IF ou Switch#
Um resultado de verificação sobre o qual você não age é crédito desperdiçado. O objetivo todo é direcionar os endereços de formas diferentes, e o n8n oferece dois nós para isso.
Opção A — um nó IF (o mais simples). Se tudo o que você quer é "manter apenas os bons endereços", adicione um nó IF depois do HTTP Request. Defina uma condição:
- Value 1:
{{ $json.result.status }}— String — is equal to — Value 2:deliverable
Tudo o que corresponder sai pela saída true rumo aos seus nós downstream
(adicionar ao seu ESP, criar o contato, enviar o e-mail de boas-vindas); tudo o
mais sai pela saída false, onde você pode descartar ou estacionar. Simples, mas
tosco — junta risky, unknown e undeliverable num só balaio, quando muitas
vezes você quer tratá-los de forma diferente.
Opção B — um nó Switch (direcione cada desfecho). Um nó Switch no modo Rules permite que você bifurque em uma ramificação separada por status, cada uma com seus próprios nós de acompanhamento:
Regra sobre o status retornado | O que fazer |
|---|---|
equals deliverable | Adicione o contato ao seu ESP ou CRM e continue o funil. |
equals risky ou unknown | Adicione a uma lista de "precisa de revisão" ou marque-o — não o descarte de imediato. Esse balde inclui domínios catch-all que não podem ser sondados de forma limpa. |
equals undeliverable | Não o adicione em lugar nenhum. Opcionalmente, registre-o em uma planilha para conseguir identificar um campo de formulário quebrado ou uma fonte de tráfego ruim. |
Você também pode ramificar pelos sub-flags. Se o seu produto é sensível à
reputação, adicione uma regra que direcione qualquer endereço em que
{{ $json.result.sub_flags.disposable }} seja true para a ramificação de
revisão, mesmo quando o status estiver, no mais, tudo certo — a mesma chamada sobre
endereços disposable, role e free que
a análise de endereços role, disposable e free
detalha. As regras do Switch são avaliadas de cima para baixo, então coloque a sua
ramificação mais rigorosa primeiro e conecte uma saída de fallback para
qualquer caso não correspondido.
Não deixe a chamada da API descartar um bom lead#
Uma regra importa mais do que qualquer ramificação: fail open. Se o nó HTTP
Request der erro — a API está momentaneamente lenta, um limite de plano foi
atingido, uma falha de rede — você não quer que a execução inteira pare e engula
silenciosamente um cadastro real. Abra a aba Settings do nó HTTP Request e
defina On Error como Continue (using error output), e depois trate um
endereço sem veredicto como unknown: mantenha-o, direcione-o para revisão e
verifique-o novamente mais tarde, em vez de descartá-lo.
Uma API de verificação é um filtro de qualidade, não um portão de autenticação. Bloquear um cliente pagante por causa de uma indisponibilidade passageira é um desfecho muito pior do que deixar passar um endereço questionável e pegá-lo na sua próxima limpeza de lista. Como você pode estar auto-hospedando, também vale dar ao nó um timeout sensato (alguns segundos) e um retry ou dois, para que uma única sondagem lenta não trave uma fila de fluxos de trabalho movimentada.
A alternativa em lote: verificar uma exportação em CSV#
O n8n é cola, e cola tem um custo: cada endereço verificado é uma execução, e uma chamada HTTP por registro pode parecer exagero — ou somar bastante — quando você não precisa de uma decisão instantânea. Recorra à rota em lote quando:
- Você está limpando uma lista que já existe — milhares de contatos históricos, não uma captação nova. Exporte-os e rode um único job em massa.
- Seu volume é alto o suficiente para o overhead por execução incomodar, e uma limpeza noturna ou semanal é recente o bastante.
- Você prefere não manter um fluxo de trabalho ao vivo rodando para uma limpeza pontual.
Para os três casos, pule o fluxo de trabalho: exporte os registros para CSV do seu
banco de dados, planilha ou CRM, e faça o upload desse arquivo para o
verificador em massa da Qualisend. Você recebe o
mesmo status, score e sub-flags por linha, disponíveis para download como um
arquivo limpo que você pode reimportar. É a maneira de menor esforço para manter uma
lista saudável e a sua taxa de bounce baixa sem
manter nenhuma automação — e você pode até rodar essa exportação-e-verificação como
seu próprio fluxo de trabalho agendado no n8n.
Se você está pesando o nó HTTP do n8n contra chamar a API diretamente do seu próprio backend, a comparação de APIs apresenta os trade-offs — o n8n ganha em rapidez de configuração e roteamento visual, uma integração direta ganha em custo e controle em escala. Se você prefere não auto-hospedar, o mesmo padrão de três passos funciona no Zapier.
Perguntas frequentes#
Existe um nó nativo da Qualisend para o n8n?#
Ainda não. As integrações nativas de plataforma da Qualisend estão sendo reconstruídas, então ainda não há um nó dedicado para procurar no n8n — ele está no roadmap. Até que seja lançado, a forma suportada de verificar e-mails com o n8n é o nó genérico HTTP Request apontado para a API da Qualisend, exatamente como este guia descreve. A abordagem com o nó HTTP também é mais flexível: você controla a requisição, a credencial armazenada, o timeout e a lógica de ramificação.
Onde o n8n guarda minha chave de API da Qualisend?#
No cofre de credenciais do n8n, não no fluxo de trabalho. Crie uma credencial
Header Auth contendo Authorization: Bearer YOUR_API_KEY e faça referência a ela
a partir do nó HTTP Request. O n8n mantém as credenciais separadas das definições de
fluxo de trabalho e as criptografa em repouso — em uma instância auto-hospedada, sob
a sua N8N_ENCRYPTION_KEY — de modo que o segredo nunca aparece nos parâmetros do
nó, no JSON exportado do fluxo ou nos logs de execução. Use uma chave restrita,
apenas de verificação, para que uma referência vazada não possa fazer nada além de
verificar.
Qual status devo deixar passar para a minha ferramenta de e-mail?#
Apenas deliverable, para um filtro rigoroso. Se quiser manter mais endereços,
permita deliverable além de risky/unknown, mas direcione esses para um
segmento separado, de menor prioridade, em vez do seu fluxo principal — muitos
resultados risky são domínios catch-all que
ainda podem entregar. Rejeite sempre os undeliverable e considere também ramificar
pelo sub-flag disposable, caso o seu produto seja sensível à reputação.
Como testo o fluxo de trabalho antes de ativá-lo?#
Use o Execute step do n8n no nó HTTP Request com um endereço reconhecidamente
bom e um reconhecidamente ruim, e confirme que {{ $json.result.status }} muda como
esperado — depois verifique se o seu nó IF ou Switch direciona cada um para a
ramificação correta. Para conferências pontuais e rápidas fora do n8n, cole um
endereço no verificador de e-mail gratuito e compare o
veredicto com o que o seu fluxo retorna.
Pronto para construir? Pegue uma chave restrita e o formato exato da requisição na documentação para desenvolvedores, verifique qualquer endereço no verificador de e-mail gratuito e comece no plano gratuito — 100 créditos são suficientes para montar o fluxo de trabalho inteiro e ver um endereço ruim ser filtrado antes mesmo de chegar à sua lista.