Come verificare le email con Zapier

Puoi verificare le email con Zapier già oggi, anche se non esiste ancora un'app Zapier nativa di Qualisend. Il trucco è smettere di cercare un connettore con il marchio e usare l'azione generica Webhooks by Zapier: il tuo form o CRM attiva un trigger, Zapier invia con una POST il nuovo indirizzo all'API di Qualisend e uno step Filter o Paths crea una diramazione in base all'esito, così solo gli indirizzi recapitabili passano al tuo strumento email e quelli a rischio restano in attesa di revisione. Questa guida costruisce quello Zap dall'inizio alla fine.

In breve#

Al momento non c'è un'app nativa da installare (è in roadmap), quindi lo schema supportato è uno Zap breve: un trigger (nuovo invio di un form, nuovo lead, nuova riga), un'azione Webhooks by Zapier → Custom Request (POST) che chiama l'API di verifica con l'email, un Delay più uno step Webhooks by Zapier → GET che recupera l'esito definitivo, e uno step Filter o Paths che legge lo status restituito e decide cosa succede dopo. Tieni la chiave API nelle intestazioni del webhook, mai in un form pubblico, e per impostazione predefinita lascia passare l'indirizzo se il webhook va in errore, così un intoppo temporaneo non ti fa mai perdere un vero lead.

Due modi per verificare le email con Zapier#

Prima di collegare qualsiasi cosa, scegli lo schema in base a quanto devono essere aggiornati i dati:

1. In tempo reale, per ogni invio di form (uno Zap). Ogni nuovo indirizzo viene verificato non appena arriva e indirizzato sul momento. È l'argomento principale di questa guida e la scelta giusta quando l'esito cambia ciò che succede dopo: decidere se inviare l'email di double opt-in, aggiungere un tag a un lead o saltare un'iscrizione falsa.
2. In blocco, a posteriori (un CSV). Lascia che le risposte ai form si accumulino in un foglio o nel tuo ESP, esportale periodicamente e passale a un job di verifica in blocco. È più semplice, costa meno per indirizzo ed è più adatto quando ti serve solo una lista pulita prima di un invio, non una decisione immediata.

La maggior parte dei team finisce per fare entrambe le cose: uno Zap sulle iscrizioni in arrivo, più una pulizia della lista mensile per intercettare gli indirizzi diventati obsoleti dopo l'iscrizione.

Passo 1: il trigger#

Inizia lo Zap con ciò che raccoglie l'indirizzo. Zapier ha trigger nativi per la maggior parte degli strumenti di form e CRM: "New Submission" in un'app di form, "New Lead" in un CRM, "New Spreadsheet Row" in Google Sheets. Qualunque sia la tua scelta, l'output importante è un campo che contiene l'indirizzo email, a cui gli step successivi fanno riferimento con un token di merge come {{1.email}}.

La stessa identica azione webhook funziona qualunque cosa la attivi, quindi lo schema di questa guida non cambia se stai collegando Typeform, un CRM o un foglio: vedi verificare le email da Typeform per una guida specifica sul trigger che poi rimanda ai passi qui sotto.

Passo 2: invia l'indirizzo con una POST tramite Webhooks by Zapier#

Aggiungi uno step di azione e scegli Webhooks by Zapier, poi l'evento Custom Request. È lo step che chiama davvero Qualisend. Configuralo così:

Nella casella Data, Zapier ti permette di digitare JSON grezzo e di inserirvi il token email del trigger. Il corpo che invii è semplicemente:

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

E la richiesta che Zapier invia per tuo conto è questa: i segnaposto li compili tu partendo dalla documentazione per sviluppatori, che indica l'endpoint esatto e mostra la richiesta in diversi linguaggi:

POST https://app.qualisend.com/api/v1/verify
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{ "email": "jane@example.com" }

Usa una chiave con scope creata per questo Zap anziché una chiave con accesso completo, così se la cronologia dello Zap dovesse mai far trapelare la chiave, questa potrà solo chiamare l'API di verifica, mai accedere ad account, fatturazione o impostazioni del team. Non inserire mai la chiave nel form o in un campo lato client: deve stare solo nelle intestazioni del webhook, che vengono gestite lato server dentro Zapier.

Quando fai clic su Test action, Zapier mostra il corpo della risposta. Riceverai un job_id e un oggetto result che contiene uno status, un codice reason, uno score da 0 a 100, un insieme di sub_flags e un campo smtp. Per un indirizzo nuovo, la risposta di solito è più o meno questa:

{
  "job_id": "8f3c9a2e-5b1d-4e7a-9c6f-2d8b1a4e7f30",
  "probe_queued": true,
  "result": {
    "email": "jane@example.com",
    "status": "unknown",
    "score": 60,
    "sub_flags": { "free_mail": false, "disposable": false, "role": false, "catch_all": false, "full_mailbox": false, "disabled": false },
    "did_you_mean": null,
    "smtp": "pending",
    "reason": null
  }
}

Quel unknown non è ancora l'esito. La risposta arriva subito, mentre il controllo SMTP della casella è ancora in corso: smtp indica pending e status resta un unknown provvisorio finché il controllo non termina. Quando smtp indica cached o skipped (un indirizzo controllato di recente, o già risolto dai controlli immediati), il result è definitivo. In ogni caso, lo step successivo legge l'esito definitivo dal job, quindi tieni a portata di mano il token job_id.

Passo 3: recupera l'esito definitivo#

Dai al controllo della casella il tempo di terminare prima di creare la diramazione. Aggiungi uno step Delay by Zapier → Delay For di qualche minuto, poi una seconda azione Webhooks by Zapier con l'evento GET. Puntala verso il job, con include=results come parametro della query string e la stessa intestazione Authorization:

GET https://app.qualisend.com/api/v1/jobs/{{2.job_id}}?include=results
Authorization: Bearer YOUR_API_KEY

Qui {{2.job_id}} è il job_id dello step POST. Questo step si limita a leggere il job: non verifica mai l'indirizzo una seconda volta né spende un altro credito, e quando smtp era già cached o skipped restituisce semplicemente lo stesso esito definitivo. Un controllo terminato appare più o meno così:

{
  "id": "8f3c9a2e-5b1d-4e7a-9c6f-2d8b1a4e7f30",
  "type": "single",
  "status": "completed",
  "results": [
    {
      "email": "jane@example.com",
      "status": "deliverable",
      "score": 93,
      "reason": "accepted_email",
      "sub_flags": { "free_mail": false, "disposable": false, "role": false, "catch_all": false, "full_mailbox": false, "disabled": false }
    }
  ]
}

Lo step successivo crea la diramazione su quei nomi di campo, quindi nota come li etichetta Zapier: di solito li appiattisce in token come results status e results sub_flags catch_all. Se il controllo non è terminato quando parte la GET, ad esempio perché il server ricevente è lento a rispondere, results status indica ancora queued o processing. Mandali in revisione insieme a risky e unknown, non scartarli mai. Per il quadro completo di cosa significa ogni status e di come la pipeline ci arriva, leggi come funziona la verifica email.

Passo 4: crea una diramazione in base all'esito#

Un risultato di verifica su cui non agisci è un credito sprecato. Il punto è proprio smistare gli indirizzi in modo diverso, e Zapier ti offre due strumenti per farlo.

Opzione A: un Filter (la più semplice). Se vuoi solo "tenere gli indirizzi buoni", aggiungi uno step Filter by Zapier dopo lo step GET. Imposta la condizione così:

• Results Status (text) exactly matches deliverable

Tutto ciò che non è recapitabile ferma lo Zap in quel punto, quindi solo gli indirizzi confermati raggiungono l'azione successiva (aggiunta al tuo ESP, creazione del contatto, invio dell'email di benvenuto). Semplice, ma grossolano: tratta risky, unknown e undeliverable allo stesso modo, mentre spesso conviene gestirli in modo diverso.

Opzione B: Paths (un percorso per ogni risultato). Paths by Zapier, disponibile sui piani a pagamento di Zapier, ti permette di dividere il flusso in rami separati, ciascuno con la propria condizione e le proprie azioni successive:

Puoi creare diramazioni anche sugli indicatori aggiuntivi. Se il tuo prodotto è sensibile alla reputazione, aggiungi una condizione che manda nel percorso di revisione ogni indirizzo in cui results sub_flags disposable è true, anche quando lo stato è altrimenti corretto: è la stessa scelta su indirizzi usa e getta, generici e gratuiti illustrata nella panoramica su indirizzi generici, usa e getta e gratuiti. I percorsi vengono valutati dall'alto verso il basso, quindi metti per primo il ramo più rigoroso.

Non lasciare che il webhook blocchi un lead valido#

Una regola conta più di qualsiasi ramo: lascia passare in caso di errore (fail open). Se lo step del webhook va in errore (l'API è lenta per qualche istante, viene raggiunto un limite del piano, un problema di rete), non vuoi che l'intero Zap si fermi e faccia sparire in silenzio una vera iscrizione. In Zapier, apri le impostazioni dell'azione webhook e attiva "Continue on error" (a volte compare come opzione di auto-replay o gestione degli errori, a seconda del piano). Fallo sia sullo step POST sia sullo step GET. Poi aggiungi un fallback, così un indirizzo senza esito viene trattato come unknown e conservato per una revisione successiva invece di essere scartato.

Un'API di verifica è un filtro di qualità, non un controllo di autenticazione. Bloccare un cliente pagante per un'interruzione temporanea è molto peggio che lasciar passare un indirizzo dubbio e intercettarlo alla prossima pulizia della lista. Lo stesso principio del fail open è alla base dello schema serverless per le iscrizioni, dove un test lento non deve mai bloccare il form.

Quando uno Zap è lo strumento sbagliato#

Zapier è un collante, e il collante ha un costo: ogni indirizzo verificato è un task, e un webhook per ogni invio di form può diventare costoso a grandi volumi o sembrare eccessivo quando non ti serve una decisione immediata. Passa piuttosto al percorso in batch quando:

• Stai pulendo una lista che esiste già: migliaia di contatti storici, non nuove acquisizioni. Esportali e lancia un unico job in blocco.
• I tuoi volumi sono abbastanza alti da rendere pesante il prezzo per task, e una pulizia notturna o settimanale è sufficientemente aggiornata.
• Sei sul piano gratuito di Zapier e non puoi usare l'app premium Webhooks.

In tutti e tre i casi, salta lo Zap: esporta le risposte in CSV dal tuo strumento di form, foglio o ESP e carica quel file nel verificatore in blocco di Qualisend. Ottieni gli stessi status, score e indicatori aggiuntivi per ogni riga, scaricabili come file pulito da reimportare. È il modo meno faticoso per mantenere sana una lista e basso il tuo tasso di bounce senza gestire alcuna automazione.

Se stai valutando i webhook di Zapier rispetto alla chiamata diretta all'API dal tuo backend, il confronto tra API espone i pro e i contro: Zapier vince sulla velocità di configurazione, un'integrazione diretta vince su costi e controllo su larga scala.

Pronto a costruirlo? Prendi una chiave con scope e la forma esatta della richiesta dalla documentazione per sviluppatori, controlla qualsiasi indirizzo con la verifica email gratuita e inizia con il piano Free: 100 crediti bastano per collegare l'intero Zap e vedere un indirizzo non valido filtrato prima che raggiunga la tua lista.