Vérification de disponibilité de domaine
Présentation
Vérifie si un nom est disponible sur trois surfaces dont dépend généralement une décision de nommage de projet : les TLD de domaine, le nom de package npm et le nom d'utilisateur/organisation GitHub. Chaque vérification est un appel API gratuit et sans clé — exécutez-les ensemble lorsque l'utilisateur nomme quelque chose, ou seulement la vérification de domaine si c'est tout ce qui lui a été demandé.
API Domaine
GET https://domainee.dev/api/v1/tools/domain-availability-checker?name=<nom>&tlds=<tld>&tlds=<tld>...
name(obligatoire) — nom de domaine sans TLD, ex.mamarque.tlds(optionnel, répétable) — ex.?tlds=com&tlds=io. Omis → par défautcom, io, dev, app, co, net, org, me, ai, xyz.- Aucune authentification nécessaire. Utilisez toujours l'hôte
domainee.dev/api/..., pasapi.domainee.dev— la page de documentation mentionne cet hôte mais il retourne 401 ("Missing Bearer token") ; le point d'accès fonctionnel et compatible CORS est sur la même origine sousdomainee.dev/api.
Limite de débit : 30 req/min, 500 req/jour par IP. Le quota restant est dans les en-têtes de réponse x-ratelimit-remaining-minute / x-ratelimit-remaining-day. Un 429 inclut Retry-After — présentez-le à l'utilisateur plutôt que de réessayer silencieusement.
Succès :
{"ok":true,"data":{"name":"google","results":[
{"tld":"com","fqdn":"google.com","available":false,"registrarHint":null},
{"tld":"io","fqdn":"google.io","available":true,"registrarHint":null}
]}}
Erreur (ex. name manquant) :
{"ok":false,"error":{"code":"missing_param","message":"Le paramètre de requête `name` est requis (ex. ?name=mamarque)"}}
Un TLD non reconnu n'est pas une erreur — il revient simplement avec un tableau results vide.
Une recherche par registre TLD peut également expirer. L'entrée de ce TLD aura alors "available":null et un registrarHint expliquant pourquoi (ex. "L'opération a été annulée en raison d'un délai d'attente dépassé"), tandis que ok reste true et les autres TLD de la même réponse ne sont pas affectés. Traitez null comme inconnu, pas comme disponible ou pris — affichez-le comme une ligne distincte "impossible de vérifier" plutôt que de deviner. Si tous les TLD de la réponse reviennent null en même temps, c'est un hoquet transitoire sur l'ensemble de la requête, pas 10 timeouts coïncidents — réessayez l'appel une fois avant de signaler un résultat tout inconnu à l'utilisateur.
API Nom de package npm
GET https://registry.npmjs.org/<nom>
Pas d'authentification, pas d'en-têtes de limite de débit à craindre en pratique. 200 = nom pris (un package réel existe), 404 = libre. Pour les noms scopés (@scope/nom), encodez la barre oblique dans l'URL : https://registry.npmjs.org/@scope%2Fnom.
API Nom d'utilisateur/organisation GitHub
GET https://api.github.com/users/<nom>
Aucune authentification requise. 200 = pris, 404 = libre. Les requêtes non authentifiées sont limitées à 60/heure par IP (en-tête x-ratelimit-remaining) — suffisant pour quelques vérifications, mais ne bouclez pas sur une grande liste de noms candidats.
Workflow
- Supprimez tout TLD déjà tapé par l'utilisateur pour obtenir le
nomnu. - Si l'utilisateur demande simplement un domaine, appelez uniquement l'API domaine. S'il nomme un projet/startup/package/outil, exécutez les trois vérifications (domaine, npm, GitHub) pour ce seul
nom— cette combinaison est le véritable objectif de la compétence, pas les domaines isolément. - Appelez l'API domaine. Si l'utilisateur n'a pas spécifié de TLD particuliers, omettez
tldspour obtenir l'ensemble par défaut des 10 extensions. - Affichez un résumé combiné : un tableau des TLD (disponible ✅ / pris ❌ / inconnu-timeout ⚠️, d'après
registrarHint), plus une ligne chacun pour npm et GitHub (✅/❌). - Demandez une fois si l'utilisateur souhaite vérifier plus de TLD (suggérez-en quelques-uns non déjà couverts, ex.
.ai,.so, un ccTLD) — ne reposez pas la question pour le même nom à moins que l'utilisateur ne le mentionne à nouveau. - S'il nomme d'autres TLD, répétez l'appel domaine avec seulement ces
tldset affichez les nouveaux résultats.
Les handles sociaux (X, Instagram, etc.) sont délibérément exclus — aucune de ces plateformes n'expose une vérification de disponibilité gratuite et non authentifiée ; le scraping des pages de profil n'est pas fiable et va à l'encontre de la plupart de leurs conditions d'utilisation. Dites-le si on vous le demande, plutôt que de deviner à partir d'un scrape.
Exemple
curl -s "https://domainee.dev/api/v1/tools/domain-availability-checker?name=mamarque&tlds=com&tlds=io&tlds=ai"
curl -s -o /dev/null -w "%{http_code}" "https://registry.npmjs.org/mamarque"
curl -s -o /dev/null -w "%{http_code}" "https://api.github.com/users/mamarque"
Erreurs courantes
- Utiliser
api.domainee.dev— mauvais hôte, retourne 401. Utilisezdomainee.dev/api/.... - Traiter un tableau
resultsvide comme un échec — cela signifie que le TLD n'a pas été reconnu, pas une erreur. - Réessayer immédiatement après un 429 — respectez
Retry-Afteret informez l'utilisateur, ne bouclez pas. - Vérifier npm/GitHub pour une simple question "ce domaine est-il libre ?" — n'interrogez ces API que lorsque l'utilisateur nomme réellement quelque chose, pas pour chaque recherche de domaine.
- Prétendre vérifier les handles sociaux — il n'existe pas d'API fiable et gratuite pour cela ; dites que c'est hors du cadre.