API DomainCatcher : rechercher, commander et automatiser des domaines

Auteur: Leo Kobes Publié le: 22 juillet 2026 Mis à jour le: 3 août 2026 Informations produit à jour au: 3 août 2026

Nouveau · API REST · Automatisation

La nouvelle API DomainCatcher permet de récupérer et créer des backorders, de rechercher des domaines RGP et ReCatch, de reprendre des domaines ReCatch, d'enregistrer des domaines .de libres et d'acheter des domaines sur la Domex. L'interface s'adresse aux investisseurs en domaines, aux éditeurs, aux équipes SEO et aux développeurs souhaitant automatiser des processus de domaines récurrents.

L'API est fournie techniquement et contractuellement par DomainCatcher.com. deinrecatch.de explique les endpoints disponibles, les prérequis, les réponses et les règles de sécurité. La clé API, le solde, les achats et la gestion des domaines restent entièrement dans le compte DomainCatcher.

Créer une clé API chez DomainCatcher Voir les endpoints À propos de DomainCatcher

Après connexion : Account → API. Lien externe vers DomainCatcher.com – les prix et conditions actuels y sont applicables.

L'API en un coup d'œil

À qui s'adresse l'API ?

L'API ne permet pas une gestion complète des domaines ni une gestion DNS – elle couvre spécifiquement les processus de backorder, RGP, ReCatch, Free et Domex.

Prérequis pour l'accès à l'API

• Un compte DomainCatcher actif.
• Un niveau de Tier autorisant l'accès à l'API.
• Clé API depuis : Account → API
• Un solde prépayé DC suffisant pour les actions payantes.
• Une autorisation spécifique à l'endpoint.
• Pour les achats Domex, un contact standard entièrement vérifié.
• Un stockage sécurisé côté serveur de la clé API.

Authentification par clé API

En-tête préféré :

apiKey: DEIN_API_KEY

Autres formes acceptées selon la documentation :

X-Api-Key: DEIN_API_KEY
Authorization: Bearer DEIN_API_KEY

Également accepté techniquement : auth_key dans le corps ou la requête.

• Ne jamais stocker la clé API dans le frontend.
• Ne jamais publier la clé API dans du JavaScript navigateur accessible publiquement.
• Ne jamais committer la clé API dans Git.
• Ne jamais montrer la clé API dans des captures d'écran.
• Ne jamais transmettre la clé API via Google Analytics.
• Ne jamais utiliser la clé API comme paramètre d'URL dans des exemples publiquement visibles.
• Ne pas utiliser de clés de production dans du code de démonstration.
• Gérer la clé côté serveur comme variable d'environnement.
• Renouveler la clé dans le compte DomainCatcher immédiatement en cas de suspicion de divulgation.

Format JSON unifié

Toutes les réponses suivent globalement ce schéma :

{
  "success": true,
  "msg": "…",
  "data": {}
}

• success indique le succès général.
• msg contient un message compréhensible.
• data dépend de l'endpoint.
• En cas d'erreur, data.error peut contenir un code d'erreur spécifique.
• Une réponse HTTP 201 peut démarrer un processus asynchrone consécutif.

Codes de statut HTTP

Aucun autre code de statut n'est documenté pour ces endpoints.

Pourquoi il faut vérifier data.restricted

Les endpoints de liste suivants peuvent, en cas de Tier restreint ou de solde insuffisant, ne fournir qu'un aperçu ou une première page : RGP, ReCatch, Free, Domex.

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

Une réponse HTTP réussie ne signifie pas automatiquement que la liste complète a été fournie. Les applications doivent évaluer data.restricted et ne doivent pas présenter une liste partielle comme un inventaire complet.

Tous les endpoints actuellement documentés

GET /api3/backorder

Objectif: Récupérer les backorders de l'utilisateur authentifié.

Au moins un paramètre requis : domain, status

Valeurs de statut autorisées : pending, pending extended, successful, unsuccessful, user storno

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

Données de réponse :

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

Les données d'exemple sont fictives ; aucune donnée réelle de client ou de commande n'est affichée.

POST /api3/backorder

Objectif: Créer un nouveau backorder.

Paramètre obligatoire: domain

• .de uniquement
• le domaine doit être en RGP
• solde suffisant
• le Tier doit autoriser les backorders
• la limite parallèle de backorders ne doit pas être dépassée

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

Résultats possibles : 201 Created en cas de succès, 400 Bad Request en cas de problème de domaine, de RGP, de solde ou de limite, 403 Forbidden en cas d'autorisation de Tier manquante.

GET /api3/rgp

Objectif: Récupérer les domaines RGP pour une période ou via une recherche libre.

Paramètre obligatoire: date

Valeurs autorisées : drop_in_30_days, drop_in_29_days, drop_in_2_days, drop_in_1_day, search

Pour search : au moins trois caractères, caractères autorisés selon la documentation, trémas allemands et ß possibles.

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

Structure de la réponse :

{
  "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"
    }
  ]
}

Les champs d'évaluation (did, blv, age, tlc) ne sont pas librement interprétés ici, leur échelle exacte n'étant pas précisée dans la documentation fournie.

GET /api3/recatch

Objectif: Récupérer la liste ReCatch actuelle.

Paramètres (tous facultatifs) : search, limit, offset

Limite par défaut : 100 · Limite maximale : 500. La liste est raccourcie en cas d'accès restreint.

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

Structure de la réponse :

{
  "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 est le nombre total, count le nombre d'entrées fournies, offset et limit servent à la pagination, restricted indique une vue limitée.

POST /api3/recatch

Objectif: Reprendre un domaine ReCatch.

Paramètre obligatoire: domain

Prérequis: domaine .de, le domaine doit être dans le bon statut ReCatch/RGP, solde prépayé suffisant, autorisation de Tier correspondante, accès à l'API.

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

Réponse :

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

pending: true signifie que la réservation ou le traitement technique est encore en cours. Un succès définitif ne doit pas être affiché prématurément.

GET /api3/free

Objectif: Récupérer les domaines déjà supprimés et pouvant en principe être à nouveau enregistrés.

Paramètres facultatifs : search, date, limit, offset

Valeurs de date : dropToday, drop-1

Recherche par caractères génériques selon la documentation : un * en tête recherche des suffixes, un * final recherche des préfixes, un astérisque au milieu du terme de recherche est rejeté.

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

Champs de réponse : date, restricted, total, offset, limit, count, domains, freeId

Un domaine dans la liste Free ne constitue pas une garantie de disponibilité permanente. La disponibilité est revérifiée avant l'enregistrement effectif.

POST /api3/free

Objectif: Enregistrer à nouveau un domaine de la liste Free.

Paramètre obligatoire: domain

Prérequis: .de uniquement, le domaine doit encore figurer dans la liste Free, le domaine doit encore être disponible auprès du registre, solde suffisant, contact adapté et vérifié si le processus l'exige.

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

Données de succès :

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

L'enregistrement est traité de manière asynchrone via le gestionnaire de tâches. 201 Created signifie que le processus a été créé ; le statut final du domaine doit ensuite être vérifié. Aucun domaine n'est présenté ici comme réellement libre.

GET /api3/domex

Objectif: Récupérer les offres Domex actuelles.

Paramètres facultatifs : search, tld, provider, minPrice, maxPrice, limit, offset

Valeurs de provider : all, domex, user

Logique de prix : price est le prix applicable à l'utilisateur, is_netto indique si ce prix est affiché hors taxes, price_netto est toujours le prix hors taxes. Aucune hypothèse générale n'est faite sur un prix HT ou TTC.

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

Champs de réponse pertinents : domain, tld, type, price, price_netto, is_netto, provider, did, blv, age, tlc, domainId, is_own_domain

domainId est l'identifiant unique et privilégié pour l'achat Domex qui suit.

POST /api3/domex

Objectif: Acheter un domaine de la Domex.

Paramètre obligatoire: l'un des deux – domain ou domain_id (domain_id étant préféré).

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

Prérequis: le domaine doit encore être activement proposé, le domaine ne doit pas appartenir à l'acheteur lui-même, solde suffisant, contact standard entièrement vérifié, le domaine ne doit pas être déjà vendu ou en cours de traitement.

Codes d'erreur documentés : not_found, own_domain, no_money, not_available, selling, billing_failed, nis2

nis2 est renvoyé avec 403 Forbidden ; d'autres erreurs documentées peuvent apparaître dans data.error. Aucun code d'erreur propre n'est ajouté ici.

Particularité technique des requêtes GET

La documentation fournie montre plusieurs requêtes GET avec un corps JSON. Certains clients HTTP, bibliothèques navigateur, proxys ou caches traitent différemment les requêtes GET avec corps. Utilisez donc la forme de requête documentée par DomainCatcher et testez la bibliothèque HTTP côté serveur choisie. Aucune transmission alternative de paramètres non officiellement documentée n'est inventée ici.

Pour cette raison, cette page évite délibérément les exemples fetch() navigateur avec un corps GET, cela n'étant pas autorisé, ou pas fiable, selon l'implémentation. Les exemples privilégiés sont cURL et PHP cURL côté serveur.

Que peut-on automatiser avec l'API ?

Pour aller plus loin : Évaluer un domaine · Vérifier les backlinks · Vérifier l'historique du domaine · Vérification des marques · Checklist ReCatch

Gestion des erreurs pour les intégrations

• Vérifier le code de statut HTTP.
• Vérifier success.
• Journaliser msg.
• Vérifier data.error.
• Vérifier restricted pour les listes.
• Pour les processus asynchrones, stocker pending ou les identifiants.
• Ne pas répéter aveuglément une demande d'achat.
• En cas d'erreurs réseau, utiliser un backoff.
• En cas de 401, ne pas écrire la clé API dans les journaux.
• En cas de 400, ne pas relancer automatiquement à l'infini.
• En cas de 403, vérifier le statut du Tier ou du contact.
• En cas de 500, ne pas risquer des achats multiples par des relances agressives.

Aucune fréquence de relance concrète n'est indiquée ici comme exigence officielle de l'API, tant qu'aucune limite de requêtes n'est documentée.

Sécuriser la clé API et les actions d'achat

• Utiliser la clé API uniquement côté serveur.
• Stocker les secrets en variables d'environnement.
• Séparer les systèmes de production et de test.
• Nettoyer les en-têtes d'authentification des journaux.
• Ne pas automatiser les actions d'achat sans contrôle de plausibilité.
• Normaliser le nom de domaine avant les appels POST.
• N'autoriser que .de là où l'endpoint l'exige.
• Revérifier le prix et le domaine juste avant l'achat.
• Ne pas supposer l'idempotence si elle n'est pas documentée.
• Ne pas relancer aveuglément les requêtes échouées.
• Surveiller le solde et l'autorisation de Tier.
• Effectuer les achats Domex de préférence avec domain_id.
• Remplacer immédiatement la clé API en cas de suspicion de divulgation.
• Ne jamais écrire une réponse d'API non filtrée dans du HTML public.

Questions fréquentes sur l'API DomainCatcher

Pour aller plus loin

À propos de DomainCatcher · Qu'est-ce que ReCatch ? · Backorder · RGP et domaines libres · Domex · Lien économique · Charte éditoriale · Confidentialité