Migrare da Emailable

Questa guida spiega come sostituire le chiamate di verifica di Emailable con Mailbeam. La maggior parte delle migrazioni richiede fra i 30 e i 60 minuti: il lavoro è cambiare una richiesta e tradurre la stringa state di Emailable nel booleano più punteggio di Mailbeam.

Perché si cambia

• Residenza del dato nell'UE: Emailable tratta i dati su infrastruttura statunitense, quindi un'azienda europea ha bisogno di clausole contrattuali tipo; Mailbeam tratta a Francoforte con un DPA in tutti i piani
• Fatto per i moduli: la latenza di Emailable per un indirizzo si aggira sui 250 ms, lenta per validare mentre qualcuno sta ancora scrivendo
• Catch-all graduato: Emailable restituisce i domini accept-all come risky o unknown senza niente su cui fissare una soglia; Mailbeam aggiunge un punteggio da 0 a 100 e un reason
• Prezzi che si possono isolare: i pacchetti di crediti più i complementi di recapitabilità con prezzo a parte rendono difficile leggere quanto costi la verifica in sé
• Modalità di prova: una modalità deterministica per la CI, invece di chiamare la produzione

Una cosa gioca davvero a favore di Emailable: offre test di collocazione in posta in arrivo con indirizzi seme e monitoraggio continuo della recapitabilità, cosa che Mailbeam deliberatamente non fa. Le squadre che ne hanno bisogno di solito restano su Emailable per la recapitabilità e spostano solo la verifica.

Corrispondenza fra endpoint

Autenticazione

Emailable passa la chiave API come parametro nell'URL, il che significa che finisce nei registri d'accesso, nella cronologia del browser e nelle tracce dei proxy. Mailbeam prende un token Bearer nell'intestazione, così la credenziale resta fuori dall'URL.

Emailable (prima):

curl "https://api.emailable.com/v1/verify?email=user@example.com&api_key=YOUR_KEY"

Mailbeam (adesso):

curl -X POST https://api.mailbeam.dev/v1/verify \
  -H "Authorization: Bearer $MAILBEAM_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email": "user@example.com"}'

Corrispondenza fra risposte

Emailable riporta tutto con un'unica stringa state. Mailbeam distribuisce la stessa informazione su un booleano su cui ramificare e un punteggio con cui fissare soglie.

Migrare la chiamata

Emailable (prima):

const res = await fetch(
  `https://api.emailable.com/v1/verify?email=${email}&api_key=${apiKey}`
);
const { state } = await res.json();
if (state !== "deliverable") return 422;

Mailbeam (adesso):

// Nessun SDK da installare: vedi /docs/quickstart per questo wrapper di 12 righe.
import { verifyEmail } from "./lib/mailbeam.js";

const { valid, score, reason } = await verifyEmail(email);
if (!valid || score < 60) return 422;

Guarda che cosa faceva il vecchio ramo: state !== "deliverable" rifiuta risky e unknown insieme ai fallimenti veri. Se il tuo imbuto di registrazione stava scartando in silenzio indirizzi aziendali accept-all, è lì che succedeva.

La prima cosa da rivedere: risky e unknown

Emailable mette due situazioni diverse in stringhe che devi interpretare tu. Un dominio accept-all e un server che si è rifiutato di rispondere arrivano entrambi come qualcosa di diverso da deliverable, e la maggior parte delle integrazioni li rifiuta tutti e due. Mailbeam li separa, così puoi decidere una volta e per ciascun caso:

const { valid, status, catchAll, score, reason } = await verifyEmail(email);

if (status === "unknown") {
  // Il server non ha voluto rispondere: greylisting, tempo scaduto, rifiuto temporaneo.
  // Questo non è la prova che la casella sia cattiva. Accetta e riverifica più tardi.
  return acceptPendingReverification();
}

if (catchAll) {
  return score >= 70 ? accept() : challenge({ reason });
}

return valid ? accept() : reject({ reason });

Prossimi passi

• Riferimento dell'API — POST /v1/verify
• Punteggio dei catch-all
• Mailbeam a confronto con Emailable
• Prezzi