E-Mail-Checker-API: Die Wahl zwischen Einzel-, Multi- und Bulk-Anfragen

Erfahren Sie, wie Sie die richtige E-Mail-Checker-API-Anfrage für jede Aufgabe auswählen und die Ergebnisse „Zustellbar“, „Nicht zustellbar“ und „Unbestimmt“ in Code abbilden.

Eine E-Mail-Checker-API sollte in einer von drei Formen aufgerufen werden, abhängig davon, wer auf das Ergebnis wartet und wie viele Adressen vorliegen. Verwenden Sie eine Einzelprüfung (POST /api/v1/check), wenn eine Person auf eine einzelne Adresse wartet, eine synchrone Multi-Adress-Prüfung (POST /api/v1/batch-check, 1–100 Adressen, Ergebnisse in der Reihenfolge der Eingabe), wenn eine kleine Gruppe gleichzeitig verarbeitet wird, und eine asynchrone Bulk-Aufgabe (POST /api/v1/bulk-tasks, gefolgt von Statusabfragen), wenn die Adressen bereits in einer Datei vorliegen. Unabhängig von der Form sollten Sie Ihren Code auf drei Ergebnisse ausrichten statt auf ein Ja/Nein-Flag: Zustellbar, Nicht zustellbar und Unbestimmt. Fehlerhafte Eingaben sollten bereits vor dem API-Aufruf abgefangen werden. Jedes abgeschlossene Ergebnis beschreibt die Adresse ausschließlich zum Zeitpunkt der Prüfung.

Was eine E-Mail-Checker-API beantwortet und was in Ihrer Verantwortung liegt

Die meisten Seiten, die zu diesem Thema ranken, listen Funktionen auf und enden dort. Die Integrationsfrage ist jedoch spezifischer: Was entscheidet ein Aufruf tatsächlich und was liegt weiterhin in der Verantwortung Ihrer Anwendung?

Die Prüfung der E-Mail-Zustellbarkeit von EmailCheckPro liefert ein abgeschlossenes Ergebnis: Zustellbar (die Adresse konnte zum Zeitpunkt der Prüfung E-Mails empfangen) oder Nicht zustellbar. Die Profilbildprüfung für E-Mails fügt ein Signal für öffentliche Profilbilder hinzu, jedoch nur für Gmail-, Yandex- und Mail.ru-Adressen.

Ihre Anwendung übernimmt weiterhin drei Aufgaben:

• Formatprüfung. Eine vollständige Adresse besteht aus einem lokalen Teil, einem @-Zeichen und einer Domain. Eine fehlerhafte Eingabe ist ein Formularfehler, kein „Nicht zustellbar“-Urteil; fangen Sie diese also ab, bevor Sie einen API-Aufruf tätigen.
• Ein Bestätigungslink oder Ihre eigenen Einverständniserklärungen decken diesen Bereich ab.
• Zeitpunkt. Ein Ergebnis bezieht sich auf den Moment der Prüfung. Speichern Sie das Datum neben dem Ergebnis, damit spätere Prozesse wissen, wie alt die Information ist.

Wenn Sie diese Grenzen im Code einhalten – und nicht nur in der Dokumentation –, vermeiden Sie die häufigsten Integrationsfehler, die unten beschrieben werden.

Die Wahl der Anfrageform für die E-Mail-Checker-API

Die drei Anfrageformen sind nicht austauschbar. Die Wahl der falschen Form ist die häufigste Ursache für langsame Formulare oder fehleranfällige Import-Jobs.

Eine schnelle Entscheidungshilfe:

1. Wartet jemand am Bildschirm? Verwenden Sie den Einzel-Endpunkt für die Adresse, die gerade eingegeben wurde.
2. Treffen die Adressen zusammen ein und sind es maximal 100? Senden Sie eine Multi-Anfrage. Diese ist weiterhin synchron: ein größerer Einzelaufruf, keine kleine Bulk-Aufgabe.
3. Ist die Quelle bereits eine Datei oder umfasst sie weit mehr als ein paar hundert Zeilen? Übermitteln Sie eine Bulk-Aufgabe und lassen Sie einen Hintergrundprozess das Ergebnis abrufen. Es gelten produktbezogene Aufgabenlimits, die in der API-Dokumentation aufgeführt sind.
4. Benötigt der Job Profilbilder? Filtern Sie die Liste zuerst nach unterstützten Gmail-, Yandex- und Mail.ru-Domains. Eine nicht unterstützte Domain wird vor einer Echtzeit-Berechnung abgelehnt; in einer Bulk-Datei für Profilbilder führt dies zum Scheitern der Vorbereitung, wobei die Reservierung zurückgegeben wird.

Für einige hundert Adressen, die nicht in einer Datei vorliegen, sind entweder mehrere Multi-Anfragen oder die Echtzeit-Prüfung des Dashboards, die bis zu 500 Adressen verarbeitet, sinnvoll.

Umsetzung der Ergebnisse in Anwendungslogik

Das Zusammenfassen von Ergebnissen zu einem booleschen Wert ist der Punkt, an dem die meisten Integrationen scheitern. Ein kleiner Statustyp hält die Bedeutung intakt:

Aus der Dokumentation ergeben sich drei Regeln:

• Bei einer einzelnen Echtzeit-Prüfung gibt eine unbestimmte Adresse einen Geschäftscode anstelle eines Ergebnisses zurück und wird nicht berechnet. Behandeln Sie diesen Zweig als eigenen Status, nicht als Fehler, den Sie in einer engen Schleife wiederholen sollten.
• In einer Multi-Antwort gibt jedes Element an, ob ein abgeschlossenes Ergebnis vorliegt. Nur Elemente mit einem solchen Ergebnis sind „Zustellbar“ oder „Nicht zustellbar“; der Rest gehört in den Zweig „Unbestimmt“ oder „Nicht abgeschlossen“.
• Ungültige, fehlgeschlagene und unbestimmte Prüfungen werden nicht berechnet. Ein erneuter Versuch kostet also nur Zeit. Planen Sie den erneuten Versuch, anstatt ihn sofort zu wiederholen.

Asynchrone Bulk-Aufgaben ohne Überraschungen ausführen

Eine Bulk-Aufgabe ist eine kleine Zustandsmaschine und gehört in einen Hintergrundprozess, nicht in eine Web-Anfrage.

1. Datei vorbereiten. Schreiben Sie TXT- oder CSV-Dateien mit einer vollständigen E-Mail-Adresse pro Zeile. Ungültige und doppelte Zeilen werden während der Vorbereitung entfernt, aber das vorherige Entfernen von offensichtlichem Müll erleichtert den Abgleich Ihrer eigenen Zählungen.
2. Übermitteln und protokollieren. Speichern Sie die Aufgabenreferenz, die von POST /api/v1/bulk-tasks zurückgegeben wird, in Ihrer Datenbank zusammen mit dem Quelldateinamen, dem verwendeten Produkt und der Übermittlungszeit. Ein abgestürzter Prozess kann dann fortfahren, anstatt die Aufgabe erneut zu übermitteln.
3. Geduldig abfragen. Fragen Sie GET /api/v1/bulk-tasks/{id} nicht häufiger als alle 30 Sekunden ab. Ein geplanter Job, der einmal prüft und dann pausiert, ist besser geeignet als eine Schleife, die eine Verbindung offen hält.
4. Zeitnah herunterladen. Eine erfolgreiche Aufgabe stellt eine CSV-Datei über einen Download-Link bereit, der 12 Stunden lang gültig ist. Wenn der Link abläuft, fragen Sie dieselbe Aufgabe erneut ab, um einen neuen Link zu erhalten, anstatt die Datei ein zweites Mal hochzuladen.
5. Nach Adresse zusammenführen. Da bei der Vorbereitung Zeilen gelöscht werden können, führen Sie die Ergebnis-CSV anhand der E-Mail-Adresse mit Ihren Datensätzen zusammen, niemals anhand der Zeilennummer.

Die Zustellbarkeits-CSV verknüpft jede Adresse mit ihrem Ergebnis. Die Profilbild-CSV gibt zusätzlich an, ob ein öffentliches Profilbild gefunden wurde, und liefert einen Link, der auch dann leer sein kann, wenn ein Profilbild vorhanden ist. Behandeln Sie einen leeren Link daher als normalen Wert.

Die tägliche Arbeit mit der Integration

Sobald die Anfrageformen und Status korrekt sind, sorgen einige Arbeitsgewohnheiten für einen reibungslosen Betrieb:

• Nur serverseitige Schlüssel. Der API-Schlüssel verbraucht das Kontoguthaben, das von Web-Prüfungen, REST-Aufrufen, Bulk-Aufgaben und MCP-Zugriffen gemeinsam genutzt wird. Geben Sie ihn niemals in Browser- oder Mobile-Code weiter.
• Prüfung zum Zeitpunkt der Änderung. Prüfen Sie, wenn eine Adresse erstellt oder bearbeitet wird, und verwenden Sie das gespeicherte Ergebnis innerhalb Ihres eigenen Zeitfensters für erneute Prüfungen wieder, anstatt bei jedem Seitenaufruf erneut anzufragen.
• Fehlertoleranz im Formular, Strenge in der Pipeline. Wenn eine Prüfung während der Registrierung langsam oder unbestimmt ist, lassen Sie die Person mit einer markierten Adresse fortfahren. In einer Versand-Pipeline halten Sie markierte Zeilen zurück, bis ein abgeschlossenes Ergebnis vorliegt.
• Schützen Sie Ihren eigenen Endpunkt. Wenn Ihre App eine Route zur Adressprüfung bereitstellt, begrenzen Sie die Rate und geben Sie konsistente Meldungen zurück. Die OWASP-Richtlinien zur E-Mail-Validierung warnen davor, Formulare preiszugeben, ob ein Konto existiert.
• Geben Sie KI-Clients den MCP-Endpunkt. https://emailcheckpro.com/mcp unterstützt Einzelprüfungen, bis zu 100 Adressen pro Aufruf, Produktauflistungen und Guthabenabfragen. Dateibasierte Bulk-Arbeiten verbleiben im Web-Workflow oder der REST-API.

Aktuelle Anfrage-Limits und Nutzungsdetails sind in der EmailCheckPro-API-Dokumentation veröffentlicht; lesen Sie diese dort nach, anstatt Annahmen fest zu kodieren.

Eine Formatprüfung, die den Erwartungen der API entspricht

Der günstigste Aufruf ist der, den Sie für fehlerhafte Eingaben gar nicht erst tätigen. Zwei Referenzen helfen Ihnen bei der Wahl einer sinnvollen Prüfung:

• Der WHATWG HTML-Standard definiert das Muster, das Browser für type="email"-Felder verwenden. Er weicht bewusst von den vollständigen E-Mail-Standards ab, um praktikabel zu bleiben, was ihn auch zu einer vernünftigen serverseitigen Basis macht.
• RFC 5321 beschreibt die Adressformen, die beim E-Mail-Transport verwendet werden. Betrachten Sie dies als Format-Referenz für Grenzfälle wie zitierte lokale Teile, nicht als Beschreibung der Funktionsweise eines Prüfdienstes.

In der Praxis: Entfernen Sie Leerzeichen, entfernen Sie nachgestellte Satzzeichen, die aus Dokumenten kopiert wurden, schreiben Sie die Domain klein, behalten Sie den lokalen Teil wie eingegeben bei und lehnen Sie nur Eingaben ab, denen eindeutig ein lokaler Teil, ein @ oder eine Domain fehlt. Zu strenge Muster, die Pluszeichen oder lange Top-Level-Domains ablehnen, weisen echte Benutzer ab und sollten vermieden werden.

FAQ

Wann sollten Teams von Multi-Adress-Aufrufen auf eine Bulk-Aufgabe umsteigen?

Steigen Sie um, wenn die Adressen bereits in einer Datei vorliegen oder wenn ein Job viele aufeinanderfolgende Multi-Aufrufe benötigen würde, um eine Liste abzuarbeiten. Multi-Anfragen eignen sich für Gruppen von bis zu 100 Adressen, die zusammen eintreffen und Antworten in derselben Antwort benötigen. Bulk-Aufgaben eignen sich für vorbereitete Exporte, die warten können, da das Ergebnis später als eine CSV-Datei eintrifft und der Prozess den Status nur alle 30 Sekunden oder seltener abfragen muss.

Wie sollte eine Anwendung E-Mail-Checker-API-Ergebnisse speichern?

Speichern Sie die Adresse wie eingegeben, das verwendete Produkt, das Ergebnis in einfachen Worten, das Prüfdatum und die Quelle der Adresse. Dieser Datensatz ermöglicht es dem Support, eine Entscheidung zu erklären, lässt Jobs zur erneuten Prüfung zuerst die ältesten Ergebnisse auswählen und hält unbestimmte oder nicht abgeschlossene Zeilen von „Nicht zustellbar“-Ergebnissen getrennt. Vermeiden Sie es, rohe Antwort-Payloads als einzigen Datensatz zu speichern, da andere Systeme sonst vom Format der API abhängig wären.

Kann ein „Zustellbar“-Ergebnis eine Bestätigungs-E-Mail ersetzen?

Nein. Ein „Zustellbar“-Ergebnis informiert darüber, ob die Adresse zum Zeitpunkt der Prüfung E-Mails empfangen konnte; die Prüfung selbst sendet nichts. Ein Bestätigungslink beantwortet eine andere Frage: ob die Person, die die Adresse eingegeben hat, diese kontrolliert und dem Empfang von Nachrichten zustimmt. Viele Registrierungsprozesse nutzen die Prüfung, um tote Adressen vor dem Versand abzufangen, und verlassen sich dann auf die Bestätigung für Einverständnis und Eigentumsnachweis.

Was ist der sicherste Weg, um Prüfungen zu wiederholen, die nicht abgeschlossen wurden?

Stellen Sie diese in eine Warteschlange mit einer Verzögerung, anstatt sie in der Anfrage zu wiederholen, die fehlgeschlagen ist. Unbestimmte, fehlgeschlagene und ungültige Prüfungen werden nicht berechnet, aber sofortige Wiederholungen ändern das Ergebnis selten und können Ihren eigenen Dienst verlangsamen. Eine geplante Wiederholung mit einer Begrenzung der Versuche und einer Notiz über das Datum jedes Versuchs hält die Aufzeichnungen korrekt und ermöglicht es Prüfern zu sehen, welche Adressen noch kein abgeschlossenes Ergebnis haben.

Mehr erfahren

Wählen Sie die Produktinformationen, die zum nächsten Schritt in Ihrem Workflow passen.

• Zur Produktdokumentation →
• Kontakt zum Team →