Puedes verificar correos con Zapier hoy mismo, aunque todavía no exista una app nativa de Qualisend para Zapier. El truco está en dejar de buscar un conector de marca y usar en su lugar la acción genérica Webhooks by Zapier: tu formulario o CRM dispara un trigger, Zapier envía la nueva dirección por POST a la API de Qualisend y un paso de Filter o Paths ramifica según el veredicto, de modo que solo las direcciones deliverable siguen hasta tu herramienta de correo y las risky quedan aparcadas para revisión. Esta guía construye ese Zap de principio a fin.
La respuesta corta#
Ahora mismo no hay ninguna app nativa que instalar (está en la hoja de ruta), así
que el patrón admitido es un Zap de tres pasos: un trigger (nuevo envío de
formulario, nuevo lead, nueva fila), una acción Webhooks by Zapier → Custom
Request (POST) que llama a la API de verificación con el correo, y un paso de
Filter o Paths que lee el status devuelto y decide qué ocurre a
continuación. Mantén tu clave de API en las cabeceras del webhook, nunca en un
formulario público, y, por defecto, deja pasar una dirección si el webhook llega
a fallar, para que un fallo pasajero nunca descarte un lead real.
Dos formas de verificar correos con Zapier#
Antes de conectar nada, elige el patrón que se ajuste a lo actualizados que necesitan estar los datos:
- En tiempo real, por envío (un Zap). Cada nueva dirección se verifica en el momento en que llega y se encamina al instante. Este es el tema principal de esta guía y la opción correcta cuando el veredicto cambia lo que ocurre a continuación: bloquear un correo de doble opt-in, etiquetar un lead o saltarte un registro falso.
- Por lotes, a posteriori (un CSV). Deja que los envíos se acumulen en una hoja o en tu ESP, expórtalos periódicamente y pásalos por un trabajo de verificación masiva. Más sencillo, más barato por dirección y mejor opción cuando solo necesitas una lista limpia antes de un envío en lugar de una decisión instantánea.
La mayoría de los equipos acaban haciendo ambas cosas: un Zap sobre la entrada en vivo, más una limpieza de lista mensual para detectar direcciones que se han quedado obsoletas desde que se registraron.
Paso 1: el trigger#
Empieza el Zap con lo que sea que capture la dirección. Zapier tiene triggers
nativos para la mayoría de herramientas de formularios y CRM: "New Submission" en
una app de formularios, "New Lead" en un CRM, "New Spreadsheet Row" en Google
Sheets. Elijas lo que elijas, lo importante de la salida es un campo que contenga
la dirección de correo, al que los pasos posteriores hacen referencia como un
token de fusión del tipo {{1.email}}.
Exactamente la misma acción de webhook funciona sin importar qué la dispare, así que el patrón de esta guía es idéntico tanto si estás conectando Typeform, un CRM o una hoja de cálculo; consulta verificar correos desde Typeform para ver un recorrido específico según el trigger que después enlaza con los pasos de abajo.
Paso 2: envía la dirección por POST con Webhooks by Zapier#
Añade un paso de acción y elige Webhooks by Zapier, luego el evento Custom Request. Este es el paso que realmente llama a Qualisend. Configúralo así:
| Campo | Valor |
|---|---|
| Method | POST |
| URL | tu endpoint de verificación, p. ej. https://api.qualisend.com/v1/verify (consulta la referencia de la API para conocer la ruta exacta) |
| Data Pass-Through? | No |
| Data | cuerpo JSON con una única clave email mapeada al campo de correo del trigger |
| Headers | Authorization: Bearer YOUR_API_KEY y Content-Type: application/json |
En la caja Data, Zapier te permite escribir JSON en bruto e insertar en él el token de correo del trigger. El cuerpo que envías es simplemente:
{ "email": "{{1.email}}" }
Y la petición que Zapier dispara en tu nombre tiene este aspecto: los marcadores de posición los rellenas tú a partir de la documentación para desarrolladores, que indica el endpoint exacto y muestra la petición en varios lenguajes:
POST https://api.qualisend.com/v1/verify
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
{ "email": "jane@example.com" }
Usa una clave con alcance limitado creada para este Zap en lugar de una clave de acceso total, para que, si el historial del Zap llegara a filtrar la clave, esta solo pueda verificar y nada más. Nunca pongas la clave en el propio formulario ni en ningún campo del lado del cliente: pertenece únicamente a las cabeceras del webhook, que se ejecutan del lado del servidor dentro de Zapier.
Cuando hagas clic en Test action, Zapier te muestra el cuerpo de la respuesta.
Recibirás de vuelta un status, un código reason, un score de 0 a 100 y un
conjunto de sub_flags. Una dirección deliverable vuelve más o menos así:
{
"status": "deliverable",
"reason": null,
"score": 95,
"sub_flags": { "disposable": false, "role": false, "free": false, "catch_all": false }
}
Esos nombres de campo son sobre los que ramifica el siguiente paso, así que fíjate
en cómo los etiqueta Zapier: normalmente los aplana en tokens como status y
sub_flags catch_all. Para tener la imagen completa de lo que significa cada
estado y de cómo llega a él el pipeline, consulta
cómo funciona la verificación de correos.
Paso 3: ramifica según el veredicto#
Un resultado de verificación sobre el que no actúas es crédito desperdiciado. Todo el sentido está en encaminar las direcciones de forma distinta, y Zapier te da dos herramientas para ello.
Opción A: un Filter (lo más sencillo). Si lo único que quieres es "conservar solo las direcciones buenas", añade un paso Filter by Zapier después del webhook. Configura la condición como:
- Status (texto) coincide exactamente con
deliverable
Cualquier cosa que no sea deliverable detiene el Zap ahí mismo, de modo que solo
las direcciones confirmadas llegan a tu acción posterior (añadirla a tu ESP, crear
el contacto, enviar el correo de bienvenida). Sencillo, pero tosco: trata risky,
unknown y undeliverable de la misma forma, cuando a menudo querrás gestionarlas
de otra manera.
Opción B: Paths (encamina cada resultado). Paths by Zapier, disponible en los planes de pago de Zapier, te permite bifurcarte en ramas separadas, cada una con su propia condición y sus propias acciones de seguimiento:
| Condición de la ruta | Qué hacer |
|---|---|
El estado es deliverable | Añade el contacto a tu ESP o CRM y continúa el funnel. |
El estado es risky o unknown | Añádelo a una lista de "pendiente de revisión" o etiquétalo; no lo descartes de golpe. En este grupo entran los dominios catch-all que no se pueden sondear con claridad. |
El estado es undeliverable | No lo añadas a ningún sitio. Si quieres, regístralo en una hoja para poder detectar un campo de formulario roto o una fuente de tráfico de mala calidad. |
También puedes ramificar según los subindicadores. Si tu producto es sensible a la
reputación, añade una condición que encamine cualquier dirección en la que
sub_flags disposable sea true hacia la ruta de revisión aunque el estado sea
por lo demás correcto: el mismo criterio sobre las direcciones disposable, role y
free que recorre
el desglose de direcciones role, disposable y free.
Los Paths se evalúan de arriba abajo, así que pon primero tu rama más estricta.
No dejes que el webhook bloquee un buen lead#
Una regla importa más que cualquier ramificación: falla en abierto. Si el paso
del webhook falla (la API va lenta un momento, se alcanza un límite del plan, hay
un corte de red), no quieres que todo el Zap se caiga y se trague en silencio un
registro real. En Zapier, abre los ajustes de la acción del webhook y activa
"Continue on error" (a veces se muestra como una opción de reintento
automático / gestión de errores según tu plan). Después añade un valor de reserva
para que una dirección sin veredicto se trate como unknown y se conserve para
revisarla más tarde en lugar de descartarla.
Una API de verificación es un filtro de calidad, no una puerta de autenticación. Bloquear a un cliente que paga por culpa de un corte pasajero es un desenlace mucho peor que dejar pasar una dirección dudosa y atraparla en tu próxima limpieza de lista. El mismo principio de fallar en abierto sustenta el patrón de registro serverless, donde un sondeo lento nunca debe atascar el formulario.
Cuándo un Zap es la herramienta equivocada#
Zapier es pegamento, y el pegamento tiene un coste: cada dirección verificada es una tarea, y un webhook por envío puede salir caro a gran volumen o parecer excesivo cuando no necesitas una decisión instantánea. Recurre en su lugar a la ruta por lotes cuando:
- Estás limpiando una lista que ya existe: miles de contactos históricos, no entradas nuevas. Expórtalos y pásalos por un único trabajo por lotes.
- Tu volumen es lo bastante alto como para que el precio por tarea escueza, y una limpieza nocturna o semanal es lo suficientemente actual.
- Estás en el plan gratuito de Zapier y no puedes usar la app premium de Webhooks.
Para los tres casos, sáltate el Zap: exporta los envíos a CSV desde tu herramienta
de formularios, hoja o ESP, y sube ese archivo al verificador masivo de Qualisend.
Obtienes el mismo status, score y subindicadores por fila, descargables como un
archivo limpio que puedes volver a importar. Es la forma con menos esfuerzo de
mantener una lista sana y tu tasa de rebote baja
sin mantener ninguna automatización.
Si estás sopesando el enfoque de webhook de Zapier frente a llamar a la API directamente desde tu propio backend, la comparativa de APIs expone los compromisos: Zapier gana en rapidez de puesta en marcha, y una integración directa gana en coste y control a escala.
Preguntas frecuentes#
¿Existe una app nativa de Qualisend para Zapier?#
Ahora mismo no. Las integraciones nativas de plataforma de Qualisend se están reconstruyendo, así que todavía no hay ninguna app de marca que buscar en el directorio de Zapier: está en la hoja de ruta. Hasta que se publique, la forma admitida de verificar correos con Zapier es la acción genérica Webhooks by Zapier apuntando a la API de Qualisend, exactamente como describe esta guía. El enfoque de webhook también es más flexible: tú controlas la petición, las cabeceras y la lógica de ramificación.
¿Necesito un plan de pago de Zapier?#
Para el Zap en tiempo real, en la práctica sí. Webhooks by Zapier es una app integrada premium, y los Zaps de varios pasos y los Paths requieren un plan de pago de Zapier, así que el flujo de ramificar según el veredicto necesita un plan de pago. Si estás en el plan gratuito, usa en su lugar la ruta de exportar a CSV y verificar por lotes: no requiere ningún Zap ni ninguna app premium, solo subir un archivo.
¿Qué estado debería dejar pasar hacia mi herramienta de correo?#
Solo deliverable si quieres una puerta estricta. Si prefieres conservar más
direcciones, permite deliverable más risky/unknown, pero encamínalas a un
segmento aparte de menor prioridad en lugar de a tu flujo principal: muchos
resultados risky son dominios catch-all que
aún podrían entregar. Rechaza siempre undeliverable y plantéate ramificar también
según el subindicador disposable si tu producto es sensible a la reputación.
¿Cómo pruebo el Zap antes de activarlo?#
Usa la acción de prueba integrada de Zapier en el paso del webhook con una
dirección que sepas que es buena y otra que sepas que es mala, y confirma que el
campo status cambia como esperas; luego comprueba que tus condiciones de Filter o
Paths encaminan cada una a la rama correcta. Para comprobaciones puntuales rápidas
fuera de Zapier, pega una dirección en el
verificador de correos gratuito y compara el veredicto con
el que devuelve tu Zap.
¿Listo para construirlo? Consigue una clave con alcance limitado y la forma exacta de la petición en la documentación para desarrolladores, comprueba cualquier dirección en el verificador de correos gratuito y empieza con el plan gratuito: 100 créditos bastan para montar el Zap entero y ver cómo una dirección mala se filtra antes de que llegue siquiera a tu lista.
