DomainCatcher API: Domains suchen, bestellen und automatisieren

Autor: Leo Kobes Veröffentlicht: 22. Juli 2026 Aktualisiert: 29. Juli 2026 Stand der Produktinformationen: 29. Juli 2026

Neu · REST API · Automatisierung

Die neue DomainCatcher API ermöglicht es, Backorders abzurufen und anzulegen, RGP- und ReCatch-Domains zu durchsuchen, ReCatch-Domains zu übernehmen, freie .de-Domains zu registrieren und Domains aus der Domex zu kaufen. Die Schnittstelle richtet sich an Domaininvestoren, Publisher, SEO-Teams und Entwickler, die wiederkehrende Domainprozesse automatisieren möchten.

Die API wird technisch und vertraglich von DomainCatcher.com bereitgestellt. deinrecatch.de erklärt die verfügbaren Endpunkte, Voraussetzungen, Antworten und Sicherheitsregeln. API-Key, Guthaben, Käufe und Domainverwaltung bleiben vollständig im DomainCatcher-Konto.

API-Key bei DomainCatcher erstellen Endpunkte ansehen Über DomainCatcher

Nach dem Login: Account → API. Externer Link zu DomainCatcher.com – dort gelten die aktuellen Preise und Bedingungen.

Die API auf einen Blick

Für wen ist die API gedacht?

Die API ermöglicht keine vollständige Domainverwaltung und keine DNS-Verwaltung – sie deckt gezielt Backorder-, RGP-, ReCatch-, Free- und Domex-Prozesse ab.

Voraussetzungen für den API-Zugriff

• Ein aktives DomainCatcher-Konto.
• Ein Tier-Level, das API-Zugang erlaubt.
• API-Key aus: Account → API
• Ausreichendes DC-Prepaid-Guthaben für kostenpflichtige Aktionen.
• Endpoint-spezifische Berechtigung.
• Bei Domex-Käufen ein vollständig verifizierter Standardkontakt.
• Sichere serverseitige Speicherung des API-Keys.

Authentifizierung mit API-Key

Bevorzugter Header:

apiKey: DEIN_API_KEY

Weitere laut Dokumentation akzeptierte Formen:

X-Api-Key: DEIN_API_KEY
Authorization: Bearer DEIN_API_KEY

Außerdem technisch akzeptiert: auth_key im Body oder in der Query.

• API-Key niemals im Frontend speichern.
• API-Key niemals in lokalem Browser-JavaScript veröffentlichen.
• API-Key niemals in Git committen.
• API-Key niemals in Screenshots zeigen.
• API-Key niemals über Google Analytics übertragen.
• API-Key niemals als URL-Parameter in öffentlich sichtbaren Beispielen verwenden.
• Produktionsschlüssel nicht in Demo-Code einsetzen.
• Schlüssel serverseitig als Umgebungsvariable verwalten.
• Bei vermuteter Offenlegung Schlüssel im DomainCatcher-Konto erneuern.

Einheitliches JSON-Format

Alle Antworten folgen grundsätzlich diesem Muster:

{
  "success": true,
  "msg": "Lesbare Meldung",
  "data": {}
}

• success zeigt den grundsätzlichen Erfolg.
• msg enthält eine verständliche Meldung.
• data ist abhängig vom Endpunkt.
• Bei Fehlern kann data.error einen spezifischen Fehlercode enthalten.
• Eine HTTP-201-Antwort kann einen asynchronen Folgeprozess starten.

HTTP-Statuscodes

Weitere Statuscodes sind für diese Endpunkte nicht dokumentiert.

Warum data.restricted geprüft werden muss

Folgende List-Endpunkte können bei eingeschränktem Tier oder unzureichendem Guthaben nur eine Teaser- beziehungsweise erste Seite liefern: RGP, ReCatch, Free, Domex.

{
  "restricted": true,
  "total": 245,
  "count": 10,
  "domains": []
}

Eine erfolgreiche HTTP-Antwort bedeutet nicht automatisch, dass die vollständige Liste geliefert wurde. Anwendungen müssen data.restricted auswerten und dürfen eine Teaser-Liste nicht als vollständigen Bestand darstellen.

Alle aktuell dokumentierten Endpunkte

GET /api3/backorder

Zweck: Backorders des authentifizierten Nutzers abrufen.

Mindestens ein Parameter erforderlich: domain, status

Erlaubte Statuswerte: pending, pending extended, successful, unsuccessful, user storno

curl -X GET ' + NL + '  "https://api.domaincatcher.com/api3/backorder" ' + NL + '  -H "apiKey: DEIN_API_KEY" ' + NL + '  -H "Content-Type: application/json" ' + NL + '  -d '{"status":"pending"}'

Antwortdaten:

[
  {
    "domain": "dein-recatch.de",
    "order_date": "DATUM",
    "status": "pending",
    "drop_date": "DATUM"
  }
]

Die Beispieldaten sind Platzhalter; es werden keine echten Kunden- oder Auftragsdaten gezeigt.

POST /api3/backorder

Zweck: Neuen Backorder anlegen.

Pflichtparameter: domain

• nur .de
• Domain muss sich in der RGP befinden
• ausreichendes Guthaben
• Tier muss Backorders erlauben
• paralleles Backorder-Limit darf nicht überschritten sein

curl -X POST ' + NL + '  "https://api.domaincatcher.com/api3/backorder" ' + NL + '  -H "apiKey: DEIN_API_KEY" ' + NL + '  -H "Content-Type: application/json" ' + NL + '  -d '{"domain":"dein-recatch.de"}'

Mögliche Ergebnisse: 201 Created bei Erfolg, 400 Bad Request bei Domain-, RGP-, Guthaben- oder Limitproblemen, 403 Forbidden bei fehlender Tier-Berechtigung.

GET /api3/rgp

Zweck: RGP-Domains für einen Zeitraum oder über eine Freitextsuche abrufen.

Mindestens ein Parameter erforderlich: date

Erlaubte Werte: drop_in_30_days, drop_in_29_days, drop_in_2_days, drop_in_1_day, search

Bei search: mindestens drei Zeichen, erlaubte Zeichen gemäß Dokumentation, deutsche Umlaute und ß möglich.

curl -X GET ' + NL + '  "https://api.domaincatcher.com/api3/rgp" ' + NL + '  -H "apiKey: DEIN_API_KEY" ' + NL + '  -H "Content-Type: application/json" ' + NL + '  -d '{"date":"drop_in_1_day"}'

Antwortstruktur:

{
  "date": "drop_in_1_day",
  "restricted": false,
  "domains": [
    {
      "domain": "dein-recatch.de",
      "tld": "de",
      "drop_at": "DATUM",
      "did": "WERT",
      "blv": "WERT",
      "age": "WERT",
      "tlc": "WERT"
    }
  ]
}

Die Bewertungsfelder (did, blv, age, tlc) werden hier nicht frei interpretiert, da ihre genaue Skala in der bereitgestellten Dokumentation nicht spezifiziert ist.

GET /api3/recatch

Zweck: Aktuelle ReCatch-Liste abrufen.

Parameter (alle optional): search, limit, offset

Standard-Limit: 100 · Maximal-Limit: 500. Bei eingeschränktem Zugang wird die Liste gekürzt.

curl -X GET ' + NL + '  "https://api.domaincatcher.com/api3/recatch" ' + NL + '  -H "apiKey: DEIN_API_KEY" ' + NL + '  -H "Content-Type: application/json" ' + NL + '  -d '{"search":"recatch","limit":100,"offset":0}'

Antwortstruktur:

{
  "restricted": false,
  "total": 1,
  "offset": 0,
  "limit": 100,
  "count": 1,
  "domains": [
    {
      "domain": "dein-recatch.de",
      "tld": "de",
      "drop_at": "DATUM",
      "did": "WERT",
      "blv": "WERT",
      "age": "WERT",
      "tlc": "WERT",
      "recatchId": "WERT"
    }
  ]
}

total ist die Gesamtzahl, count die Zahl der gelieferten Einträge, offset und limit dienen der Seitennavigation, restricted zeigt eine begrenzte Ansicht.

POST /api3/recatch

Zweck: Eine ReCatch-Domain übernehmen.

Pflichtparameter: domain

Voraussetzungen: .de-Domain, Domain muss sich im richtigen ReCatch-/RGP-Status befinden, ausreichendes Prepaid-Guthaben, entsprechende Tier-Berechtigung, API-Zugang.

curl -X POST ' + NL + '  "https://api.domaincatcher.com/api3/recatch" ' + NL + '  -H "apiKey: DEIN_API_KEY" ' + NL + '  -H "Content-Type: application/json" ' + NL + '  -d '{"domain":"dein-recatch.de"}'

Antwort:

{
  "success": true,
  "msg": "Meldung",
  "data": {
    "pending": true
  }
}

pending: true bedeutet, dass die Reservierung beziehungsweise technische Verarbeitung noch läuft. Es darf nicht vorschnell ein endgültiger Erfolg angezeigt werden.

GET /api3/free

Zweck: Domains abrufen, die bereits gelöscht wurden und grundsätzlich neu registriert werden können.

Optionale Parameter: search, date, limit, offset

Datumswerte: dropToday, drop-1

Platzhaltersuche laut Dokumentation: ein führendes * sucht nach Endungen, ein abschließendes * sucht nach Präfixen, ein Sternchen mitten im Suchwort wird abgelehnt.

curl -X GET ' + NL + '  "https://api.domaincatcher.com/api3/free" ' + NL + '  -H "apiKey: DEIN_API_KEY" ' + NL + '  -H "Content-Type: application/json" ' + NL + '  -d '{"date":"dropToday","limit":100,"offset":0}'

Antwortfelder: date, restricted, total, offset, limit, count, domains, freeId

Eine Domain in der Free-Liste ist keine dauerhafte Verfügbarkeitsgarantie. Vor der tatsächlichen Registrierung wird die Verfügbarkeit erneut geprüft.

POST /api3/free

Zweck: Eine Domain aus der Free-Liste neu registrieren.

Pflichtparameter: domain

Voraussetzungen: nur .de, Domain muss noch in der Free-Liste stehen, Domain muss bei der Registry noch verfügbar sein, ausreichendes Guthaben, geeigneter und verifizierter Kontakt, sofern für den Prozess erforderlich.

curl -X POST ' + NL + '  "https://api.domaincatcher.com/api3/free" ' + NL + '  -H "apiKey: DEIN_API_KEY" ' + NL + '  -H "Content-Type: application/json" ' + NL + '  -d '{"domain":"DOMAIN-AUS-DER-FREE-LISTE.de"}'

Erfolgsdaten:

{
  "domain": "DOMAIN-AUS-DER-FREE-LISTE.de",
  "taskmanager_id": 123,
  "domain_id": 456,
  "netto": "BETRAG",
  "msg": "Meldung"
}

Die Registrierung wird asynchron über den Taskmanager verarbeitet. 201 Created bedeutet, dass der Prozess angelegt wurde; der endgültige Domainstatus muss anschließend geprüft werden. Keine Domain wird hier als tatsächlich frei dargestellt.

GET /api3/domex

Zweck: Aktuelle Domex-Angebote abrufen.

Optionale Parameter: search, tld, provider, minPrice, maxPrice, limit, offset

Provider-Werte: all, domex, user

Preislogik: price ist der für den Nutzer gültige Preis, is_netto zeigt, ob dieser Preis netto ausgegeben wird, price_netto ist immer der Nettopreis. Es wird keine pauschale Netto- oder Bruttopreisannahme getroffen.

curl -X GET ' + NL + '  "https://api.domaincatcher.com/api3/domex" ' + NL + '  -H "apiKey: DEIN_API_KEY" ' + NL + '  -H "Content-Type: application/json" ' + NL + '  -d '{"search":"burger","provider":"domex","limit":100,"offset":0}'

Relevante Antwortfelder: domain, tld, type, price, price_netto, is_netto, provider, did, blv, age, tlc, domainId, is_own_domain

domainId ist die eindeutige und bevorzugte ID für den anschließenden Domex-Kauf.

POST /api3/domex

Zweck: Eine Domain aus der Domex kaufen.

Pflichtparameter: einer von beiden – domain oder domain_id (bevorzugt domain_id).

curl -X POST ' + NL + '  "https://api.domaincatcher.com/api3/domex" ' + NL + '  -H "apiKey: DEIN_API_KEY" ' + NL + '  -H "Content-Type: application/json" ' + NL + '  -d '{"domain_id":12345}'

Voraussetzungen: Domain muss noch aktiv angeboten werden, Domain darf nicht dem Käufer selbst gehören, ausreichendes Guthaben, vollständig verifizierter Standardkontakt, Domain darf nicht bereits verkauft oder in Verarbeitung sein.

Dokumentierte Fehlercodes: not_found, own_domain, no_money, not_available, selling, billing_failed, nis2

nis2 wird mit 403 Forbidden ausgegeben; andere dokumentierte Fehler können in data.error erscheinen. Es werden keine eigenen Fehlercodes ergänzt.

Technische Besonderheit von GET-Anfragen

Die bereitgestellte Dokumentation zeigt mehrere GET-Anfragen mit JSON-Body. Einige HTTP-Clients, Browserbibliotheken, Proxys oder Caches behandeln GET-Requests mit Body unterschiedlich. Verwende deshalb die von DomainCatcher dokumentierte Request-Form und teste die gewählte serverseitige HTTP-Bibliothek. Es wird hier keine alternative Parameterübertragung erfunden, die nicht offiziell dokumentiert ist.

Aus diesem Grund verzichtet diese Seite bewusst auf Browser-fetch()-Beispiele mit GET-Body, da dies je nach Implementierung nicht zulässig beziehungsweise nicht zuverlässig ist. Bevorzugte Beispiele sind cURL und serverseitiges PHP cURL.

Was lässt sich mit der API automatisieren?

Vertiefend: Domain bewerten · Backlinks prüfen · Domainhistorie prüfen · Markenprüfung · ReCatch-Checkliste

Fehlerbehandlung für Integrationen

• HTTP-Statuscode prüfen.
• success prüfen.
• msg protokollieren.
• data.error prüfen.
• restricted bei Listen prüfen.
• Bei asynchronen Vorgängen pending beziehungsweise IDs speichern.
• Keine Kaufanfrage blind wiederholen.
• Bei Netzwerkfehlern mit Backoff arbeiten.
• Bei 401 API-Key nicht in Logs schreiben.
• Bei 400 nicht automatisch unendlich erneut senden.
• Bei 403 Tier- oder Kontaktstatus prüfen.
• Bei 500 keine Mehrfachkäufe durch aggressive Wiederholung riskieren.

Eine konkrete Retry-Frequenz wird hier nicht als offizielle API-Vorgabe ausgegeben, solange kein Rate Limit dokumentiert ist.

API-Key und Kaufaktionen absichern

• API-Key nur serverseitig verwenden.
• Secrets als Umgebungsvariablen speichern.
• Produktions- und Testsysteme trennen.
• Logs von Authentifizierungsheadern bereinigen.
• Kaufaktionen nicht ohne Plausibilitätsprüfung automatisieren.
• Domainname vor POST-Aufrufen normalisieren.
• Nur .de zulassen, wo der Endpunkt dies verlangt.
• Preis und Domain direkt vor dem Kauf erneut prüfen.
• Idempotenz nicht annehmen, wenn sie nicht dokumentiert ist.
• Fehlgeschlagene Requests nicht blind wiederholen.
• Guthaben und Tier-Berechtigung überwachen.
• Domex-Käufe bevorzugt mit domain_id durchführen.
• API-Schlüssel bei Verdacht auf Offenlegung sofort austauschen.
• Keine API-Antwort ungefiltert in öffentliches HTML schreiben.

Häufige Fragen zur DomainCatcher API

Weiterführend

Über DomainCatcher · Was ist ReCatch? · Backorder · RGP & freie Domains · Domex · Wirtschaftliche Verbindung · Redaktionelle Richtlinien · Datenschutz