Email-Finder-API: vier Dinge, die in keiner Doku stehen

Die Endpoints gleichen sich bei allen Anbietern; die vier Antworten, die über deine Rechnung entscheiden, gibt kaum einer.

Das Wichtigste in Kürze Einer Email-Finder-API übergibst du eine Person, die du schon identifiziert hast, meistens Name plus Firma, und bekommst dafür eine verifizierte geschäftliche E-Mail-Adresse. Die Endpoints sehen bei allen Anbietern ungefähr gleich aus. Vier Fragen beantwortet fast keiner, und genau die entscheiden über deine Rechnung und über deine Architektur. Wird der Versuch abgerechnet oder das geprüfte Ergebnis? Wie lange dauert eine Suche, und blockiert sie dabei? Was sagt die Antwort verbindlich aus? Wird eine Catch-all-Adresse entschieden, oder bleibt sie dein Problem? Eine fünfte Frage wird erst bei großen Mengen wichtig: was das Rate-Limit bei einem Lauf über 50.000 Zeilen bedeutet. Enrows Antworten zum Vergleich: Berechnet wird nur ein gültiges Ergebnis, jeder Endpoint arbeitet asynchron, Catch-all-Adressen werden geprüft statt nur markiert, 10 Anfragen je Sekunde auf POST, Bulk-Läufe bis 5.000 Zeilen. Lies die Angaben zur Abrechnung vor der Feature-Liste. Sie beeinflussen die echten Kosten stärker als der Listenpreis.

Eine Email-Finder-API ist ein HTTP-Endpoint, der zu einer Person die geschäftliche E-Mail-Adresse ermittelt. Du schickst einen Namen und eine Firma hin. Heraus kommt eine Adresse, dazu irgendeine Aussage darüber, ob es sie gibt.

Vorweg eine Abgrenzung, weil die Suche nach „email api“ überwiegend etwas anderes ausspuckt: Versanddienste und Relays für Transaktions-E-Mails. Diese verschicken Nachrichten. Eine Finder-API klärt vorher, welche Adresse zu einer Person gehört, und zu diesem Zeitpunkt existiert noch gar keine Nachricht.

Die vier Kriterien unten sind entstanden, als wir unsere eigene API entwickelt und parallel ein Dutzend Anbieter-Dokumentationen gelesen haben. Endpoint-Listen sind austauschbar. Das Abrechnungsmodell, die Zusage zur Latenz, die Form der Antwort und der Umgang mit Catch-all-Adressen sind es nicht, und alle vier stehen üblicherweise weit hinten. Die Bulk-Obergrenze zählt ebenfalls, aber erst, wenn dein Volumen wirklich groß wird. Sie bekommt deshalb einen eigenen Abschnitt danach.

1. Zahlst du für den Versuch oder für das geprüfte Ergebnis?

Zahlst du für Fehlschläge mit, kostet dich jeder gefundene Kontakt mehr als das Dreifache einer einzelnen Suche.

Daran hängt alles. Und genau diese Angabe fehlt auf den meisten Preisseiten.

Es gibt zwei Modelle. Beim Preis je Versuch kostet schon die Anfrage Geld: Der Anbieter sucht, findet nichts Brauchbares und bucht trotzdem einen Credit ab. Beim zweiten Modell zahlst du nur für ein verifiziertes Ergebnis: Ein Fehlschlag kostet nichts, und der Zähler springt erst an, wenn eine zustellbare Adresse da ist.

Der Unterschied ist keine Rundungsdifferenz. Die meisten Anbieter veröffentlichen überhaupt keine Trefferquote, deshalb nehme ich für eine kalte B2B-Liste 30 % als Arbeitsannahme. Bei 30 % zahlst du im Modell je Versuch für jeden Kontakt, den du am Ende hast, mehr als das Dreifache. Danach kommt ein Teil der Treffer als Bounce zurück, und auch dafür hast du schon bezahlt.

Ein paar Anbieter sagen das ausdrücklich, und das ist etwas wert. Anymail Finder zieht einen Credit erst ab, wenn die Adresse verifiziert ist. Bei Findymail gilt dasselbe, ein Credit für eine gefundene Adresse. ZeroBounce berechnet die erfolgreiche Suche und verlangt für eine ungeklärte nichts.

Enrows Finder-Endpoints arbeiten genauso, und im Bulk lässt sich die Abrechnung nachrechnen. Ein Bulk-GET liefert stats.credits_cost als drei Zahlen: initial, refunded, final. Beim Start des Laufs werden Credits abgebucht, danach gibt es für jede leere Zeile eine Gutschrift. Das dokumentierte Beispiel schickt 3 Zeilen los, findet 2 und schließt mit {initial: 3, refunded: 1, final: 2} ab. Damit kannst du die Ausgaben eines Monats den gefundenen Zeilen gegenüberstellen, ohne ein Support-Ticket aufzumachen.

Ein Vorbehalt, weil er in die andere Richtung geht. Enrows Email Verifier rechnet je Prüfung ab, 0,25 Credit, nicht je gültiges Ergebnis. Schickst du ungültige Adressen hinein, zahlst du die 0,25 trotzdem für jede Zeile. Beim Finden wird nur ein gültiges Ergebnis berechnet, beim Prüfen jede einzelne Anfrage. Das solltest du wissen, bevor du eine Aufräumaktion durch den falschen Endpoint schickst.

2. Latenz, und ob der Aufruf blockiert

Zwei Entwurfsphilosophien, und keine davon ist falsch.

Manche APIs antworten synchron. Anymail Finder gibt für eine Einzelsuche meist rund drei Sekunden an. Hunter legt die Abwägung als Parameter offen: max_duration, zwischen 3 und 20 Sekunden, Standardwert 10, und die Doku schreibt dazu, dass eine längere Dauer die Ergebnisse verfeinert und genauere Daten liefert. Ein ungewöhnlich ehrlicher Regler. Genauigkeit kostet Millisekunden, und Hunter lässt dich entscheiden, wie viele du davon ausgibst.

Bei Enrow haben wir uns anders entschieden. Jeder Endpoint arbeitet asynchron. Ein POST auf /email/find/single antwortet sofort mit einer Such-ID, das Ergebnis kommt später per Webhook oder über den passenden GET. Die Doku sagt ausdrücklich, dass das Absicht ist: Große Mengen sollen den Aufrufer nie blockieren. Solange eine Suche läuft, liefert der GET {"qualification": "ongoing"}.

Die Prüfung selbst ist in Sekunden durch. Dein Ablauf wartet trotzdem nicht darauf, und Code, der die Adresse in der POST-Antwort erwartet, findet sie dort nicht.

Was besser passt, hängt davon ab, wo die Suche stattfindet. In einem Formular, auf das ein Mensch schaut, sind drei Sekunden synchrone Wartezeit völlig in Ordnung. In einem Nachtlauf über 40.000 Zeilen wird ein blockierender Aufruf zur Last. Für den zweiten Fall gibt es RFC 9110 §15.3.3: 202 Accepted bedeutet, dass die Anfrage zur Verarbeitung angenommen wurde, diese aber noch nicht abgeschlossen ist.

Einen p95 veröffentlicht niemand. Enrow nicht, die Anbieter oben auch nicht. Im Marketing steht „in Sekunden“, und auf ein Perzentil legt sich keiner fest. Miss es an deinem eigenen Volumen nach, bevor du deine Architektur auf eine Zahl von einer Landingpage ausrichtest.

3. Was die Antwort verbindlich aussagt

Hier teilt sich der Markt in zwei Schulen, und die falsche Wahl kostet dich Entwicklungswochen.

Schule eins reicht dir die Unsicherheit weiter. Hunters Email Finder meldet einen score von 0 bis 100, ein accept_all als Boolean, ein verification-Objekt mit dem Status valid, accept_all oder unknown, dazu bis zu zwanzig Einträge unter sources, jeder mit der Seite, auf der die Adresse aufgetaucht ist, und den Daten extracted_on und last_seen_on. Zum Score auf einer Accept-all-Domain wird die Doku deutlich: Er schätzt die Wahrscheinlichkeit, dass die Adresse gültig ist. ZeroBounce macht dasselbe gröber und meldet email_confidence als HIGH, MEDIUM oder LOW, dazu einen von neun Werten unter failure_reason.

Das ist brauchbar, wenn du deine eigene Bewertungsschicht entwickelst. Das sources-Array ist ein ernstzunehmendes Werkzeug für die Spurensuche.

Schule zwei nimmt dir die Entscheidung ab und liefert ein Urteil. Enrows Finder meldet qualification als valid oder invalid, während der Suche ongoing. Die Doku sagt es unverblümt: binäre Ergebnisse, keine Wahrscheinlichkeitsklassen. Daneben stehen email, ein info-Block mit Firmendomain, Firmenname, Vor- und Nachname, und das custom-Objekt, das du mitgeschickt hast.

Die richtige Frage ist nicht, welche Antwort mehr Felder hat. Sie lautet: Wer ist für den Schwellenwert verantwortlich? Kommen 0 bis 100 und accept_all: true heraus, liegt er bei dir, und zwar dauerhaft. Jeder Vertriebler, der sich dann über einen Bounce beschwert, beschwert sich über eine Zahl, die du gesetzt hast. Kommt valid oder invalid heraus, liegt der Schwellenwert beim Anbieter, und du kannst den Anbieter daran messen.

Das custom-Objekt erspart dir eine ganze Menge Glue-Code. Was immer du hineinschreibst, je Anfrage und im Bulk je Zeile, steht unverändert in der GET-Antwort und im Webhook. Interne Kontakt-ID, Kampagnen-Kennzeichen, Datensatz-ID aus dem CRM, worüber dein Ablauf die Datensätze eben zuordnet. Eine Zuordnungstabelle brauchst du nicht.

4. Catch-all-Domains: entschieden oder dir überlassen

Eine Accept-all-Domain sagt zu jeder Adresse Ja, die man ihr vorlegt. Echtes Postfach, Tippfehler, blanker Unsinn, alles wird angenommen. Das ist kein Versagen eines Anbieters, sondern im Protokoll so vorgesehen. RFC 5321 §3.5.3 rechnet damit: Es gibt Fälle, in denen eine Adresse gültig aussieht, sich in Echtzeit aber nicht sinnvoll prüfen lässt, und dann soll der Server mit 252 antworten. §3.3 hält außerdem fest, dass manche Server den Empfänger erst prüfen, wenn der Nachrichtentext eintrifft. Eine angenommene Adresse kann also später trotzdem als Bounce zurückkommen.

Mit einer einzelnen SMTP-Abfrage ist das nicht zu klären. Das liegt am Protokoll und nicht an einer Lücke im Werkzeug.

Deshalb schieben die meisten APIs die Unklarheit dir zu. Hunters Verifier meldet accept_all, und die eigene Doku warnt, dass ein SMTP-Server, der alles annimmt, bei SMTP-Prüfungen zu falsch positiven Ergebnissen führt. Das ist ehrlich. Übrig bleibt bei dir trotzdem ein Stapel Zeilen, für den niemand zuständig sein will.

Wirf diesen Stapel nicht weg. B2B-Listen sind voll von genau den Firmen, die am ehesten alles annehmen, und wer alles mit diesem Etikett löscht, wirft echte Entscheider zusammen mit den ungültigen Zeilen hinaus.

Enrow trifft bei Catch-all-Adressen eine Entscheidung, statt sie nur zu markieren: wiederholte SMTP-Durchläufe von Servern aus verschiedenen Regionen, abgeglichen mit absichtlich erfundenen Kontrolladressen auf derselben Domain, als Teil der mehr als 10 Prüfungen hinter jedem Ergebnis. Was sich klären lässt, kommt als valid heraus und wird als Treffer berechnet. Was sich nicht klären lässt, kommt als invalid heraus und kostet nichts. Die Catch-all-Prüfung steckt im Credit-Preis und ist kein Zusatzprodukt. Die beobachtete Bounce-Rate liegt unter 1 %, ein Durchschnitt aus echten Versendungen und keine Zusage. Wie das funktioniert, erklären wir im Artikel „Was ist eine Catch-all-Adresse?“, die Folgen beim Versand in Bounce-Rate bei E-Mails.

Bulk Email Finder: die Endpoints und ihre Rate-Limits

Bei großen Mengen zählt die Stapelgröße mehr als das Limit je Sekunde: zehn Anfragen statt rund 83 Minuten POSTs.

Ein Bulk Email Finder ist ein Endpoint, der eine ganze Kontaktliste in einer einzigen Anfrage annimmt und die verifizierten Adressen als Stapelauftrag ausliefert, statt einen HTTP-Aufruf je Person zu verlangen. Daran hängt, ob ein Ablauf über Nacht fertig wird oder eben nicht.

Die Obergrenzen je Stapel und die Rate-Limits gehen weit auseinander, und sie greifen ineinander.

Rechne einen Lauf über 50.000 Zeilen einmal durch. Einzelsuchen bei einer Grenze von 10 Anfragen je Sekunde ergeben 5.000 Sekunden reines Absenden, also rund 83 Minuten POSTs, bevor überhaupt jemand nach einem Ergebnis fragt. Im Bulk braucht derselbe Lauf zehn Anfragen. Bei Snovs dokumentierten 60 Anfragen je Minute dauert er im Einzelmodus vierzehn Stunden.

Bei großen Mengen zählt die Stapelgröße also mehr als die Zahl je Sekunde. Enrows Grenze liegt pauschal bei 10 POSTs je Sekunde und API-Schlüssel, GETs werden nicht gezählt, und eine Anhebung gibt es auf Anfrage über api@enrow.io. Eine veröffentlichte Zahl darüber hinaus existiert nicht, plane also nicht mit einer.

Wiederholungsversuche, Idempotenz und was die Abrechnung daran ändert

POST ist nicht idempotent. RFC 9110 §9.2.2 erlaubt einem Client, eine Anfrage zu wiederholen, wenn keine Antwort ankommt, setzt dafür aber voraus, dass die Anfrage als idempotent gelten darf. Ein Such-POST tut das nicht. Eine Anfrage, die du nach einem Timeout erneut abschickst, ist ein zweiter abrechenbarer Vorgang, solange der Anbieter sie nicht selbst als Dublette erkennt.

Der Header, nach dem jeder greift, ist kein Standard. Idempotency-Key ist ein IETF-Entwurf, draft-ietf-httpapi-idempotency-key-header, in Revision 07 ausgelaufen. Ob er unterstützt wird, entscheidet jeder Anbieter für sich, und flächendeckend ist das nicht der Fall. Hunter setzt ihn sauber um, mit 24 Stunden TTL, einem Fingerabdruck über den Request-Body und vier verschiedenen Fehlercodes, aber nur auf den Endpoints für Sequenzen und Nachrichten. Beim Email Finder nicht.

Beim Preis je Versuch ist das ein echtes Problem. Die Wiederholungslogik wird zur Ausgabenentscheidung, und ein aggressiver Backoff in einem wackligen Netz verdoppelt die Monatsrechnung, ohne dass es jemand merkt.

Wird nur ein gültiges Ergebnis berechnet, löst sich der Ärger größtenteils auf. Ein zweiter Anlauf, der nichts findet, kostet nichts, du kannst also knappe Timeouts setzen, ohne auf den Zähler zu schauen. Größtenteils, nicht vollständig: Ein Wiederholungsversuch, der dieselbe Adresse findet, ist trotzdem ein Treffer, und Enrow veröffentlicht keine Zusage, dass Dubletten erkannt werden. Führ deshalb selbst Buch über die Such-IDs, die noch offen sind. Die Abrechnung nach gültigen Ergebnissen macht Wiederholungen billig, nicht kostenlos.

Zwei Dinge fehlen bei Enrow, und ich schreibe sie lieber hier hin, als dass du sie nachts um zwei entdeckst. X-RateLimit-*-Header gibt es nicht, und ein 429 kommt als bloßes {"message": "Too Many Requests"} an. RFC 6585 §4 stellt Retry-After frei, Enrow lässt den Header weg, und die Doku sagt entsprechend, dass du den exponentiellen Backoff für die feste Obergrenze selbst einrichten musst. Dazu kommt: 404 steht überhaupt nicht in der Liste der dokumentierten Statuscodes, dort stehen 400, 401, 402, 429 und 500. Ein Handler, der auf einen sauberen 404 für eine unbekannte oder abgelaufene Such-ID wartet, greift also nie.

So bindest du die API an

Die Authentifizierung ist ein API-Schlüssel im Header x-api-key. Kein OAuth-Ablauf, keine Bearer-Token, und die Doku schreibt genau das. Die Basis-URL lautet https://api.enrow.io.

Zu jedem POST gehört ein passender GET: /email/find/single, /email/find/bulk, /email/verify/single, /email/verify/bulk, /phone/single, /phone/bulk. Dazu kommt GET /account/info mit deinem Credit-Stand als einer einzigen Zahl und den hinterlegten Webhook-URLs.

Sechs Webhook-Ereignisse decken die Endpoints ab. Bei einer Einzelsuche enthält das Ereignis das vollständige Ergebnis; eine saubere Anbindung für Einzelsuchen muss also nie nachfragen. Bei einem Bulk-Lauf meldet das Ereignis lediglich, dass der Stapel abgearbeitet ist; die Zeilen und die Credit-Abrechnung holst du über den passenden GET. Die Webhook-URL hinterlegst du global auf der Integrationsseite oder je Anfrage unter settings.webhook, ausschließlich über HTTPS, und sie muss mit 200 antworten.

Fehler, die du abfangen solltest: 401 bei falschem Schlüssel, 402 bei zu wenig Credits, 429 beim Rate-Limit. Achte auf den 402. Auf den Einzel-Endpoints kommt er als {reason, success}, im Bulk als schlichtes {message}, und daran scheitert ein gemeinsamer Fehler-Parser. Offizielle SDKs gibt es inzwischen, sieben Stück: JS/TypeScript, Python, PHP, Go, Java, Swift und Rust, laut docs.enrow.io/sdks/overview, abgerufen am 29. August 2026. Alle sieben sind im Early Access und werden aus dem GitHub-Quellcode statt über eine Paketregistry installiert; den Commit pinnst du also selbst, und die curl- und JavaScript-Beispiele aus der Doku bleiben der Rückfallweg. Die vollständige Spezifikation steht auf der Enrow-API-Seite, ein Schlüssel ist in etwa dreißig Sekunden da, ohne Verkaufsgespräch.

Sitzt am anderen Ende ein KI-Agent statt eines Dienstes, gibt es dafür einen offiziellen MCP-Server. Das Repo auf GitHub heißt EnrowAPI/enrow-mcp, steht unter MIT-Lizenz und wird über npm installiert oder mit npx gestartet. Es stellt den Finder, den Verifier und die Telefonsuche als Tools bereit, nämlich find_email, find_emails_bulk, verify_email, find_phone und die zugehörigen Abruffunktionen; dokumentiert sind Claude Desktop, Cursor und Windsurf als Clients. So ermittelt ein Assistent die Kontaktdaten mitten im Gespräch, ohne dass jemand Anbindungscode schreibt.

Der Email Finder als Chrome-Extension: der Weg ohne Code

Viele von denen, die diese Daten brauchen, öffnen nie ein Terminal. Für sie ist eine Chrome-Extension zur E-Mail-Suche die richtige Oberfläche und keine API.

Enrows Extension arbeitet direkt auf einem LinkedIn- oder Sales-Navigator-Profil. Ein Klick schreibt den kompletten Datensatz nach HubSpot, Salesforce oder Pipedrive: Name, verifizierte E-Mail-Adresse, Direktnummer, Firma, LinkedIn-URL. Keine kopierte Adresse, die jemand in ein Feld einfügt, sondern die ganze Kontaktkarte. Abgerechnet wird wie bei der API: 1 Credit für eine verifizierte E-Mail-Adresse, 40 für eine verifizierte Nummer, und ohne Ergebnis kostet es nichts.

RevOps richtet den Ablauf ein, der Vertrieb arbeitet Profile ab. Dasselbe Credit-Guthaben, dieselbe Prüfung, zwei Oberflächen. Mehr dazu in E-Mail-Adressen über LinkedIn finden und in unserem Artikel zur Datenanreicherung in HubSpot.

Was diese API nicht für dich erledigt

Eine durchsuchbare Datenbank gibt es nicht. Wenn du Enrow nach „allen CTOs in Berlin bei Firmen ab 200 Leuten“ fragst, bekommst du nichts, weil es keine Liste gibt, die sich abfragen ließe. Der Finder braucht einen vollständigen Namen plus Firmendomain oder Firmenname. Die Telefonsuche braucht eine LinkedIn-URL.

Das ist ein bewusster Kompromiss, und der Grund dafür ist schnell erzählt. Datenbankanbieter aktualisieren in Zyklen, die man in Monaten misst, weshalb ein nennenswerter Teil dessen, was sie verkaufen, Leute beschreibt, die den Arbeitgeber längst gewechselt haben. Enrow ermittelt die Adresse erst im Moment der Anfrage, und daher kommt die Genauigkeit. Der Preis dafür ist, dass das Sourcing bei dir bleibt. Die Liste entsteht auf LinkedIn oder im Sales Navigator, danach geht sie an die API. Fürs Sequencing nimmst du Emelia, La Growth Machine oder lemlist.

Was ein verifizierter Kontakt kostet

Weil nur ein gefundenes Ergebnis berechnet wird, sind Listenpreis und echter Preis dieselbe Zahl. Start kostet 15 € im Monat für 1.000 Credits, das sind 0,015 € für eine gültige E-Mail-Adresse. Pro kostet 75 € für 10.000 Credits, also 0,0075 €. Scale beginnt bei 360 € für 50.000 Credits, und die Monatstarife reichen bis 200.000 Credits für 1.250 €. Stellst du diese oberste Stufe auf Jahreszahlung um, landest du bei rund 0,0056 € für eine Adresse, dem günstigsten Wert aller Preisstufen. Eine Direktnummer kostet 40 Credits, im Pro-Tarif also 0,30 €. Eine Prüfung kostet 0,25 Credit, egal wie sie ausgeht.

Stell das einem Anbieter gegenüber, der je Versuch abrechnet, beim gleichen Monatsvolumen und auf derselben Grundlage, statt einfach Listenpreise zu vergleichen. Ein Tool, das 0,02 € für jede gestartete Suche berechnet, kostet dich bei einer Trefferquote von 30 % 0,067 € für jeden gefundenen Kontakt, und die Zeilen, die später als Bounce zurückkommen, sind darin noch nicht enthalten. Nur diese Zahl gehört in eine Vergleichstabelle.

Eine Gebühr pro Nutzer gibt es nicht, in Pro und Scale sind beliebig viele Teammitglieder inklusive, und übrige Credits werden übertragen: im Pro-Tarif bis zum Dreifachen deines Monatskontingents, im Scale-Tarif bis zum Sechsfachen. Der Gratis-Tarif bietet jeden Monat 50 Credits, wiederkehrend und ohne Kreditkarte.

FAQ

Kostet eine erfolglose Suche über die Email-Finder-API einen Credit?

Das hängt vom Anbieter ab, und es ist das Erste, was du nachschlagen solltest. Enrow, Anymail Finder und Findymail schreiben übereinstimmend, dass ihre Finder-Endpoints nur ein gefundenes Ergebnis berechnen; ZeroBounce verlangt für eine ungeklärte Suche nichts. Tools, die je Versuch abrechnen, kassieren schon für die Anfrage. Nimmst du für eine kalte B2B-Liste eine Trefferquote von 30 % an, kostet dich ein gefundener Kontakt in Wahrheit mehr als das Dreifache einer einzelnen Suche, und daneben verschwindet jeder Unterschied im Listenpreis.

Gibt es eine kostenlose Email-Finder-API?

Gratis-Tarife gibt es, dauerhaft kostenlose APIs bei nennenswertem Volumen in der Regel nicht, weil jede Suche den Anbieter echte SMTP-Arbeit kostet. Enrow gibt dir jeden Monat 50 Credits, wiederkehrend und ohne Kreditkarte; das sind 50 verifizierte E-Mail-Adressen oder 200 Prüfungen, dauerhaft. Das reicht, um eine Anbindung einzurichten und durchzutesten.

Wie schnell sollte eine Email-Finder-API antworten?

Eine synchrone Suche, die länger als etwa fünf Sekunden braucht, macht überall Ärger, wo ein Mensch darauf wartet. Hunter lässt dich das über den Parameter max_duration zwischen 3 und 20 Sekunden einstellen und dokumentiert, dass eine längere Dauer genauere Daten liefert. Bei Stapelarbeit zählt der Durchsatz, die Latenz je Zeile spielt dort keine Rolle. Einen p95 veröffentlicht in diesem Markt niemand, also miss an deinem eigenen Volumen nach.

Kann ich eine Email-Finder-API im Bulk nutzen?

Ja, und ab ein paar hundert Zeilen solltest du das auch. Enrow nimmt bis zu 5.000 Kontakte je Bulk-Lauf beim Email Finder und 3.000 je Telefonlauf, die Ergebnisse kommen per Webhook oder über einen GET. Hunters v2-API hat gar keinen Bulk-Finder-Endpoint, dort läuft die Massenverarbeitung in der Oberfläche. Prüf also, ob es den Endpoint überhaupt gibt, bevor du deine Architektur darauf aufbaust.

Kann ich eine Suche nach einem Timeout gefahrlos wiederholen?

Technisch ja, aber rechne es vorher durch. POST ist nach RFC 9110 nicht idempotent, und Idempotency-Key ist ein ausgelaufener IETF-Entwurf, den längst nicht jeder Anbieter unterstützt, weshalb ein zweiter Anlauf normalerweise ein zweiter abrechenbarer Vorgang ist. Wird nur ein gültiges Ergebnis berechnet, kostet ein Wiederholungsversuch ohne Treffer nichts, und knappe Timeouts werden bezahlbar. Führ trotzdem selbst Buch über die offenen Such-IDs.

Darf ich Kontakte anreichern, die ich nicht selbst erhoben habe?

In der EU stützt sich das auf Artikel 6 Abs. 1 lit. f DSGVO, das berechtigte Interesse, zusammen mit der Informationspflicht aus Artikel 14 und der Ausnahme nach Artikel 14 Abs. 5 lit. b, wenn die Benachrichtigung unverhältnismäßigen Aufwand bedeutet. Kaltakquise im B2B passt häufig in diesen Rahmen, die Bewertung dokumentierst aber du, und zwar mit einem Anwalt und nicht mit einem Blogbeitrag. Für europäische Handynummern hält Enrow die dokumentierte Rechtsgrundlage vor.

Prüf alle vier Kriterien an deiner eigenen Liste. Über die Enrow-API bekommst du den Schlüssel in etwa dreißig Sekunden, und der Gratis-Tarif bietet jeden Monat 50 Credits, ohne Kreditkarte.