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 Arbeitsadresse. 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? Worauf legt sich die Antwort tatsächlich fest? Kommt eine Catch-all-Domain entschieden zurück oder als dein Problem? Eine fünfte Frage tut erst bei Menge weh: was ein Lauf über 50.000 Zeilen mit dem Rate-Limit macht. Enrows Antworten, zum Vergleich: berechnet wird nur ein gültiges Ergebnis, jeder Endpoint arbeitet asynchron, Catch-all-Adressen werden geprüft statt etikettiert, 10 Anfragen je Sekunde auf POST, Bulk-Läufe bis 5.000 Zeilen. Lies die Abrechnungszeile vor der Feature-Liste. Sie verschiebt die echten Kosten stärker als der Listenpreis.

Eine Email-Finder-API ist ein HTTP-Endpoint, der eine Person auf ihre geschäftliche E-Mail-Adresse auflöst. 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. Die schieben Nachrichten hinaus. 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 beim Entwickeln der eigenen API entstanden, parallel zum Lesen von einem Dutzend Anbieter-Dokumentationen. 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 echt 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 der Suche.

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

Es gibt zwei Modelle. Beim Preis je Versuch kostet schon die Frage: Der Anbieter rechnet, 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 rechne ich auf einer kalten B2B-Liste mit 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 bouncet ein Teil der Treffer, und dafür hast du auch schon bezahlt.

Ein paar Anbieter schreiben die Zeile ausdrücklich hin, 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 stellst du einen Monat Ausgaben den gefundenen Zeilen gegenüber, ohne ein Support-Ticket.

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 hergibt. 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, steht im 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 sitzt. In einem Formular, auf das ein Mensch schaut, sind drei Sekunden synchron 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 heißt angenommen zur Verarbeitung, die 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 eine Architektur um eine Zahl von einer Landingpage herum entwirfst.

3. Worauf sich die Antwort festlegt

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.

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

Schule zwei entscheidet die Frage und legt dir ein Urteil hin. 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: Wem gehört der Schwellenwert? Kommen 0 bis 100 und accept_all: true heraus, gehört er 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, gehört der Schwellenwert dem Anbieter, und du kannst ihn daran messen.

Das custom-Objekt spart eine ganze Klasse von Klebe-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, worauf dein Ablauf eben schlüsselt. 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 steht im Protokoll. 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 bouncen.

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

Also schieben die meisten APIs die Unklarheit zu dir. 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 nach dem Etikett löscht, wirft lebende Entscheider zusammen mit den ungültigen Zeilen hinaus.

Enrow entscheidet Catch-all-Adressen, statt sie zu etikettieren: wiederholte SMTP-Durchläufe von Servern aus verschiedenen Regionen, abgeglichen gegen absichtlich erfundene Kontrolladressen auf derselben Domain, als Teil der 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. Die Mechanik dahinter steht in Was ist eine Catch-all-Adresse, der Schaden am anderen Ende in Bounce-Rate bei E-Mails.

Bulk Email Finder: die Endpoints und ihre Rate-Limits

Bei Menge zählt die Stapelgröße mehr als das Limit je Sekunde: zehn Anfragen gegen 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 gegen eine Grenze von 10 Anfragen je Sekunde ergeben 5.000 Sekunden reines Absenden, also rund 83 Minuten POSTs, bevor überhaupt jemand nach einem Ergebnis fragt. Derselbe Lauf im Bulk sind zehn Anfragen. Gegen Snovs dokumentierte 60 je Minute wird aus dem Einzelmodus ein Fenster von vierzehn Stunden.

Bei Menge zählt die Stapelgröße also mehr als die Zahl je Sekunde. Enrows Grenze sind pauschal 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. Ein Timeout, den du erneut abschickst, ist ein zweiter abrechenbarer Vorgang, solange der Anbieter ihn 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. Wer ihn unterstützt, entscheidet jeder Anbieter für sich, und flächendeckend ist das nicht. 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. Auf dem Email Finder nicht.

Beim Preis je Versuch ist das ein echtes Problem. Die Wiederholungslogik wird zur Ausgabenentscheidung, und ein forscher 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 fahren, 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 auf gültige Ergebnisse 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 nacktes {"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 gegen die feste Obergrenze selbst einrichtest. 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.

Wie du sie anschließt

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 trägt das Ereignis das vollständige Ergebnis, eine saubere Einzelsuch-Anbindung fragt also nie nach. Bei einem Bulk-Lauf meldet das Ereignis lediglich, dass der Stapel durch 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 antwortet er mit {reason, success}, im Bulk mit dem schlichten {message}, und daran zerbricht 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 am 29. August 2026. Alle sieben stehen im Early Access und werden aus dem GitHub-Quellcode installiert statt über eine Paketregistry, du pinnst den Commit 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 heißt EnrowAPI/enrow-mcp auf GitHub, 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 Abholfunktionen; dokumentiert sind Claude Desktop, Cursor und Windsurf als Clients. So klärt ein Assistent einen Kontakt 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. Nicht eine kopierte Adresse, die jemand in ein Feld einfügt, sondern die ganze Kontaktkarte. Abgerechnet wird wie über die 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. Derselbe Credit-Topf, dieselbe Prüfung, zwei Oberflächen. Mehr dazu in E-Mail-Adressen über LinkedIn finden und unter 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, kommt 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 Tausch, 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 löst erst im Moment der Anfrage auf, 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 sind 75 € für 10.000 Credits, also 0,0075 €. Scale beginnt bei 360 € für 50.000 Credits, und die Monatsleiter läuft hinauf 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 der ganzen Leiter. Eine Direktnummer zieht 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, nicht Listenpreis gegen Listenpreis. 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 bouncen, sind darin noch nicht enthalten. Nur diese Zahl gehört in eine Tabelle.

Eine Gebühr pro Nutzer gibt es nicht, auf Pro und Scale sind beliebig viele Teammitglieder dabei, und übrige Credits werden übertragen, auf Pro bis zum Dreifachen deines Tarifs, auf Scale bis zum Sechsfachen. Der Gratis-Tarif sind 50 Credits jeden Monat, wiederkehrend, ohne Karte.

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 nachschlägst. 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 die Frage. Nimmst du auf einer kalten B2B-Liste eine Trefferquote von 30 % an, kostet dich ein gefundener Kontakt in Wahrheit mehr als das Dreifache, und daneben verschwindet jeder Unterschied im Listenpreis.

Gibt es eine kostenlose Email-Finder-API?

Gratis-Tarife gibt es, dauerhaft kostenlose APIs bei echtem Volumen in der Regel nicht, weil jede Suche den Anbieter echte SMTP-Arbeit kostet. Enrow gibt 50 Credits jeden Monat, wiederkehrend und ohne Karte, das sind 50 verifizierte E-Mail-Adressen oder 200 Prüfungen, dauerhaft. Genug, 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 hergibt. 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 stellst.

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. Die Enrow-API gibt dir den Schlüssel in etwa dreißig Sekunden, und der Gratis-Tarif sind 50 Credits jeden Monat, ohne Karte.