Como verificar e-mails com o Make (Integromat)

Você já pode verificar e-mails com o Make (antigo Integromat) hoje, mesmo que ainda não exista um módulo da Qualisend com a marca no app. O padrão é montar um cenário em torno do módulo genérico HTTP: um gatilho dispara quando um novo endereço chega, uma requisição HTTP envia esse endereço via POST para a API da Qualisend, e um Router ou Filter lê o veredito e bifurca o fluxo — de modo que apenas endereços deliverable seguem para o seu ESP ou CRM, enquanto os risky ou undeliverable ficam estacionados. Este guia monta esse cenário do início ao fim.

A resposta curta#

Não há um app nativo para instalar no momento (está no roadmap), então o padrão suportado é um cenário em três partes: um gatilho (novo envio de formulário, nova linha, ou um webhook personalizado para o qual você aponta um formulário), um módulo HTTP → Make a request que chama a API de verificação com o e-mail, e um Router com filtros por rota que leem o status retornado e decidem o que acontece em seguida. Mantenha sua chave de API nos cabeçalhos do módulo — nunca em um campo público de formulário — e configure o módulo HTTP para continuar rodando caso a API venha a dar erro, de modo que um soluço passageiro nunca descarte um lead real.

Duas formas de verificar e-mails com o Make#

Antes de conectar qualquer coisa, escolha o padrão que corresponde a quão fresca a informação precisa estar:

1. Em tempo real, por envio (um cenário). Cada novo endereço é verificado no momento em que chega e roteado na hora. Este é o assunto central deste guia e a escolha certa quando o veredito muda o que acontece em seguida — condicionar um e-mail de double opt-in, etiquetar um lead ou pular um cadastro falso.
2. Em lote, depois do fato (um CSV). Deixe os envios se acumularem em uma planilha ou no seu ESP, exporte-os periodicamente e passe-os por um job de verificação em lote. Mais simples, mais barato por endereço e mais adequado quando você só precisa de uma lista limpa antes de um envio, e não de uma decisão instantânea.

A maioria das equipes acaba fazendo os dois: um cenário na captação ao vivo, mais uma limpeza de lista mensal para pegar endereços que ficaram obsoletos desde que se cadastraram.

Passo 1: o gatilho#

Comece o cenário com o que quer que capture o endereço. O Make tem centenas de módulos de gatilho — "Watch Responses" em um app de formulários, "Watch Rows" no Google Sheets ou no Airtable, "New Lead" em um CRM. Se a sua ferramenta de formulário não tiver um módulo dedicado no Make, coloque um Custom webhook como primeiro módulo e aponte a URL de webhook do seu formulário para ele; o Make gera uma URL única e mostra a estrutura dos dados recebidos assim que o primeiro envio chega.

Qualquer que seja a sua escolha, a saída importante é um campo contendo o endereço de e-mail, que os módulos seguintes referenciam como um token mapeado — o Make os mostra como pílulas coloridas nas quais você clica para inseri-las em um campo, extraídas do pacote de saída do gatilho. Nos exemplos abaixo, esse token é escrito como {{1.email}}, onde 1 é o módulo de gatilho.

Passo 2: envie o endereço via POST com o módulo HTTP#

Adicione um módulo e escolha HTTP → Make a request. Este é o passo que realmente chama a Qualisend. Configure-o assim:

Ative o Parse response para que o Make leia o JSON de volta em campos mapeáveis em vez de uma string bruta. Na caixa Request content, digite o corpo e insira nele a pílula de e-mail do gatilho:

{ "email": "{{1.email}}" }

A requisição que o Make dispara em seu nome fica assim — os espaços reservados 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" }

Use uma chave com escopo criada para este cenário, em vez de uma chave de acesso total, para que, se o histórico de execução do cenário algum dia vazar, a chave só possa verificar, e nada mais. Nunca coloque a chave no próprio formulário nem em qualquer campo do lado do cliente — ela pertence somente aos cabeçalhos do módulo HTTP, que rodam no lado do servidor dentro do Make.

Quando você clica em Run once, o Make mostra o pacote de resposta. Você recebe de volta um objeto result contendo um status, um código 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 a base sobre a qual o próximo passo ramifica, então observe como o Make os mapeia — você vai referenciar result: status, result: score e as sub_flags individuais nos filtros. Para o quadro completo do que cada status significa e de como o pipeline chega a ele, veja como funciona a verificação de e-mail.

Passo 3: ramifique conforme o veredito com um Router#

Um resultado de verificação sobre o qual você não age é crédito desperdiçado. O objetivo é justamente rotear endereços de formas diferentes, e no Make isso é o módulo Router.

Coloque um Router após o módulo HTTP e ele se abre em quantas rotas você precisar. Cada rota recebe seu próprio filtro — clique na chave inglesa na linha que sai do Router — que testa o status já parseado da resposta HTTP:

O Make avalia as rotas da esquerda para a direita e, a menos que você marque uma rota como o fallback (a rota sem filtro), toda rota que corresponde é executada — então mantenha suas condições mutuamente exclusivas no status para evitar que um único endereço desça por dois ramos. Defina o ramo undeliverable/sem correspondência como o fallback, para que nada escape sem ser categorizado.

Você também pode ramificar pelas sub-flags. Se o seu produto for sensível à reputação, adicione uma condição à rota de revisão que também dispare quando sub_flags: disposable for igual a true, mesmo quando o status estiver de resto tudo certo — o mesmo critério sobre endereços disposable, role e free que a análise de role, disposable e free percorre. Um único filtro do Router aceita múltiplas condições AND/OR, então você pode combinar um teste de status e um teste de sub_flags em uma mesma rota.

Não deixe o módulo HTTP bloquear um bom lead#

Uma regra importa mais do que qualquer ramificação: falhe aberto. Se o módulo HTTP der erro — a API está brevemente lenta, um limite do plano foi atingido, uma falha de rede — você não quer que o cenário inteiro pare e engula silenciosamente um cadastro real. Clique com o botão direito no módulo HTTP, escolha Add error handler e anexe uma diretiva Resume que forneça um pacote padrão com status definido como unknown. O cenário então continua rodando por um caminho que trata o endereço como "revisar depois" em vez de descartá-lo. (Você também pode configurar o tratamento de erros do cenário para store incomplete executions, de modo que execuções falhas entrem na fila para nova tentativa em vez de desaparecerem.)

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 resultado muito pior do que deixar passar um endereço questionável e pegá-lo na sua próxima limpeza de lista. O mesmo princípio de falhar aberto sustenta o padrão de verificação serverless no cadastro, em que uma sondagem lenta nunca pode travar o formulário.

Quando um cenário é a ferramenta errada#

O Make é cola, e cola tem um custo: cada endereço verificado queima operações, e uma chamada HTTP por envio pode se acumular em volume ou parecer exagero 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, e não captação nova. Exporte-os e rode um único job em lote.
• Seu volume é alto o suficiente para o preço por operação pesar, e uma limpeza noturna ou semanal já é fresca o bastante.
• Você prefere não manter um cenário ao vivo para uma tarefa que só precisa rodar de vez em quando.

Para os três casos, pule o cenário: exporte os envios para CSV a partir da sua ferramenta de formulário, planilha ou ESP, e faça o upload desse arquivo para o verificador em lote da Qualisend. Você recebe o mesmo status, score e sub-flags por linha, baixável como um arquivo limpo que você pode reimportar. É a forma de menor esforço para manter uma lista saudável e sua taxa de rejeição baixa sem manter nenhuma automação.

Se você está pesando a abordagem via HTTP do Make contra chamar a API diretamente do seu próprio backend, a comparação de APIs expõe os prós e contras — um cenário no Make ganha em rapidez de configuração e não precisa de servidor, enquanto uma integração direta ganha em custo e controle em escala. O mesmo padrão do módulo HTTP também se porta de forma limpa para um fluxo de trabalho n8n auto-hospedado se você superar o preço por operações do Make.

Perguntas frequentes#

Existe um módulo nativo da Qualisend para o Make?#

Agora não. As integrações nativas de plataforma da Qualisend estão sendo reconstruídas, então ainda não há um app com a marca para procurar na lista de módulos do Make — está no roadmap. Até que ele seja lançado, a forma suportada de verificar e-mails com o Make é o módulo genérico HTTP → Make a request apontado para a API da Qualisend, exatamente como este guia descreve. A abordagem via HTTP também é mais flexível: você controla a requisição, os cabeçalhos e a lógica de roteamento.

Quantas operações o cenário consome por e-mail?#

Aproximadamente uma operação por módulo que roda: o gatilho, a requisição HTTP e a rota ativa do Router contam cada um. Então um único envio verificado são algumas operações, e 1.000 envios são alguns milhares — bem dentro da maioria dos planos pagos do Make. Se o seu volume fizer o preço por operação pesar, mude esse tráfego para a rota de exportação em CSV e verificação em lote, que não usa nenhuma operação.

Qual status devo deixar passar para minha ferramenta de e-mail?#

Apenas deliverable para um portão rigoroso. Se você quiser manter mais endereços, permita deliverable mais risky/unknown, mas encaminhe esses para um segmento separado e de menor prioridade, em vez do seu fluxo principal — muitos resultados risky são domínios catch-all que ainda podem entregar. Sempre rejeite undeliverable e considere ramificar também pela sub-flag disposable se o seu produto for sensível à reputação.

Como testo o cenário antes de ativá-lo?#

Use o botão Run once do Make com um endereço sabidamente bom e um sabidamente ruim, e observe o balão no módulo HTTP mostrar o status retornado — depois confirme que cada rota do Router acende para a entrada certa. Para conferências rápidas e pontuais fora do Make, cole um endereço no verificador de e-mail gratuito e compare o veredito com o que o seu cenário retorna.

Pronto para montar? Pegue uma chave com escopo 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 bastam para conectar o cenário inteiro e ver um endereço ruim ser filtrado antes mesmo de chegar à sua lista.