Você já pode verificar e-mails com o Zapier hoje, mesmo que ainda não exista um app nativo da Qualisend no Zapier. O truque é parar de procurar um conector de marca e usar a ação genérica Webhooks by Zapier: seu formulário ou CRM dispara um gatilho, o Zapier envia um POST do novo endereço para a API da Qualisend, e uma etapa de Filter ou Paths ramifica conforme o veredicto — de modo que apenas endereços deliverable sigam para a sua ferramenta de e-mail e os arriscados fiquem reservados para revisão. Este guia constrói esse Zap do começo ao fim.
A resposta curta#
Não há um app nativo para instalar agora (está no roadmap), então o padrão suportado
é um Zap de três etapas: um gatilho (novo envio de formulário, novo lead, nova
linha), uma ação Webhooks by Zapier → Custom Request (POST) que chama a API de
verificação com o e-mail, e uma etapa de Filter ou Paths que lê o status
retornado e decide o que acontece em seguida. Mantenha sua chave de API nos headers
do webhook — nunca em um formulário público — e, por padrão, deixe um endereço passar
caso o webhook apresente algum erro, para que uma falha momentânea nunca descarte um
lead real.
Duas maneiras de verificar e-mails com o Zapier#
Antes de montar qualquer coisa, escolha o padrão que corresponde ao quão atualizados os dados precisam estar:
- Em tempo real, por envio (um Zap). 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 em seguida — barrar um e-mail de double opt-in, marcar um lead ou pular um cadastro falso.
- 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 trabalho 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 disparo, em vez de uma decisão instantânea.
A maioria das equipes acaba fazendo os dois: um Zap na captação ao vivo, mais uma limpeza de lista mensal para pegar endereços que ficaram obsoletos desde o cadastro.
Etapa 1: o gatilho#
Inicie o Zap com o que quer que capture o endereço. O Zapier tem gatilhos nativos
para a maioria das ferramentas de formulário e CRM — "New Submission" em um app de
formulário, "New Lead" em um CRM, "New Spreadsheet Row" no Google Sheets. Escolha o
que escolher, a saída importante é um campo que contenha o endereço de e-mail, ao qual
as etapas seguintes fazem referência como um token de mesclagem, algo como
{{1.email}}.
Exatamente a mesma ação de webhook funciona não importa o que a dispare, então o padrão deste guia é idêntico quer você esteja conectando o Typeform, um CRM ou uma planilha — veja verificar e-mails do Typeform para um passo a passo específico de gatilho que depois passa o bastão para as etapas abaixo.
Etapa 2: envie o endereço com o Webhooks by Zapier#
Adicione uma etapa de ação e escolha Webhooks by Zapier, depois o evento Custom Request. É esta a etapa que de fato chama a Qualisend. Configure-a assim:
| Campo | Valor |
|---|---|
| Method | POST |
| URL | seu endpoint de verificação — por exemplo https://api.qualisend.com/v1/verify (consulte a referência da API para o caminho exato) |
| Data Pass-Through? | No |
| Data | corpo JSON com uma única chave email mapeada para o campo de e-mail do gatilho |
| Headers | Authorization: Bearer YOUR_API_KEY e Content-Type: application/json |
Na caixa Data, o Zapier permite que você digite JSON puro e insira nele o token de e-mail do gatilho. O corpo que você está enviando é apenas:
{ "email": "{{1.email}}" }
E a requisição que o Zapier dispara em seu nome fica 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" }
Use uma chave com escopo criada especificamente para este Zap, em vez de uma chave de acesso total, para que, se o histórico do Zap algum dia vazar, a chave só possa verificar, nada mais. Nunca coloque a chave no próprio formulário nem em qualquer campo do lado do cliente — ela pertence apenas aos headers do webhook, que rodam no lado do servidor dentro do Zapier.
Quando você clica em Test action, o Zapier mostra o corpo da resposta. Você receberá
de volta um status, um código de reason, um score de 0 a 100 e um conjunto de
sub_flags. Um endereço deliverable volta parecido com isto:
{
"status": "deliverable",
"reason": null,
"score": 95,
"sub_flags": { "disposable": false, "role": false, "free": false, "catch_all": false }
}
Esses nomes de campo são o que a próxima etapa usa para ramificar, então observe como o
Zapier os rotula — geralmente ele os achata em tokens como status e sub_flags catch_all.
Para entender por completo o que cada status significa e como o pipeline chega a ele,
veja como funciona a verificação de e-mails.
Etapa 3: ramifique conforme o veredicto#
Um resultado de verificação em que você não age é crédito desperdiçado. O objetivo todo é direcionar endereços de formas diferentes, e o Zapier lhe dá duas ferramentas para isso.
Opção A — um Filter (o mais simples). Se tudo o que você quer é "manter apenas os bons endereços", adicione uma etapa Filter by Zapier depois do webhook. Defina a condição como:
- Status (texto) exactly matches
deliverable
Qualquer coisa que não seja deliverable interrompe o Zap ali mesmo, de modo que apenas
endereços confirmados cheguem à sua ação seguinte (adicionar ao ESP, criar o contato,
enviar o e-mail de boas-vindas). Simples, mas grosseiro — trata risky, unknown e
undeliverable da mesma forma, quando muitas vezes você quer tratá-los de modo diferente.
Opção B — Paths (direcione cada desfecho). O Paths by Zapier — disponível nos planos pagos do Zapier — permite que você se divida em ramificações separadas, cada uma com sua própria condição e suas próprias ações de acompanhamento:
| Condição da Path | O que fazer |
|---|---|
Status é deliverable | Adicione o contato ao seu ESP ou CRM e continue o funil. |
Status é risky ou unknown | Adicione a uma lista de "revisar" ou marque com uma tag — não descarte de vez. Esse grupo inclui domínios catch-all que não podem ser sondados de forma limpa. |
Status é undeliverable | Não adicione a lugar nenhum. Opcionalmente, registre em uma planilha para conseguir identificar um campo de formulário quebrado ou uma fonte de tráfego ruim. |
Você também pode ramificar pelas sub-flags. Se o seu produto é sensível a reputação,
adicione uma condição que direcione qualquer endereço em que sub_flags disposable
seja true para a ramificação de revisão, mesmo quando o status esteja, de resto, bom
— o mesmo critério para endereços disposable, role e free que
a análise de endereços role, disposable e free detalha.
As Paths são avaliadas de cima para baixo, então coloque sua ramificação mais rigorosa
primeiro.
Não deixe o webhook barrar um bom lead#
Uma regra importa mais do que qualquer ramificação: falhe em aberto (fail open). Se
a etapa do webhook der erro — a API está brevemente lenta, um limite de plano é atingido,
uma oscilação de rede — você não quer que o Zap inteiro morra e engula silenciosamente
um cadastro real. No Zapier, abra as configurações da ação do webhook e ative
"Continue on error" (às vezes exibido como uma opção de replay automático /
tratamento de erros no seu plano). Depois adicione um fallback para que um endereço sem
veredicto seja tratado como unknown e mantido para revisão posterior, em vez de
descartado.
Uma API de verificação é um filtro de qualidade, não uma barreira de autenticação. Bloquear um cliente pagante por causa de uma interrupção passageira é um desfecho bem 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 em aberto sustenta o padrão de cadastro serverless, em que uma sondagem lenta jamais pode travar o formulário.
Quando um Zap é a ferramenta errada#
O Zapier é cola, e cola tem um custo: cada endereço verificado é uma tarefa, e um webhook por envio pode ficar caro 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, não captação nova. Exporte-os e rode um único trabalho em lote.
- Seu volume é alto o suficiente para que a cobrança por tarefa incomode, e uma limpeza noturna ou semanal é atualizada o bastante.
- Você está no plano gratuito do Zapier e não pode usar o app premium Webhooks.
Para os três, pule o Zap: 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ê obtém o mesmo status, score e sub-flags por linha, baixável como um
arquivo limpo que você pode reimportar. É a maneira de menor esforço para manter uma
lista saudável e sua taxa de bounce baixa sem manter
nenhuma automação.
Se você está pesando a abordagem por webhook do Zapier contra chamar a API diretamente do seu próprio backend, a comparação de APIs apresenta os trade-offs — o Zapier ganha na rapidez de montagem, uma integração direta ganha em custo e controle em escala.
Perguntas frequentes#
Existe um app nativo da Qualisend para o Zapier?#
Ainda não. As integrações nativas de plataforma da Qualisend estão sendo reconstruídas, então ainda não há um app da marca para procurar no diretório do Zapier — está no roadmap. Até o lançamento, a maneira suportada de verificar e-mails com o Zapier é a ação genérica Webhooks by Zapier apontada para a API da Qualisend, exatamente como este guia descreve. A abordagem por webhook também é mais flexível: você controla a requisição, os headers e a lógica de ramificação.
Preciso de um plano pago do Zapier?#
Para o Zap em tempo real, na prática sim. O Webhooks by Zapier é um app integrado premium, e Zaps com múltiplas etapas e Paths exigem um plano pago do Zapier, então o fluxo de ramificação por veredicto precisa de um plano pago. Se você está no plano gratuito, use a rota de exportação em CSV e verificação em lote — ela não precisa de Zap nem de app premium, apenas do upload de um arquivo.
Qual status devo deixar passar para a minha ferramenta de e-mail?#
Apenas deliverable para um filtro rigoroso. Se você quiser manter mais endereços,
permita deliverable além de risky/unknown, mas direcione 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 também ramificar pela sub-flag disposable
se o seu produto for sensível a reputação.
Como testo o Zap antes de ativá-lo?#
Use a ação Test action integrada do Zapier na etapa do webhook com um endereço
sabidamente válido e um sabidamente inválido, e confirme que o campo status muda como
esperado — depois verifique se as condições do seu Filter ou Paths direcionam cada um
para a ramificação certa. Para conferências rápidas e pontuais fora do Zapier, cole um
endereço no verificador de e-mail gratuito e compare o veredicto
com o que o seu Zap retorna.
Pronto para construí-lo? Pegue uma chave com escopo e o formato exato da requisição na documentação para desenvolvedores, confira qualquer endereço no verificador de e-mail gratuito e comece no plano gratuito — 100 créditos são suficientes para montar o Zap inteiro e ver um endereço ruim ser filtrado antes mesmo de chegar à sua lista.
