Come verificare le email con Make (Integromat)

Puoi già verificare le email con Make (ex Integromat), anche se nell'app non esiste ancora un modulo Qualisend dedicato. Lo schema consiste nel costruire uno scenario attorno al modulo generico HTTP: un trigger scatta quando arriva un nuovo indirizzo, una richiesta HTTP invia quell'indirizzo in POST all'API di Qualisend e un Router o un Filter legge l'esito e dirama il flusso. Così solo gli indirizzi recapitabili proseguono verso il tuo ESP o CRM, mentre quelli a rischio o non recapitabili vengono messi da parte. Questa guida costruisce lo scenario dall'inizio alla fine.

In breve#

Al momento non c'è un'app nativa da installare (è in roadmap), quindi lo schema supportato è uno scenario in tre parti: un trigger (nuovo invio di un form, nuova riga o un custom webhook a cui collegare un form), un modulo HTTP → Make a request che chiama l'API di verifica con l'email e un Router con filtri per ogni percorso, che leggono lo status restituito e decidono cosa succede dopo. Quando la risposta indica che il controllo della casella è ancora pending, prima uno Sleep breve e una GET sul job restituito recuperano l'esito finale. Tieni la chiave API negli header del modulo, mai in un campo pubblico di un form, e imposta il modulo HTTP perché continui a girare anche se l'API va in errore, così un intoppo temporaneo non ti fa mai perdere un lead vero.

Due modi per verificare le email con Make#

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

1. In tempo reale, a ogni invio (uno scenario). Ogni nuovo indirizzo viene verificato appena arriva e instradato all'istante. È l'argomento principale di questa guida e la scelta giusta quando l'esito cambia ciò che succede dopo: subordinare l'invio di un'email di double opt-in, aggiungere un tag a un lead o scartare un'iscrizione falsa.
2. In batch, a posteriori (un CSV). Lascia che gli invii si accumulino in un foglio o nel tuo ESP, esportali periodicamente e passali in 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 scenario sulle acquisizioni in tempo reale, più una pulizia della lista mensile per intercettare gli indirizzi diventati obsoleti dopo l'iscrizione.

Passo 1: il trigger#

Fai partire lo scenario da ciò che acquisisce l'indirizzo. Make ha centinaia di moduli trigger: "Watch Responses" in un'app per i form, "Watch Rows" in Google Sheets o Airtable, "New Lead" in un CRM. Se il tuo strumento per i form non ha un modulo Make dedicato, inserisci un Custom webhook come primo modulo e fai puntare lì l'URL del webhook del form; Make genera un URL univoco e ti mostra la struttura dei dati in arrivo non appena riceve il primo invio.

Qualunque cosa tu scelga, l'output che conta è un campo con l'indirizzo email, a cui i moduli successivi fanno riferimento come token mappato: Make li mostra come pillole colorate su cui fare clic per inserirle in un campo, prese dal bundle di output del trigger. Negli esempi qui sotto quel token è scritto come {{1.email}}, dove 1 è il modulo trigger.

Passo 2: invia l'indirizzo in POST con il modulo HTTP#

Aggiungi un modulo e scegli HTTP → Make a request. È il passaggio che chiama davvero Qualisend. Configuralo così:

Attiva Parse response perché Make trasformi il JSON in campi mappabili invece che in una stringa grezza. Nella casella Request content, scrivi il corpo e trascinaci la pillola dell'email del trigger:

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

La richiesta che Make invia per conto tuo è questa: i segnaposto li compili tu partendo dalla documentazione per sviluppatori, che riporta 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 apposta per questo scenario invece di una chiave ad accesso completo: se la cronologia di esecuzione dello scenario dovesse mai far trapelare la chiave, questa potrà solo verificare indirizzi e leggerne i risultati, nient'altro. Non mettere mai la chiave nel form o in un campo lato client: deve stare solo negli header del modulo HTTP, che vengono eseguiti lato server all'interno di Make.

Quando fai clic su Run once, Make mostra il bundle della risposta. Ricevi un job_id e un oggetto result con uno status, un codice reason (null finché il controllo della casella non termina), uno score da 0 a 100, un insieme di sub_flags e un campo smtp che indica se il controllo della casella è terminato. Un indirizzo nuovo che supera i controlli di sintassi e dominio di solito torna più o meno così:

{
  "job_id": "b7e4c2a0-1d3f-4e8a-9c6b-2f5a8d0e7c41",
  "result": {
    "status": "unknown",
    "reason": null,
    "score": 61,
    "smtp": "pending",
    "sub_flags": { "disposable": false, "role": false, "free_mail": false, "catch_all": false }
  }
}

Su questi nomi di campo si basano le diramazioni del passo successivo, quindi nota come li mappa Make: nei filtri farai riferimento a result: status, result: score e ai singoli sub_flags. Per il quadro completo di cosa significa ogni status e di come la pipeline ci arriva, leggi come funziona la verifica email.

Quando il controllo della casella è ancora in sospeso#

smtp ti dice se result è definitivo. cached o skipped significa che lo è, quindi puoi instradare subito in base a quello. pending, il caso abituale per un indirizzo nuovo, significa che il controllo SMTP della casella è ancora in corso e che status è un unknown provvisorio. Non chiamare di nuovo /verify per quell'indirizzo; recupera invece il suo job:

1. Subito dopo il modulo HTTP, aggiungi un Router con due percorsi: uno filtrato su result: smtp uguale a pending e un percorso di fallback per tutto il resto.
2. Sul percorso pending, aggiungi un modulo Sleep (sotto Tools) impostato a circa 60 secondi.
3. Fallo seguire da un secondo modulo HTTP → Make a request: metodo GET, URL https://app.qualisend.com/api/v1/jobs/{{2.data.job_id}}?include=results (dove 2 è il modulo POST), lo stesso header Authorization e Parse response attivato.

Lo status del job diventa completed quando il controllo è terminato, e l'esito finale è il primo elemento del suo array results. Per un indirizzo recapitabile è più o meno così:

{
  "status": "completed",
  "results": [
    {
      "email": "jane@example.com",
      "status": "deliverable",
      "reason": "accepted_email",
      "score": 92,
      "sub_flags": { "disposable": false, "role": false, "free_mail": false, "catch_all": false }
    }
  ]
}

Se il controllo è ancora in corso quando parte la GET (un server con greylisting può tenerlo aperto per diversi minuti), il job e il suo elemento risultano ancora pending o processing; il passo successivo li instrada verso la revisione invece di scartarli. Entrambi i percorsi di questo passo confluiscono negli stessi percorsi per esito, che sul percorso pending leggono status dal primo elemento di results della GET e sul percorso di fallback da result: status della POST.

Passo 3: crea le diramazioni in base all'esito con un Router#

Un risultato di verifica su cui non agisci è un credito sprecato. Il punto è proprio instradare gli indirizzi in modo diverso, e in Make per farlo c'è il modulo Router.

Inserisci un Router alla fine di ogni percorso del passo precedente (dopo la GET su quello pending) e si diramerà in tutti i percorsi che ti servono. Ogni percorso ha il proprio filter (fai clic sulla chiave inglese sulla linea che esce dal Router) che controlla lo status finale:

Make valuta i percorsi da sinistra a destra e, a meno che tu non contrassegni un percorso come fallback (quello senza filtro), vengono eseguiti tutti i percorsi che corrispondono: mantieni quindi le condizioni su status mutuamente esclusive, per evitare che un singolo indirizzo scorra lungo due rami. Imposta come fallback il percorso di revisione, non quello undeliverable: così un indirizzo il cui controllo è ancora pending o processing finisce in revisione invece di essere scartato e nulla resta senza categoria.

Puoi creare diramazioni anche in base agli indicatori aggiuntivi. Se il tuo prodotto è sensibile alla reputazione, aggiungi al percorso di revisione una condizione che scatti anche quando sub_flags: disposable è uguale a true, pur con uno status altrimenti buono: è la stessa valutazione su indirizzi usa e getta, generici e gratuiti illustrata nell'analisi di indirizzi generici, usa e getta e gratuiti. Un singolo filtro del Router accetta più condizioni AND/OR, quindi puoi combinare un test su status e uno su sub_flags nello stesso percorso.

Non lasciare che il modulo HTTP blocchi un buon lead#

Una regola conta più di qualsiasi ramo: fail open, cioè in caso di errore si lascia passare. Se il modulo HTTP va in errore (l'API è lenta per qualche istante, si raggiunge un limite del piano, un problema di rete momentaneo) non vuoi che l'intero scenario si fermi e inghiotta in silenzio un'iscrizione vera. Fai clic con il tasto destro su ciascun modulo HTTP (la POST e la GET), scegli Add error handler e collega una direttiva Resume che fornisca un bundle predefinito con status impostato su unknown. Lo scenario continua così lungo un percorso che tratta l'indirizzo come "da rivedere più tardi" invece di scartarlo. (Puoi anche impostare la gestione degli errori dello scenario su store incomplete executions, così le esecuzioni non riuscite restano in coda per un nuovo tentativo invece di sparire.)

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 controllo lento non deve mai bloccare il form.

Quando uno scenario è lo strumento sbagliato#

Make è un collante, e il collante ha un costo: ogni indirizzo verificato consuma operations, e una chiamata HTTP a ogni invio può pesare sui grandi volumi o risultare eccessiva 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 far pesare la tariffazione per operation, e una pulizia notturna o settimanale ti dà dati abbastanza aggiornati.
• Preferisci non mantenere uno scenario attivo per un'attività che serve solo ogni tanto.

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

Se stai confrontando l'approccio HTTP di Make con la chiamata diretta all'API dal tuo backend, il confronto tra API espone i pro e i contro: uno scenario Make vince sulla rapidità di configurazione e non richiede un server, mentre un'integrazione diretta vince su costi e controllo su larga scala. Lo stesso schema con il modulo HTTP si trasferisce senza problemi anche a un workflow n8n self-hosted, se la tariffazione a operations di Make ti va stretta.

Vuoi costruirlo? Prendi una chiave con scope e la forma esatta della richiesta dalla documentazione per sviluppatori, controlla un indirizzo qualsiasi con la verifica email gratuita e parti dal piano Free: 100 crediti bastano per collegare l'intero scenario e vedere un indirizzo non valido filtrato prima che arrivi alla tua lista.