SpamZilla bietet derzeit keine öffentliche, dokumentierte API für reguläre Kunden. Wer Suchen nach abgelaufenen Domains, geplante Shortlists, CRM-Updates oder Live-Prüfungen automatisieren möchte, sollte eine API mit veröffentlichten Endpunkten und erlaubtem automatisiertem Zugriff verwenden.
Inhaltsverzeichnis
- Inhaltsverzeichnis
- Warum Nutzer nach einer SpamZilla API suchen
- Hat SpamZilla eine API?
- Datenintegrationen sind kein API-Zugang für Kunden
- Warum Scraping kein guter Ersatz ist
- Was Teams tatsächlich automatisieren wollen
- Ein unterstützter Workflow mit der Karma.Domains API
- SpamZilla und Karma.Domains API im Vergleich
- Wann SpamZilla weiterhin sinnvoll ist
- Starten, ohne eine interne Plattform zu bauen
- Häufig gestellte Fragen
Warum Nutzer nach einer SpamZilla API suchen
Für eine einzelne Person kann manuelle Domain-Recherche gut funktionieren. Dashboard öffnen, einige Filter einstellen, Ergebnisse prüfen und die verbleibenden Kandidaten in eine Tabelle kopieren.
In einer Agentur gerät derselbe Ablauf schnell ins Stocken. Kriterien unterscheiden sich von Mitarbeiter zu Mitarbeiter. Für jeden Kunden muss jemand die Suche neu aufbauen. Manche Domains werden doppelt geprüft, andere gehen zwischen Dashboard und Einkaufsliste verloren.
Eine API löst dieses Übergabeproblem. Das Team kann dieselbe Abfrage nach Zeitplan ausführen, bereits geprüfte Domains erfassen und nur die Shortlist dorthin senden, wo Menschen entscheiden.
Hat SpamZilla eine API?
Die kurze Antwort lautet nein, zumindest gibt es keine öffentliche API, auf die reguläre Abonnenten ihre Integration stützen können.
Laut SpamZillas eigener API-FAQ ist eine API nicht verfügbar und für die Zukunft geplant. Die Seite wurde vor sechs Jahren aktualisiert. Auf der aktuellen SpamZilla-Preisseite stehen Free- und Standard-Zugang, Millionen von Domains, automatische Spam-Prüfung, Backlink-Daten, Credits für eigene Listen, mehr als 70 Filter und tägliche E-Mails. API-Zugang wird nicht aufgeführt.
Auch ein öffentliches Entwicklerportal, ein OpenAPI- oder Swagger-Schema, eine Endpunktreferenz, veröffentlichte Limits oder ein Ablauf zur Erstellung eines API-Schlüssels sind auf der offiziellen Website nicht zu finden.
Möglicherweise nutzt SpamZilla private Schnittstellen für eigene Systeme oder Partner. In einer älteren Antwort im BlackHatWorld-Launch-Thread hieß es, eine Partner-API sei bereits gebaut, aber nicht öffentlich veröffentlicht worden. Das ist keine unterstützte Kunden-API.
Nach sechs Jahren ohne öffentliche Dokumentation oder Zugangsbedingungen würde ich Kundenarbeit und Entwicklung nicht auf dieses alte Versprechen stützen. Sollte SpamZilla später eine API veröffentlichen, lassen sich Endpunkte, Limits, Preis und Support dann anhand der realen Spezifikation bewerten.
Datenintegrationen sind kein API-Zugang für Kunden
SpamZilla zeigt in seiner Oberfläche Kennzahlen von Majestic, Ahrefs, Moz und Semrush an. Hinzu kommt der eigene SZ Score.
Diese Integrationen erlauben Abonnenten keine Abfragen der SpamZilla-Datenbank aus n8n, Python, einem CRM oder einer internen Anwendung. Ein Produkt kann mehrere APIs nutzen, ohne selbst eine bereitzustellen.
Für die Planung eines Workflows ist der Unterschied wichtig. Ein Web-Dashboard ist ein Ziel für Menschen. Eine API ist ein Vertrag zwischen Systemen: dokumentierte Felder, Authentifizierung, vorhersehbare Antworten und veröffentlichte Grenzen.
Warum Scraping kein guter Ersatz ist
Ein Scraper wirkt wie der kürzeste Weg vom Dashboard zur Tabelle. Bei SpamZilla entsteht zuerst ein Problem mit den Nutzungsbedingungen und danach eines mit der Wartung.
Die SpamZilla-Nutzungsbedingungen untersagen automatisierten oder nicht menschlichen Zugriff, systematische Datenabfragen, Data-Mining-Werkzeuge, Robots, Scraper und nicht autorisierte Skripte. Das Unternehmen darf außerdem den Zugriff einschränken, IP-Adressen blockieren sowie Konten sperren oder kündigen.
Selbst mit schriftlicher Erlaubnis fehlt einem Scraper ein stabiler Vertrag. Eine Änderung an Tabellenlayout, Login, Session-Token oder Paginierung kann den Prozess über Nacht stoppen. Das Team pflegt dann eine Integration ohne versioniertes Schema und ohne Garantie, dass Felder ihre Bedeutung behalten.
Für gelegentliche Recherchen eignet sich die Weboberfläche. Für Automatisierung braucht es eine unterstützte API.
Was Teams tatsächlich automatisieren wollen
Hinter den meisten Suchen nach „SpamZilla API“ stehen einige konkrete Aufgaben:
- Eine gelieferte Domainliste mit einheitlichen Regeln vorprüfen.
- Jeden Morgen neue abgelaufene Domains oder Auktionskandidaten abrufen.
- Schwache Linkprofile, verdächtige Historien und unpassende Themen aussortieren.
- Kandidaten an CRM, Notion-Datenbank, Google Sheet oder internes Dashboard weitergeben.
- Verfügbarkeit und aktuelle Daten kurz vor dem Kauf erneut prüfen.
- Kollegen oder Kunden einen nachvollziehbaren Bericht geben, ohne die Recherche zu wiederholen.
Für diese Aufgaben sind durchsuchbarer Bestand, dokumentierte Felder und verlässliches JSON wichtiger als eine Nachbildung des SZ Score.
Ein unterstützter Workflow mit der Karma.Domains API
Die Karma.Domains API für abgelaufene Domains greift auf denselben Bestand wie die Web-App zu: mehr als 13 Millionen abgelaufene und versteigerte Domains aus gTLDs und ccTLDs. Täglich verarbeitet das System über 400.000 neue Domains aus mehr als 40 Quellen. Für die Suche stehen über 90 Filter bereit.
Die Berichte kombinieren Signale von Ahrefs, Majestic, Moz, Semrush, Similarweb, der Wayback Machine und weiteren Quellen. Der Karma Content Score bewertet den archivierten Inhaltsverlauf. Die Karma Domain Metric liefert eine weitere zusammengesetzte Sicht auf die Domainqualität. Keine der beiden Kennzahlen versucht, SpamZillas proprietären SZ Score zu kopieren.
Die API verwendet REST, JSON und Bearer-Authentifizierung. Pro-Nutzer erstellen den Schlüssel unter Profile → Settings. Anfrage- und Antwortschemas sind über OpenAPI und Swagger veröffentlicht; offizielle SDKs für Python und TypeScript sowie eine CLI stehen ebenfalls bereit.
Eine Liste von Kunden oder Brokern prüfen
Angenommen, eine Agentur erhält 600 Domains von einem Kunden, Broker oder Auktionsresearcher. Ein Skript kann die Liste in einer Queue halten, zu jedem Namen nach einem vorhandenen Karma.Domains-Bericht suchen, Zusammenfassungsfelder erfassen und die wenigen interessanten Domains markieren.
Diese erste Prüfung sollte günstig und streng sein. Ich würde Domains mit themenfremder Archivhistorie, toxischen Inhalten, extremen Themen- oder Sprachwechseln, schwachen Autoritätssignalen oder nutzlosem Backlinkprofil entfernen. Ein Mensch prüft die verbleibenden Kandidaten im vollständigen Bericht und sieht sich vor dem Kauf die Wayback-Zeitleiste an.
Alle 600 Namen direkt einer teuren Detailanalyse in Ahrefs oder Semrush zu unterziehen, bringt wenig. Diese Werkzeuge lohnen sich auf der Shortlist, wo Link- und Keyword-Details die Kaufentscheidung verändern können.
Eine tägliche PBN- oder Rebuild-Shortlist erstellen
Ein geplanter Job kann jeden Morgen denselben Suchendpunkt mit denselben Filtern aufrufen. Ein Projekt verlangt vielleicht englischsprachige .com-Domains mit sauberem historischen Thema, einem Mindestwert beim Karma Content Score, brauchbaren Referring Domains und ohne erkennbare Spam-Phasen. Ein lokales Projekt sucht eher nach einer ccTLD und akzeptiert ein kleineres Linkprofil.
Da die Kriterien im Code oder in einer gespeicherten Konfiguration liegen, folgen Montags- und Freitagsliste denselben Regeln. Der Workflow speichert Report-IDs, überspringt bereits bekannte Domains und sendet nur neue Treffer an das Team.
Eine minimale Suchanfrage sieht so aus:
curl -X POST "https://api.karma.domains/v1/reports/search?page=1&page_size=25" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d '{"karmascore_min":60,"domain_type":["expired"]}'
In Produktion lassen sich genau die Felder verwenden, die zu den Kaufregeln passen. Das vollständige Filterschema gehört in die API-Dokumentation und nicht als feste Annahme in einen Blogartikel.
Auktionen in einer Queue überwachen
Auktionsrecherche ist zeitkritisch. Eine Domain kann für 40 Dollar sinnvoll und für 1.400 Dollar ein schlechter Kauf sein.
Ein geplanter Workflow ruft Auktionsdomains mit Quelle, aktuellem Preis, Gebotszahl, Endzeit und verfügbaren SEO- oder Archivdaten ab. Das Team sortiert nach Kunde, Projekttyp oder Höchstgebot. Den Zuschlag gibt weiterhin ein Mensch ab; die Automatisierung hält die Prüfwarteschlange aktuell.
SEO Enrich nur bei fehlenden Daten anfordern
Die meisten Karma.Domains-Berichte enthalten bereits SEO-Daten. Gelegentlich wartet ein Bericht noch in der gemeinsamen Verarbeitungsqueue oder eine benötigte Kennzahl fehlt. Mit SEO Enrich kann ein autorisierter Prozess die fehlenden Daten früher anfordern und anschließend den Jobstatus abfragen.
Dieser Schritt sollte eine Bedingung haben. Sind die erforderlichen Kennzahlen vorhanden, geht es weiter. Fehlen sie bei einem wichtigen Kandidaten, wird Enrichment angefordert. Ein Aufruf für jede Domain verbraucht Credits, ohne bereits vollständige Berichte zu verbessern.
Finalisten erneut prüfen und an einen Menschen übergeben
Zwischen Entdeckung und Kauf kann sich eine Domain verändern. Für die letzten Kandidaten kann die API Live-Prüfungen zu Verfügbarkeit, Registrierungsablauf, WHOIS, DNS, Autorität oder Traffic durchführen. Ergebnisse aus dem Cache kosten keinen weiteren Credit.
Der Workflow kann außerdem eine Freigabe-URL für den vollständigen Bericht erstellen und beim Kandidaten im CRM speichern. SEO-Leitung, Einkauf oder Kunde sehen damit die Belege für die Empfehlung statt einer Reihe unerklärter Scores.
SpamZilla und Karma.Domains API im Vergleich
Beide Produkte überschneiden sich bei der Recherche abgelaufener Domains, unterstützen aber unterschiedliche Arbeitsweisen.
| Funktion | SpamZilla | Karma.Domains API |
|---|---|---|
| Primärer Workflow | Web-Dashboard | REST-JSON-API plus Web-App |
| Öffentliche dokumentierte API | Laut FAQ nicht verfügbar | Ja |
| Entwicklerdokumentation | Keine öffentliche Endpunktreferenz oder Schema | OpenAPI und Swagger |
| Öffentlicher Ablauf für API-Schlüssel | Nicht aufgeführt | Profile → Settings ab Pro |
| Eigene Qualitätssignale | SZ Score | Karma Content Score, Karma Domain Metric und Archivsignale |
| Suchfilter | 70+ in der Oberfläche | 90+ über API und App |
| Domainbestand | Millionen abgelaufener und versteigerter Domains | 13M+ Domains aus 40+ Quellen |
| Maschinenlesbare Antworten | Keine öffentliche Kundenschnittstelle | JSON |
| Typische Integrationen | Manuelles Dashboard, eigene Listen und E-Mails | n8n, CRM, Sheets, Skripte, SDKs und interne Werkzeuge |
| Automatisierter Zugriff | Bedingungen untersagen unautorisierten automatisierten Zugriff | Offizielle API ist der unterstützte Automatisierungskanal |
Wann SpamZilla weiterhin sinnvoll ist
SpamZilla bleibt nützlich, wenn der SZ Score für den Prozess zentral ist und die Arbeit im Dashboard ausreicht. Der Standard-Tarif enthält derzeit die Domain-Datenbank, automatische Spam-Prüfung, Backlink-Daten, Credits für eigene Listen, mehr als 70 Filter und tägliche E-Mails. Ein einzelner Domainkäufer kann diesen geschlossenen Ablauf bevorzugen.
Die Karma.Domains API passt besser, wenn Ergebnisse in ein anderes System müssen: Kundenqueue, CRM-Eintrag, n8n-Workflow, Monitoring-Job oder internes Review-Tool. Sie eignet sich auch für Teams, die dieselben Filter nach Zeitplan ausführen möchten, ohne dass jemand die Suche jedes Mal neu aufbaut.
Manche Teams nutzen beide. SpamZilla kann als manuelle Zweitmeinung für den SZ Score dienen, während eine unterstützte API Suche und Weiterleitung übernimmt. Entscheidend ist, ob das Dashboard das Ziel oder nur ein Schritt in einem größeren System ist.
Starten, ohne eine interne Plattform zu bauen
Beginnen Sie mit einer wiederkehrenden Aufgabe, die bereits Zeit kostet. Eine tägliche Shortlist lässt sich leichter prüfen als eine große interne Anwendung.
Erstellen Sie einen Bearer-Schlüssel, führen Sie eine gespeicherte Abfrage aus, protokollieren Sie bereits geprüfte Domains und senden Sie neue Treffer an das vorhandene System. Live-Prüfungen und Freigabelinks kommen hinzu, sobald die Shortlist brauchbare Kandidaten liefert. Die Karma.Domains API-Dokumentation enthält aktuelle Feldnamen, Limits, SDK-Links und Beispiele.
Häufig gestellte Fragen
Hat SpamZilla eine API?
SpamZilla bietet keine öffentliche, dokumentierte API für reguläre Kunden. Die FAQ nennt eine geplante API, und ein älterer Firmenbeitrag erwähnte eine Partner-API. Öffentliche Entwicklerdokumentation und ein Zugangsweg für Kunden fehlen weiterhin.
Wie bekomme ich einen SpamZilla API-Schlüssel?
Die offiziellen Preis- und Hilfeseiten nennen keinen öffentlichen Prozess. Fragen Sie SpamZilla direkt nach privatem oder Partnerzugang.
Kann ich SpamZilla stattdessen scrapen?
SpamZillas Nutzungsbedingungen untersagen automatisierten Zugriff, systematische Extraktion, Robots, Scraper und nicht autorisierte Skripte. Nutzen Sie das Webprodukt wie vorgesehen oder holen Sie eine schriftliche Genehmigung ein.
Was ist eine praktische Alternative zur SpamZilla API?
Für programmierbare Bestandssuche, JSON-Berichte, Live-Prüfungen und die Anbindung an Automatisierungswerkzeuge eignet sich eine dokumentierte Domain-Research-API. Karma.Domains stellt diese Funktionen öffentlich bereit, ohne den SZ Score nachzubilden.
Lässt sich die Recherche zu abgelaufenen Domains mit n8n oder einem CRM verbinden?
Ja. Eine REST-API kann n8n, Make, Google Apps Script, ein CRM, eine Datenbank oder eine interne Anwendung speisen. Die Auswahlregeln bleiben im Workflow; Menschen erhalten nur die Shortlist.
Wenn manuelle Prüfung und SZ Score ausreichen, bleibt SpamZilla ein vernünftiges Spezialwerkzeug. Braucht das Team jetzt Automatisierung, sollte es auf einer API aufbauen, die sich heute dokumentieren, testen und unterstützen lässt.