Verificare le email dai moduli Webflow prima che generino bounce

Webflow include un modulo in ogni sito, ma archivia senza problemi asdf@asdf, una casella usa e getta o un @gmial.com digitato di fretta accanto ai tuoi lead veri, e ognuno di questi indirizzi genera un hard bounce non appena il tuo ESP prova a scrivergli. Per verificare le email dai moduli Webflow devi far passare l'invio del modulo da un controllo di verifica prima che arrivi nel CRM: in tempo reale, nell'istante in cui qualcuno preme invio, oppure in blocco in un secondo momento. Questa guida copre entrambi i percorsi, con codice funzionante per quello in tempo reale e una nota onesta su dove il tuo piano Webflow ti pone dei limiti.

In breve#

Oggi non esiste un'app Qualisend da installare in Webflow (i connettori nativi per le piattaforme sono in fase di ricostruzione), quindi entrambi gli schemi la aggirano. In tempo reale: invia ogni modulo compilato a una piccola funzione lato server (tramite un webhook dei moduli Webflow o un passaggio Make/Zapier "watch form submissions"), fai chiamare a quella funzione l'API di verifica e agisci sull'esito prima di sincronizzare il lead a valle. In blocco: esporta in CSV gli invii dei moduli Webflow e passali a un job di verifica in blocco. Il tempo reale tiene gli indirizzi sbagliati fuori dalla lista fin dall'inizio; la verifica in blocco serve a pulire ciò che c'è già.

Perché verificare le email dei moduli Webflow al punto di acquisizione#

Un indirizzo morto intercettato nel modulo Webflow è un bounce che non avviene mai. Lo stesso indirizzo scoperto tre invii dopo ti è già costato tentativi di recapito, ha intaccato il tuo tasso di bounce e ha spinto la tua reputazione del mittente nella direzione sbagliata. La verifica al punto di acquisizione è prevenzione; la pulizia della lista è un rimedio, e la prevenzione costa meno sotto ogni aspetto. Ferma anche i problemi più silenziosi che non generano bounce ma fanno comunque danni: un indirizzo generico come info@ che non legge nessuno in particolare, o una casella usa e getta che gonfia il numero di iscritti e la tua fattura senza aprire mai nulla.

Se vuoi capire i meccanismi di base (sintassi, MX e il test SMTP della casella), come funziona la verifica email illustra la pipeline da cui esce ogni esito.

Percorso 1: verifica in tempo reale con un webhook#

In tempo reale significa che il controllo avviene tra l'invio del modulo Webflow e la sincronizzazione con il tuo ESP o CRM. Servono tre componenti:

1. Far uscire l'invio da Webflow. Webflow può inviare con una POST ogni modulo compilato a un URL di tua proprietà. Con un Site plan a pagamento puoi registrare un webhook form_submission (Site settings → Integrations, oppure tramite la Data API di Webflow), che si attiva senza toccare gli invii che Webflow conserva per te. Alternativa no-code: collega Make o Zapier, usa il loro trigger Webflow "new form submission" e aggiungi un passaggio Webhooks che invia una POST alla tua funzione. In ogni caso la destinazione è un piccolo endpoint che controlli tu, mai direttamente l'API di verifica, perché porteresti la chiave in un posto in cui non vuoi che stia.
2. Una funzione lato server che custodisce la chiave API, chiama l'endpoint di verifica e trasforma la risposta in una decisione.
3. La tua logica di sincronizzazione, che invia il lead al CRM solo quando l'esito lo consente.

La funzione di verifica#

Ecco il pezzo centrale come funzione serverless: la struttura funziona su Vercel, Netlify, Cloudflare Workers o qualsiasi host che ti dia un handler HTTP. La funzione legge l'email dal payload del webhook, chiama l'API e decide. Il percorso dell'endpoint e il payload qui sotto sono segnaposto (controlla il riferimento API per la richiesta esatta) e la chiave con ambiti definiti (YOUR_API_KEY) resta sul server in una variabile d'ambiente, mai nel codice delle pagine Webflow:

// api/webflow-verify.js — Webflow (or Make/Zapier) POSTs form submissions here
export default async function handler(req, res) {
  // Webflow's form_submission webhook nests the fields under `data`;
  // a Make/Zapier Webhooks step can forward the same shape.
  const fields = req.body?.data ?? req.body ?? {};
  const email = fields.email ?? fields.Email;
  if (!email) return res.status(400).json({ error: "no email field" });

  let verdict = { status: "unknown" }; // default if the API can't be reached
  try {
    const r = await fetch("https://app.qualisend.com/api/v1/verify", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${process.env.QUALISEND_API_KEY}`, // your scoped key
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ email }),
      signal: AbortSignal.timeout(4000), // don't let a slow probe stall the webhook
    });
    if (r.ok) {
      const { job_id, result } = await r.json();
      verdict = { ...result, job_id }; // { status, reason, score, sub_flags, smtp, job_id }
    }
  } catch {
    // timeout or network error — fall through as "unknown" and sync anyway
  }

  // Act on the verdict BEFORE the lead reaches your ESP/CRM.
  if (verdict.status === "undeliverable" || verdict.sub_flags?.disposable) {
    return res.status(200).json({ synced: false, status: verdict.status });
  }

  await syncToCrm(email, fields, verdict); // your existing ESP/CRM call
  // smtp "pending": the mailbox probe is still running. A background job (not this
  // handler) polls GET /api/v1/jobs/{job_id} for the final verdict and updates the lead.
  if (verdict.smtp === "pending") await queueVerdictCheck(verdict.job_id, email);
  return res.status(200).json({ synced: true, status: verdict.status });
}

La risposta ti dà uno status (deliverable, risky, undeliverable o unknown), un codice motivo reason, uno score da 0 a 100 e sub_flags per disposable, role, free_mail e catch_all. È tutto ciò che ti serve per instradare il lead. Il primo esito arriva subito. Quando il suo campo smtp è "pending", il test della casella è ancora in corso: lo snippet passa il job_id a un job in background che legge l'esito finale da GET /jobs/{job_id} e aggiorna il lead, invece di tenere aperto il webhook o chiamare di nuovo /verify. I meccanismi serverless (custodire la chiave, impostare il timeout e applicare il fail open) sono gli stessi trattati in dettaglio in verificare le email all'iscrizione con una funzione serverless, e la versione specifica per Node della chiamata API è in validare un indirizzo email in Node.js.

Agire in base all'esito#

Il vantaggio di farlo prima della sincronizzazione è che puoi prendere una decisione di instradamento invece di lasciar passare tutto:

Dove conta il tuo piano Webflow#

Sii onesto con te stesso su quale meccanismo puoi davvero usare, perché dipende dal tuo piano:

• I webhook form_submission nativi e l'aggiunta di codice personalizzato a un sito richiedono un Site plan Webflow a pagamento. Con il piano gratuito non hai accesso ai webhook né agli embed personalizzati, e gli invii dei moduli hanno un limite massimo.
• La sostituzione dell'action del modulo (puntare l'URL di action del modulo direttamente al tuo endpoint) funziona senza webhook, ma salta l'archiviazione degli invii e le notifiche email di Webflow: ti stai facendo carico dell'intero invio.
• Make o Zapier aggirano la questione del piano sul lato Webflow, ma aggiungono un passaggio che pagherai sul loro lato e aggiungono latenza. Per la maggior parte dei team il webhook nativo è il percorso in tempo reale più pulito, una volta passati a un piano a pagamento.

Nel dubbio, parti da ciò a cui hai già accesso. Alla funzione centrale non importa come le arriva l'invio.

Percorso 2: verifica in blocco degli invii esportati#

Se il tempo reale richiede più lavoro di quanto vuoi affrontare ora, o hai già una montagna di invii raccolti prima di configurare tutto questo, verifica in blocco:

1. Apri il pannello Forms del tuo sito nelle impostazioni di Webflow ed esporta gli invii in CSV (l'esportazione è una funzione dei piani a pagamento).
2. Carica quel CSV in un job di verifica in blocco su Qualisend. Ogni riga torna con gli stessi status, reason, score e sub_flags dell'API in tempo reale.
3. Tieni le righe deliverable, elimina o metti in quarantena undeliverable e disposable, e decidi caso per caso su risky e catch_all.
4. Importa la lista pulita nel tuo ESP.

Questo è il normale ciclo di igiene della lista, e come pulire una lista email spiega come leggere gli indicatori e cosa fare con ogni gruppo. La verifica in blocco è anche lo strumento giusto per un controllo una tantum di tutto ciò che Webflow ha già raccolto: non c'è motivo di lasciare nel CRM indirizzi notoriamente morti.

Quale percorso scegliere?#

La maggior parte dei team finisce per usarli entrambi: il tempo reale per mantenere pulita la lista da qui in avanti e un passaggio in blocco ogni tanto per intercettare gli indirizzi diventati obsoleti da quando si sono iscritti.

E un'app nativa per Webflow?#

Al momento non esiste. Le integrazioni native di Qualisend con le piattaforme sono in fase di ricostruzione, quindi non cercare un'app, un plugin o un connettore Qualisend nel marketplace di Webflow: non ne esiste ancora nessuno e un'integrazione nativa con Webflow è nella roadmap, non disponibile oggi. Finché non arriverà, lo schema webhook più funzione descritto sopra è l'approccio in tempo reale supportato, e la verifica in blocco via CSV copre tutto il resto. Nessuno dei due deve aspettare l'integrazione.

Pronto a tenere gli indirizzi sbagliati fuori dai tuoi lead Webflow? Prova gratis qualsiasi indirizzo con la verifica di un singolo indirizzo, prendi l'endpoint /verify e le chiavi con ambiti definiti dal riferimento API e parti dal piano Free con 100 crediti per collegare il webhook dall'inizio alla fine.