Verificar emails B2B en n8n
Clasifica válido/inválido/catch-all, HITL en riesgosos y upsert emailVerified en CRM (Europe/Madrid).
Verificar emails B2B n8n: estados, HITL, HubSpot o Pipedrive, Sheets y Slack. Flag emailVerified bajo RGPD Europe/Madrid.
Descarga el workflow
JSON listo para importar en n8n (Import from File). Sustituye solo REEMPLAZA_* y credenciales.
Qué problema resuelve frente a confiar en Apollo verified
Una columna verified en un export de Apollo, Clay u otra herramienta de datos no garantiza buzón vivo. Muchos correos pasan sintaxis y reputación del proveedor, pero rebotan al primer envío real y queman dominio, inbox y warmup. Este workflow de n8n orquesta una segunda pasada: clasifica válido, inválido, catch-all o riesgoso, escribe emailVerified en el CRM, deja traza en Sheets Verificacion_Email y avisa por Slack.
El flujo no envía SMTP. Solo decide quién puede entrar en la cola de Instantly u otro ESP autorizado. La guía educativa está en /verificar-emails-b2b-automaticamente-antes-enviar. Este recurso es la mitad de implementación con timezone Europe/Madrid.
Úsalo cuando ya tengas una lista cualificada y quieras un control repetible antes de subir volumen: estados claros, HITL en catch-all/risky y un flag que el cold email a escala pueda leer sin discutir a mano cada fila. Si saltas esta pasada, el warmup del ESP paga el error con rebotes y spam folder desde el primer lote.
Qué necesitas antes de importar el JSON
Una instancia de n8n (local para probar, Cloud o VPS UE) y una política escrita: qué haces con catch-all, cuándo exiges HITL y qué propiedad del CRM guarda emailVerified. Sin ese documento, Config solo repite booleans sueltos.
Leads con email, nombre, empresa y, si vienes de un export, un statusHint o resultado de API. Campos útiles: firstName, lastName, email, title, company, sourceLabel, statusHint o verificationStatus. Documenta también el origen (Apollo, Clay, lista manual) para auditar después qué fuente genera más inválidos.
CRM con API (HubSpot Private App o api_token de Pipedrive), pestaña Google Sheets Verificacion_Email y Incoming Webhook de Slack. Decide batchLabel, demoMode, acceptCatchAll, requireHitlOnRisky, verifierApiUrl, verifierApiKey, crmProvider, sheetsId y slackWebhookUrl antes de Active. El JSON llega con REEMPLAZA_* y emails @example.com a propósito.
Cómo está construido el workflow (mapa del lienzo)
El lienzo abre con el sticky INSTRUCCIONES y Manual Trigger verificar emails. Config Verificar Emails concentra batchLabel, demoMode, acceptCatchAll, requireHitlOnRisky, URL y key del verificador, crmProvider, tokens placeholder, sheetsId, slackWebhookUrl y timezone Europe/Madrid.
Desde Config sale Payload de prueba (4 emails): Ana (valid), Bruno (invalid), Carla (catch_all) y Diego (risky). Ese payload alimenta Clasificar resultado, que calcula verificationStatus, emailVerified, queueReady, skipReason y requireHitl.
IF email válido: true → Upsert emailVerified → Append Sheets OK → Slack resumen. False → IF requireHitl → Slack HITL + Sheets pendiente o Append omitido. El workflow llega inactive y en timezone Europe/Madrid. Revisa cada rama antes de Active para no mezclar demos con producción.
Cómo funciona Clasificar resultado (demoMode vs API real)
Con demoMode=true el nodo lee statusHint del item y lo normaliza a valid, invalid, catch_all o risky. Así pruebas las cuatro ramas sin gastar créditos de un proveedor externo.
Con demoMode=false debes sustituir o preceder el Code por un HTTP Request a tu API (NeverBounce, ZeroBounce, MillionVerifier u otra) y mapear la respuesta a verificationStatus o apiStatus. El clasificador ya entiende deliverable, undeliverable, accept_all y unknown.
acceptCatchAll=false (recomendado al empezar) rechaza catch-all con skipReason catch_all_rechazado y puede forzar HITL. requireHitlOnRisky=true marca risky y catch-all para revisión humana antes de marcar enviable. Mide durante dos semanas cuántos catch-all terminan en bounce real antes de abrir acceptCatchAll.
Payload de prueba: Ana, Bruno, Carla y Diego
Ana Rios (valid) entra en cola: emailVerified=true, Upsert CRM y fila verificado_ok en Sheets. Es el camino feliz que debe alimentar Instantly después.
Bruno Vila (invalid) se omite con email_invalido: demuestra por qué no debes confiar solo en un export Apollo sin segunda pasada.
Carla Mendez (catch_all sobre info@) y Diego Soler (risky) cubren HITL. Ejecuta Manual Trigger sin CRM real primero y revisa queueReady, skipReason y verificationStatus en cada rama. Si alguna rama no aparece, revisa las condiciones de los nodos IF antes de culpar al proveedor de verificación.
HITL, Upsert CRM con emailVerified y Sheets
IF requireHitl publica en Slack el email, empresa y estado para que alguien decida si el catch-all o risky entra en cola. No bloquea un Wait eterno: deja pendiente_hitl en Sheets.
Upsert CRM (emailVerified) escribe progreso en HubSpot o Pipedrive según crmProvider. En HubSpot conviene crear propiedades custom (emailverified, verification_status, last_email_verified_at). El nodo no envía correo.
Crea la pestaña Verificacion_Email con columnas: fecha, batchLabel, email, company, verificationStatus, emailVerified, estado, crmProvider y complianceFlag. Comparte la hoja con OAuth de Google Sheets en n8n. Ese inventario es la prueba de que no empujaste inválidos al ESP.
Importar el JSON y sustituir el payload demo
Import: n8n → ⋯ → Import from File → assets/workflows/verificar-emails-b2b-n8n.json. Rellena Config, crea Credentials y ejecuta Manual Trigger una vez.
En producción sustituye Manual Trigger + Payload de prueba por Schedule Trigger + lectura Sheets/CRM con el mismo shape. Pon demoMode=false y conecta el HTTP del verificador antes de Clasificar resultado.
No mezcles filas demo @example.com con leads reales en la misma ejecución. El cold email a escala (/recursos/cold-email-escala-n8n) debe leer emailVerified=true como puerta de entrada.
Producción 24/7, Make y Zapier
Un clasificador que solo corre en el portátil no protege el dominio el viernes. Sustituye Manual Trigger por Schedule (p. ej. cada hora), lee pendientes y vuelve a clasificar por lote. Evita Wait largos.
VPS UE: Ubuntu, Docker Compose, n8n + Postgres, HTTPS, GENERIC_TIMEZONE=Europe/Madrid, WEBHOOK_URL y N8N_ENCRYPTION_KEY. Aplica también los límites y costes del proveedor de verificación.
Make o Zapier: Schedule → HTTP verificador → Router por estado → Slack HITL → update CRM → Sheets. Este JSON es el esqueleto n8n; no copies secretos entre plataformas.
RGPD, minimización, HITL y EU AI Act
Tratas emails y datos de contacto B2B. Minimiza qué guardas en Sheets (evita volcar cuerpos de respuesta completos del API). Base jurídica habitual: interés legítimo documentado para prospección B2B, con baja clara en el envío posterior.
HITL en catch-all y risky amortigua falsos positivos y protege el dominio. complianceFlag rgpd_interes_legitimo_b2b_verificacion_antes_envio recuerda la revisión en Sheets.
Si un LLM interpreta resultados del verificador sois deployers bajo el Reglamento (UE) 2024/1689 (EU AI Act) Art. 4. Detalle en /uso-responsable-de-ia-y-transparencia. Texto informativo; no sustituye asesoramiento legal.
Preguntas frecuentes
¿Este flujo envía el email verificado por SMTP?
No. Solo clasifica y escribe emailVerified. El envío real lo haces en Instantly u otro ESP tras la cola de cold email.
¿Qué hace demoMode?
Con true usa statusHint del payload demo sin llamar a la API. Con false debes conectar tu HTTP de verificación y mapear verificationStatus.
¿Por qué cuatro emails en el payload?
Ana (valid), Bruno (invalid), Carla (catch_all) y Diego (risky) cubren las ramas principales sin tocar el CRM real.
¿Debo aceptar catch-all automáticamente?
No al empezar. Deja acceptCatchAll=false y requireHitlOnRisky=true hasta medir rebotes reales.
¿Qué columnas debe tener Verificacion_Email?
fecha, batchLabel, email, company, verificationStatus, emailVerified, estado, crmProvider y complianceFlag.
¿Dónde van tokens del verificador, HubSpot y Slack?
Nunca en el JSON descargado. Credentials dentro de n8n. Config trae REEMPLAZA_* a propósito.
¿Dónde está la guía larga?
En /verificar-emails-b2b-automaticamente-antes-enviar. Esta página es la mitad de implementación (JSON + pasos).