Die E-Mail-Validierung in Echtzeit prüft eine Adresse, während der Nutzer noch in Ihrem Formular ist. Sie läuft in den wenigen hundert Millisekunden zwischen „Absenden“ und dem nächsten Bildschirm und beantwortet eine Frage: Sollte diese Adresse in Ihre Datenbank aufgenommen werden? Eine E-Mail-Validierungs-API in Echtzeit trifft diese Entscheidung für Sie. Sie prüft Syntax, Domain und deren MX-Einträge, Einweg- und Rollen-Signale, das Catch-all-Verhalten und auf Wunsch auch das Postfach selbst. Anschließend gibt sie ein strukturiertes Ergebnis zurück, auf das Ihr Code reagieren kann.
Dieser Leitfaden richtet sich an Entwickler, die diese Prüfung zu einem Registrierungs-, Checkout- oder Lead-Formular hinzufügen. Er behandelt, was die Prüfungen leisten, wie Sie eine API aufrufen, wie Sie jeden Status in eine Produktentscheidung umwandeln und wie Sie schnell bleiben, wenn ein Mailserver langsam ist. Die Beispiele verwenden die BillionVerify-E-Mail-Validierungs-API, aber die Designempfehlungen gelten für jeden Anbieter.
Was ist eine E-Mail-Validierung in Echtzeit?
Eine E-Mail-Validierung in Echtzeit ist eine Prüfung, die in dem Moment ausgeführt wird, in dem eine Adresse eingegeben wird – nicht erst Tage später, wenn eine Kampagne versendet wird. Der Nutzer gibt eine Adresse ein. Ihr Frontend oder Backend sendet sie an eine E-Mail-Prüfungs-API. Die API antwortet mit einem Status wie valid, invalid oder catchall sowie den zugrunde liegenden Signalen. Ihre Anwendung erlaubt dann die Registrierung, blockiert sie oder fordert den Nutzer auf, einen Tippfehler zu korrigieren.
Der entscheidende Punkt ist das Timing. Ein Tippfehler wie gmial.com kostet nichts, solange der Nutzer noch im Formular ist. Sobald die Willkommens-E-Mail zurückgewiesen wird, kostet Sie derselbe Tippfehler den Kunden. Falsche Adressen schaden außerdem Ihrer Absender-Reputation, denn jeder Hard Bounce teilt den Mailbox-Providern mit, dass Sie an unbestätigte Adressen senden. Die E-Mail-Verifizierung in Echtzeit hält sie bereits an der Tür auf.
Sie hilft auch gegen Betrug: Eine Echtzeitprüfung kann ein Wegwerf-Postfach erkennen, bevor das Konto existiert.
Echtzeit- vs. Bulk-E-Mail-Verifizierung
Beide Ansätze verwenden dieselben Prüfungen. Sie unterscheiden sich darin, wann sie ausgeführt werden und wie viel Zeit ihnen zur Verfügung steht.
- Echtzeit-Verifizierung wird jeweils für eine einzelne Adresse innerhalb einer Benutzeranfrage ausgeführt. Sie hat ein striktes Zeitlimit, oft deutlich unter einer Sekunde, da ein langsames Formular Anmeldungen kostet. Sie verhindert, dass fehlerhafte Daten aufgenommen werden.
- Bulk-Verifizierung wird im Hintergrund für eine vollständige Liste ausgeführt. Sie kann Minuten oder Stunden dauern, und niemand wartet auf einem Bildschirm. Sie bereinigt Daten, die sich bereits in Ihrem System befinden, beispielsweise vor einer großen Kampagne oder nach einem CRM-Import.
Die meisten Teams benötigen beides. Echtzeit-Prüfungen halten neue Daten sauber, und eine regelmäßige Bulk-E-Mail-Verifizierung erkennt Adressen, die im Laufe der Zeit ungültig geworden sind, etwa von Mitarbeitern, die ein Unternehmen verlassen haben. Einen ausführlicheren Vergleich finden Sie unter Echtzeit- vs. Bulk-E-Mail-Verifizierung.
Was eine Echtzeitprüfung tatsächlich testet
Eine API zur E-Mail-Verifizierung führt eine Reihe von Prüfungen durch, von günstig bis aufwendig. Jede Prüfung schließt eine andere Art ungültiger Adresse aus.
Syntax
Die erste Prüfung betrifft das Format. Gibt es genau ein @? Besteht der lokale Teil aus zulässigen Zeichen? Sieht die Domain wie eine Domain aus? Die Syntaxprüfung lehnt offensichtlichen Datenmüll wie john@@example oder jane.example.com ab. Sie ist schnell und benötigt keinen Netzwerkaufruf. Eine perfekte Syntax sagt jedoch nichts darüber aus, ob das Postfach existiert.
Domain- und MX-Einträge
Als Nächstes fragt die API die Domain über DNS ab. Eine Domain ohne MX-Einträge kann keine E-Mails empfangen, daher ist eine Adresse dort nutzlos, ganz gleich, wie sauber sie aussieht. Dadurch werden falsch geschriebene Domains und nicht mehr aktive Unternehmensdomains erkannt. BillionVerify gibt die gefundenen MX-Hosts in mx_records zurück, und domain_suggestion kann eine wahrscheinliche Korrektur enthalten, wenn die Domain wie ein Tippfehler einer häufig verwendeten Domain aussieht.
Hinweise auf Wegwerf-, Rollen- und kostenlose Anbieter
Einige Adressen existieren, passen aber trotzdem schlecht zu deinem Produkt:
- Wegwerfadressen stammen von temporären Postfachdiensten und funktionieren normalerweise nur wenige Stunden. Siehe wie die Erkennung von Wegwerf-E-Mail-Adressen funktioniert.
- Rollenadressen wie
info@odersupport@gehen an ein Team, nicht an eine Person. Sie sind normalerweise zustellbar, zeigen aber tendenziell weniger Engagement. - Adressen kostenloser Anbieter wie Gmail sind für Verbraucher normal, sollten in einem B2B-Formular jedoch erfasst werden.
Die API meldet diese als Flags (is_disposable, is_role, is_free), sodass du je nach Produkt entscheiden kannst.
Catch-all-Domains
Einige Mailserver akzeptieren E-Mails für jede Adresse ihrer Domain, unabhängig davon, ob sie tatsächlich existiert. Bei diesen Catch-all-Domains kann eine Postfachprüfung nicht beweisen, dass ein bestimmtes Postfach existiert. Ein Catch-all-Ergebnis ist kein schlechtes Ergebnis. Es bedeutet, dass die Sicherheit geringer ist, sodass der Score wichtiger ist als das Label. Erkennung von Catch-all-E-Mail-Adressen erklärt, wie dies funktioniert und warum es wichtig ist.
SMTP-Postfachprüfung
Bei der gründlichsten Prüfung wird der Mailserver des Empfängers über SMTP gefragt, ob er eine Nachricht annehmen würde, ohne eine Nachricht zu senden. Dadurch werden Adressen auf realen Domains gefunden, die nicht mehr existieren, etwa das Postfach eines ehemaligen Mitarbeiters. Dieser Schritt ist auch der langsamste, da er vom Server einer anderen Person abhängt. In BillionVerify wird er durch den Parameter check_smtp gesteuert. Wenn du ihn weglässt, führt die API die SMTP-Prüfung durch; sende check_smtp: false, um sie zu überspringen.
Domain-Reputation
BillionVerify kann außerdem ein domain_reputation-Objekt mit Blacklist-Ergebnissen für die IP-Adresse des Mailservers der Domain zurückgeben. Es dient ausschließlich der Information: Es ändert weder den Status noch den Score oder die Kosten.
So rufen Sie eine E-Mail-Validierungs-API in Echtzeit auf
Mit BillionVerify ist eine einzelne Echtzeitprüfung eine HTTPS-Anfrage. Die Basis-URL lautet https://api.billionverify.com/v1, und Ihr API-Schlüssel gehört in den Header BV-API-KEY. Bewahren Sie diesen Schlüssel auf Ihrem Server auf. Binden Sie ihn niemals in Browser-Code ein.
Hier ist eine minimale Anfrage, basierend auf der API-Referenz:
curl -X POST https://api.billionverify.com/v1/verify/single \
-H "BV-API-KEY: sk_xxx" \
-H "Content-Type: application/json" \
-d '{"email":"test@example.com","check_smtp":true}'
Die Anfrage akzeptiert drei Parameter:
| Parameter | Standardwert | Funktion |
|---|---|---|
email | erforderlich | Die zu validierende Adresse |
check_smtp | aktiviert | Auf false setzen, um die Live-SMTP-Postfachprüfung zu überspringen |
force_refresh | false | Überspringt zwischengespeicherte Ergebnisse; das aktuelle Ergebnis wird wie eine neue Prüfung abgerechnet |
Eine erfolgreiche Antwort kapselt das Ergebnis in einem standardmäßigen Umschlag. Hier ist ein gekürztes Beispiel für eine zustellbare Adresse:
{
"success": true,
"code": "0",
"message": "Success",
"data": {
"email": "user@example.com",
"status": "valid",
"score": 0.95,
"is_deliverable": true,
"is_disposable": false,
"is_catchall": false,
"is_role": false,
"is_free": false,
"domain": "example.com",
"mx_records": ["mail.example.com"],
"check_smtp": true,
"reason": "smtp_deliverable",
"domain_suggestion": "",
"response_time": 250,
"credits_used": 1
}
}
Wenn Sie ein SDK bevorzugen, veröffentlicht BillionVerify offizielle SDKs für Node.js, Python, TypeScript, Go, PHP und Java. In Node.js erhalten Sie mit npm install billionverify-sdk einen Client mit einer verify-Methode; in Python lautet der Paketname billionverify.
Die Antwort lesen: Status, Score und Grund
Das Feld status ist ausschlaggebend für die meisten Code-Zweige. Hier sehen Sie, was die einzelnen Statuswerte bedeuten, sowie eine sinnvolle Standardeinstellung für ein Anmeldeformular:
| Status | Bedeutung | Standard für Anmeldeformular |
|---|---|---|
valid | Das Postfach existiert und kann E-Mails empfangen | Akzeptieren |
invalid | Die Adresse existiert nicht oder kann keine E-Mails empfangen | Blockieren und nach einer anderen Adresse fragen |
disposable | Ein temporäres Postfach | Blockieren oder mit Einschränkungen akzeptieren |
catchall | Die Domain akzeptiert jede Adresse | Akzeptieren und überwachen |
role | Ein gemeinsames Postfach wie info@ | Akzeptieren, eventuell für den Vertrieb markieren |
unknown | Die E-Mail-Zustellbarkeit konnte nicht bestätigt werden | Akzeptieren und später erneut prüfen |
Der score liefert ein genaueres Signal zwischen 0 und 1. Als grobe Orientierung erzielen valid-Ergebnisse einen Score von 0,85 bis 1,0, catchall etwa 0,55 bis 0,75, unknown 0,3 bis 0,6, disposable 0,1 und invalid 0. Ein role-Ergebnis behält den Score der zugrunde liegenden Prüfung. Sie können den Score verwenden, um Ihren eigenen Schwellenwert für Grenzfälle festzulegen, beispielsweise um Catch-all-Adressen in einem Formular mit hohem Wert nur oberhalb eines bestimmten Scores zu akzeptieren.
Das Feld reason erklärt die Bewertung. Ein invalid-Ergebnis kann mit invalid_syntax, no_mx_records oder mailbox_not_found einhergehen, wobei jeder Grund auf eine andere Benutzernachricht hinweist. Ein Syntaxproblem bedeutet „Format überprüfen“. Ein fehlendes Postfach bedeutet „Dieses Postfach existiert nicht“. Die Seite Gründe für die Verifizierung listet alle Gründe auf und erklärt, bei welchen unknown-Gründen sich ein erneuter Versuch lohnt.
Zwei Felder helfen dem Benutzer direkt: domain_suggestion kann einen Hinweis wie „Meinten Sie gmail.com?“ bereitstellen, und is_disposable erklärt, warum eine Wegwerfadresse abgelehnt wurde.
Den Anmeldeprozess an einem Latenzbudget ausrichten
Die größte Herausforderung besteht darin, die Prüfung in ein Formular zu integrieren, ohne es zu verlangsamen. Beginnen Sie mit einem Budget. Legen Sie fest, wie lange Sie den Nutzer beispielsweise beim Absenden warten lassen möchten: 300 bis 500 Millisekunden. Alles Weitere ergibt sich aus dieser Zahl.
Der Produkttext von BillionVerify nennt für zwischengespeicherte Ergebnisse weniger als 200 ms und für eine vollständige SMTP-Prüfung durchschnittlich 1–3 Sekunden. Diese Lücke lässt Ihnen zwei gute Designs:
- Vollständige Prüfung mit Timeout. Rufen Sie die API mit aktiviertem SMTP und einem Timeout von 2–3 Sekunden auf. Die meisten Antworten treffen rechtzeitig ein und liefern Ihnen ein eindeutiges
validoderinvalid. Wenn das Timeout ausgelöst wird, lassen Sie die Anfrage zunächst durch und prüfen Sie später erneut. - Jetzt schnell prüfen, später gründlich prüfen. Rufen Sie die API mit
check_smtp: falseauf. Damit lassen sich nur eindeutige Fälle klären: fehlerhafte Syntax, eine Domain ohne MX-Einträge sowie Wegwerf- und Funktionsadressen. Eine Adresse auf einer funktionierenden Domain wird mitunknownund dem Grundsmtp_unverifiablezurückgegeben, was erwartungsgemäß ist. Akzeptieren Sie sie und führen Sie anschließend aus einem Hintergrundprozess einen zweiten Aufruf mit aktiviertem SMTP durch. Wenn das Postfach nicht existiert, markieren Sie das Konto und bitten Sie den Nutzer, seine Adresse zu bestätigen.
Einige Gewohnheiten im Frontend helfen ebenfalls:
- Beim Verlassen des Feldes oder beim Absenden validieren, nicht bei jedem Tastendruck. Die Prüfung von
j,jo,johverschwendet Aufrufe und Credits. - Lokale Syntaxprüfungen zuerst durchführen, um bei offensichtlichen Fehlern einen Roundtrip zu sparen.
- Die API vom Backend aus aufrufen. Ihr Server verwahrt den API-Schlüssel und protokolliert das Ergebnis; der Browser zeigt nur das Resultat an.
Details zur UX, etwa zur Formulierung, Platzierung von Fehlermeldungen und dem Zeitpunkt für einen Hinweis, finden Sie unter E-Mail-Verifizierung während der Anmeldung.
Fail Open oder Fail Closed? Umgang mit Timeouts und unbekannten Ergebnissen
Das Muster, das für die meisten Produkte funktioniert, lautet: Bei eindeutigen Fehlern Fail Closed, bei Unsicherheit Fail Open.
- Fail Closed bedeutet, dass du die Anmeldung blockierst. Tu das, wenn die API sagt, dass die Adresse eindeutig ungültig ist:
invalidmitinvalid_syntaxoderno_mx_records, oder einedisposable-Adresse in einem Formular, bei dem Wegwerfkonten Schaden verursachen. - Fail Open bedeutet, dass du den Nutzer durchlässt und später nachfasst. Tu das, wenn das Ergebnis unsicher ist: ein
unknown-Status, eine Catch-all-Domain oder wenn dein eigener Timeout abläuft, bevor die API antwortet.
Warum sollte man unsichere Adressen nicht ebenfalls blockieren? Dahinter stehen viele echte Personen. Unternehmens-Mailserver setzen SMTP-Prüfungen häufig auf Greylisting oder begrenzen deren Rate, sodass ihre Blockierung echte Anmeldungen kostet. Akzeptiere die Adresse, markiere den Datensatz und prüfe ihn später erneut.
Setze für deinen API-Aufruf einen clientseitigen Timeout, der zu deinem Latenzbudget passt. Wenn er auslöst, behandle das Ergebnis als unknown: akzeptiere es, speichere ein Kennzeichen und stelle eine erneute Prüfung im Hintergrund in die Warteschlange. Wiederhole Prüfungen mit dem Ergebnis unknown später, statt innerhalb der Anfrage.
Beispiel: Eine E-Mail bei der Registrierung in Node.js validieren
Die folgende Skizze zeigt die schnelle Prüfung (Design 2) in einem Registrierungs-Handler. Sie verwendet den dokumentierten REST-Endpunkt und die Antwortfelder, ein Timeout sowie die oben genannten Regeln für Fail-Open oder Fail-Closed. Passe die Namen an dein Framework an.
const BLOCK = new Set(['invalid', 'disposable']);
async function checkEmail(email) {
const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), 400);
try {
const response = await fetch('https://api.billionverify.com/v1/verify/single', {
method: 'POST',
headers: {
'BV-API-KEY': process.env.BV_API_KEY,
'Content-Type': 'application/json',
},
body: JSON.stringify({ email, check_smtp: false }),
signal: controller.signal,
});
const body = await response.json();
if (!body.success) return { allow: true, recheck: true };
const { status, reason, domain_suggestion } = body.data;
if (BLOCK.has(status)) {
return { allow: false, reason, suggestion: domain_suggestion };
}
return { allow: true, recheck: status === 'unknown' || status === 'catchall' };
} catch {
// Timeout or network error: fail open and re-check in the background.
return { allow: true, recheck: true };
} finally {
clearTimeout(timer);
}
}
Ohne SMTP kommen die meisten echten Adressen mit dem Status unknown zurück und erhalten das recheck-Flag. Nachdem das Konto gespeichert wurde, ruft ein Hintergrundjob für jeden mit recheck markierten Datensatz denselben Endpunkt mit aktiviertem SMTP auf. Das Node.js-Tutorial führt durch eine ausführlichere Einrichtung einschließlich des offiziellen SDK. Dieselbe Anfrage funktioniert mit Python oder jeder Sprache mit einem HTTP-Client.
Rate-Limits, Caching und Kosten
Eine Echtzeitprüfung ist Teil deines Registrierungsprozesses, daher werden ihre Limits zu deinen Limits. Plane entsprechend.
Rate-Limits. BillionVerify schützt seine Kapazität mit kontobezogenen Limits. Wenn du eines erreichst, gibt die API HTTP 429 mit dem Code 1003 und einem Retry-After-Header zurück. Fahre die Anfragen zurück und wiederhole sie, und behalte deine eigene Fail-Open-Regel bei, damit ein Limit niemals einen echten Nutzer blockiert.
Caching. Ergebnisse werden zwischengespeichert, weshalb wiederholte Prüfungen schnell zurückkommen. Eine erneute Prüfung einer Adresse, die dein Konto in den letzten 24 Stunden verifiziert hat, ist kostenlos. Verwende force_refresh: true nur, wenn du wirklich eine aktuelle Antwort benötigst, da dadurch der Cache übersprungen und die Prüfung wie eine neue abgerechnet wird.
Kosten. Eine einzelne Prüfung verwendet normalerweise 1 Guthaben, angezeigt in credits_used. Jedes unknown-Ergebnis ist kostenlos, ebenso Syntaxfehler. Validiere beim Absenden statt bei jedem Tastendruck und prüfe eine Adresse nicht erneut, wenn du sie erst kürzlich verifiziert hast. BillionVerify gibt dir jeden Tag, an dem du dich anmeldest, 20 kostenlose Guthaben, bis zu 600 pro Monat – genug, um eine Integration zu entwickeln und zu testen. Kostenpflichtige Guthabenpakete findest du auf der Preisseite.
Über das Formular hinaus: Stapelverarbeitung, Dateien und Webhooks
Die Echtzeitvalidierung prüft neue Adressen einzeln. Für alles andere bietet dieselbe API weitere Einstiegspunkte:
- Kleine Stapel.
POST /verify/bulkprüft bis zu 50 Adressen in einer Anfrage – ideal für eine CRM-Synchronisierung oder einen Importbildschirm. - Große Listen.
POST /verify/fileakzeptiert eine CSV-, TXT- oder XLSX-Datei und verarbeitet sie im Hintergrund. - Webhooks. Statt einen Datei-Job regelmäßig abzufragen, registrieren Sie einen Webhook für die Ereignisse
file.completedundfile.failed. Weitere Informationen zu E-Mail-Verifizierungs-Webhooks sowie Signaturprüfungen und Wiederholungsversuchen finden Sie im Leitfaden. - Prüfungen nur auf Wegwerf-Adressen.
POST /verify/disposablebeantwortet ausschließlich die Frage, ob es sich um eine Wegwerf-Adresse handelt, und verbraucht keine Credits.
Eine gängige Einrichtung: Echtzeitprüfungen bei jedem Formular, ein nächtlicher Stapel für Datensätze mit der Markierung recheck und ein Datei-Job vor großen Kampagnen.
Checkliste für die E-Mail-Verifizierung in Echtzeit
Bevor du veröffentlichst, gehe diese Liste durch:
- Der API-Schlüssel befindet sich auf dem Server, niemals im Browser.
- Die Syntax wird lokal vor dem API-Aufruf geprüft.
- Der Anfragepfad verwendet
check_smtp: falseund einen Timeout, der zu deinem Latenzbudget passt. - Für
invalidunddisposablegibt es klare, spezifische Fehlermeldungen. unknown,catchallund Timeouts werden standardmäßig zugelassen und für eine erneute Prüfung in die Warteschlange eingereiht.domain_suggestionliefert einen Hinweis auf Tippfehler.- Bei 429-Antworten wird die Anfrageverarbeitung verlangsamt, ohne Nutzer zu blockieren.
- Die Ergebnisse werden zusammen mit dem Nutzerdatensatz gespeichert, damit du später die Bounce-Raten messen kannst.
FAQ
Was ist eine E-Mail-Verifizierungs-API in Echtzeit?
Eine E-Mail-Verifizierungs-API in Echtzeit prüft eine einzelne E-Mail-Adresse, während ein Benutzer ein Formular absendet, und liefert innerhalb eines Sekundenbruchteils ein Ergebnis. Sie führt Syntax-, Domain-, MX-, Wegwerf-, Rollen- und Catch-all-Prüfungen sowie optional eine SMTP-Postfachprüfung durch, sodass Ihre App die Adresse akzeptieren, blockieren oder markieren kann, bevor sie Ihre Datenbank erreicht.
Wie unterscheidet sich die E-Mail-Verifizierung in Echtzeit von der Massenverifizierung?
Bei der E-Mail-Verifizierung in Echtzeit wird jeweils eine Adresse innerhalb einer Benutzeranfrage geprüft, und die Antwort muss schnell erfolgen. Bei der Massenverifizierung wird eine gesamte Liste im Hintergrund geprüft, was deutlich länger dauern kann. Verwenden Sie Echtzeitprüfungen, um neue Daten sauber zu halten, und Massenprüfungen, um bereits vorhandene Daten zu bereinigen.
Sollte ich die SMTP-Prüfung bei jeder Anmeldung ausführen?
Das hängt von Ihrem Latenzbudget ab. Die SMTP-Prüfung bestätigt ein Postfach. Ohne sie werden die meisten echten Adressen als unknown zurückgegeben. Wenn Sie 2–3 Sekunden warten können, führen Sie sie beim Absenden mit einem Timeout aus. Falls nicht, verwenden Sie die schnelle Prüfung mit check_smtp: false und führen Sie die SMTP-Prüfung in einem Hintergrundprozess aus.
Was sollte ich mit Catch-all- und unbekannten Ergebnissen tun?
Akzeptieren Sie sie und prüfen Sie sie später erneut. Eine Catch-all-Domain akzeptiert jede Adresse, daher kann eine Postfachprüfung nicht beweisen, dass der Posteingang existiert, und ein unbekanntes Ergebnis bedeutet, dass die Prüfung nicht abgeschlossen werden konnte. Wenn Sie diese Benutzer blockieren, verlieren Sie echte Anmeldungen. Wenn Sie sie markieren und erneut prüfen, bleiben Ihre Daten sauber, ohne die Conversion zu beeinträchtigen.
Kann ich die API des E-Mail-Prüfers aus dem Browser aufrufen?
Nein. Dadurch wird Ihr API-Schlüssel offengelegt. Rufen Sie die API von Ihrem Backend aus auf und geben Sie nur die Entscheidung zurück.
Wie schnell ist die E-Mail-Verifizierung in Echtzeit?
Mit BillionVerify werden zwischengespeicherte Ergebnisse in weniger als 200 ms zurückgegeben, und eine vollständige SMTP-Prüfung dauert durchschnittlich 1–3 Sekunden. Deshalb gehört die schnelle Prüfung ohne SMTP in den Anfragepfad und die SMTP-Prüfung in den Hintergrund.
Wie viel kostet eine E-Mail-Verifizierungs-API?
Bei BillionVerify verwendet eine einzelne Prüfung normalerweise 1 Guthaben, und jedes unknown-Ergebnis ist kostenlos. Sie erhalten täglich 20 kostenlose Guthaben, wenn Sie sich anmelden, bis zu 600 pro Monat. Kostenpflichtige Guthabenpakete finden Sie auf der Preisseite. force_refresh überspringt den Cache und wird wie eine neue Prüfung abgerechnet.
Beginnen Sie mit der E-Mail-Validierung in Echtzeit
E-Mail-Validierung in Echtzeit bedeutet weniger Bounces, weniger Fake-Konten und weniger verlorene Nutzer durch Tippfehler. Fügen Sie eine schnelle Prüfung in den Anfragepfad ein, verschieben Sie die langsame Prüfung in den Hintergrund und lassen Sie eindeutige Fehler blockieren, während unsichere Ergebnisse durchgelassen werden. Erstellen Sie ein kostenloses BillionVerify-Konto, erhalten Sie einen API-Schlüssel und führen Sie Ihren ersten API-Aufruf zur E-Mail-Validierung aus der obigen Dokumentation durch.