API de domaine - Liste des commandes API

Bien démarrer avec notre API RESTful

L'API Dynadot est conçue pour une intégration transparente avec vos systèmes. Notre API propose des URL prévisibles orientées ressources, prend en charge les corps de requête encodés en JSON, renvoie des réponses encodées en JSON et en XML, et respecte les méthodes HTTP, l'authentification et les codes de réponse standard.

Vous pouvez utiliser l'API Dynadot en mode test et en mode live. Le mode est déterminé par la clé API utilisée pour authentifier vos requêtes. Le mode test vous permet de simuler et de valider votre intégration API sans affecter les données ou transactions réelles.

L'API Dynadot est principalement axée sur la gestion de domaines, le traitement des commandes et les services associés. Vous pouvez effectuer des actions telles que l'enregistrement, le transfert et le renouvellement de domaines, la gestion des paramètres DNS, et la consultation ou la mise à jour des commandes du compte.

Veuillez noter: Les créations, mises à jour et suppressions en masse ne sont pas prises en charge, et chacun de ces types de requête est limité à un objet ou une action.

Génération de vos clés API

Avant de commencer à effectuer des requêtes API, il est essentiel de générer votre clé API et votre secret API.

Ces clés sont requises pour l'authentification et pour garantir la sécurité de vos actions lorsque vous interagissez avec notre API.

Vous pouvez générer à la fois la clé API et le secret API via la section API dans les paramètres de votre compte.

1. Connectez-vous à votre compte sur Dynadot.

2. Accédez à Outils > API.

3. Générez votre Clé API et votre Secret API à partir de cette page.

Rejoignez notre communauté

Des idées ou des suggestions ? Parlez directement à nos ingénieurs professionnels.

Discord

Méthode HTTP

L'API utilise les méthodes HTTP standard pour effectuer des opérations sur les ressources :

Méthode	Description
GET	Requête GET : Récupérer des informations détaillées sur une ressource spécifiée
POST	Requête POST: Créer une nouvelle ressource
PUT	Requête PUT : mettre entièrement à jour la ressource spécifiée
DELETE	Requête DELETE : Supprimer la ressource spécifiée

URL

L'URL de base pour toutes les requêtes API est :

https://api.dynadot.com/

Le format complet de l'URL:

http://api.dynadot.com/restful/version_code/resource/{resource_identify}/action

https://api.dynadot.com/restful/v2/domains/{domain_name}/search

Version

La version actuelle de l'API est v2.0.0

Lorsque vous construisez l'URL de requête de l'API, il suffit d'inclure la version majeure. Les mises à jour mineures et correctives sont conçues pour être rétrocompatibles et n'introduiront pas de changements qui cassent votre code existant. Cela garantit la stabilité tout en vous permettant de bénéficier d'améliorations progressives et de correctifs sans avoir à modifier votre implémentation.

Lorsque de futures versions seront publiées, nous maintiendrons la compatibilité ascendante pour les anciennes versions pendant un certain temps. De nouvelles fonctionnalités et des changements majeurs seront introduits dans les versions majeures.

En-tête

L'en-tête d'une requête API contient des métadonnées sur la requête. Ces métadonnées fournissent un contexte essentiel au serveur pour traiter correctement la requête. Les en-têtes couramment utilisés incluent :

Content-Type

Spécifie le format des données envoyées dans le corps de la requête. Le serveur utilise ces informations pour analyser correctement la requête. Actuellement, la seule valeur acceptable est : application/json

Content-Type: application/json

Accepter

Informe le serveur du format de réponse attendu par le client.

Valeurs possibles : application/json, application/xml

Accept: application/json

Autorisation

Toutes les requêtes API doivent inclure une clé API pour l'authentification. Vous pouvez obtenir votre clé API depuis le tableau de bord de votre compte.

Vous pouvez générer une clé API dans la page des paramètres API

Authorization: Bearer YOUR_API_KEY

X-Request-ID

L'en-tête X-Request-ID est un en-tête (Optionnel) utilisé pour identifier de manière unique chaque requête API. Lorsqu'il est inclus, cet en-tête aide à suivre et corréler les requêtes à travers les systèmes et les journaux, ce qui facilite le débogage et la surveillance de l'activité de l'API.

La valeur de X-Request-ID doit être un UUID valide (identifiant unique universel), selon le format standard : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (par ex., 123e4567-e89b-12d3-a456-426614174000).

X-Request-ID: 550e8400-e29b-41d4-a716-446655440000

X-Signature Nouveau

L'en-tête X-Signature est un mécanisme de sécurité obligatoire pour les requêtes transactionnelles, y compris celles qui récupèrent des informations sensibles ou mettent à jour des données. Il garantit l'authenticité, l'intégrité et la non-répudiation des requêtes API en exigeant que les clients signent la charge utile de la requête à l'aide de HMAC-SHA256.

Pour générer la signature, vous aurez besoin des valeurs suivantes

1. Clé API: Votre clé API unique.

2. Chemin complet et requête: Le chemin complet du point de terminaison de l'API ainsi que les paramètres de requête.

3. X-Request-Id: L'ID de la requête. S'il n'est pas disponible, vous pouvez saisir une chaîne vide.

4. Corps de la requête: Le corps de la requête. S'il est vide ou nul, vous pouvez saisir une chaîne vide.

La chaîne à signer est une combinaison des valeurs mentionnées ci-dessus, concaténées dans l'ordre suivant :

apiKey + "\n" + fullPathAndQuery + "\n" + (xRequestId or empty String) + "\n" + (requestBody or empty String)

apiKey = "your_api_key"
fullPathAndQuery = "/restful/v2/some/endpoint?param=value"
xRequestId = "unique-request-id"
requestBody = "{\"key\":\"value\"}"

stringToSign = "your_api_key\n/restful/v2/some/endpoint?param=value\nunique-request-id\n{\"key\":\"value\"}"

Générer la signature HMAC-SHA256

Après avoir construit stringToSign, calculez la signature en utilisant HMAC-SHA256 avec votre secret comme clé, puis Encoder en Base64 le résultat.

La signature est générée en utilisant les étapes suivantes:

1. Utilisez l'algorithme HMAC-SHA256.

2. Utilisez stringToSign (UTF-8) comme message d'entrée.

3. Utilisez votre secret (UTF-8) comme clé.

4. Encodez la sortie HMAC en Base64 (Base64 standard)

Utilisez le Signature généré comme valeur de X-Signature dans l'en-tête de la requête

X-Signature: {HMAC-SHA256 Signature}

import base64
import hashlib
import hmac
import uuid

def create_signature(api_key, api_secret, full_path_and_query, x_request_id, request_body=""):
    string_to_sign = (
        api_key + "\n" +
        full_path_and_query + "\n" +
        (x_request_id or "") + "\n" +
        (request_body or "")
    )

    digest = hmac.new(
        api_secret.encode("utf-8"),
        string_to_sign.encode("utf-8"),
        hashlib.sha256
    ).digest()

    return base64.b64encode(digest).decode("utf-8")

api_key = "your_api_key"
api_secret = "your_secret"
full_path_and_query = "/restful/v2/accounts/info"
x_request_id = str(uuid.uuid4())
request_body = ""

x_signature = create_signature(
    api_key,
    api_secret,
    full_path_and_query,
    x_request_id,
    request_body
)

print("X-Request-ID:", x_request_id)
print("X-Signature:", x_signature)

Corps

Le corps d'une requête API est utilisé pour envoyer des données au serveur. Il est couramment inclus dans les requêtes POST, PUT ou PATCH (généralement pas pour les requêtes GET ou DELETE).

Format du contenu

Le format des données du corps est déterminé par l'en-tête Content-Type. Voici quelques formats courants :

Cas d'utilisation typiques

Requêtes POST: La méthode POST est utilisée pour créer une nouvelle ressource sur le serveur. Le corps de la requête contient généralement les détails de la ressource..

Requêtes PUT: La méthode PUT est utilisée pour mettre à jour une ressource existante en la remplaçant entièrement. Le corps de la requête contient la ressource mise à jour complète.

Requêtes DELETE: La méthode DELETE est utilisée pour supprimer une ressource existante du serveur. Il n'a pas de corps de requête..

Requêtes GET: La méthode GET est utilisée pour récupérer une ressource existante depuis le serveur. Il n'a pas de corps de requête.

Format de réponse

Toutes les réponses de l'API sont renvoyées au format JSON ou XML, le format des données du corps étant déterminé par l'en-tête Accept, fournissant les données demandées ou un message d'erreur, le cas échéant.

Format du contenu

La réponse en général contient 3 parties : Code, Message, Données

Code : Le statut de la requête

Message : Plus de détails sur le statut

Données: Le corps de la réponse

Gestion des erreurs

Les codes d'état HTTP sont des nombres à trois chiffres standardisés renvoyés par un serveur pour indiquer le résultat de la requête d'un client. Ils fournissent des informations essentielles sur la question de savoir si la requête a été traitée avec succès, nécessite une action supplémentaire ou a rencontré une erreur. Ces codes sont divisés en cinq catégories, chacune représentant un type de réponse distinct.

Les codes d'état de notre API respectent le protocole HTTP/1.1, une norme largement acceptée qui garantit une communication cohérente et fiable. En utilisant HTTP/1.1, nous exploitons des fonctionnalités comme les connexions persistantes et la mise en cache améliorée pour optimiser les interactions client-serveur.

Aperçu des webhooks

Les Webhooks sont un outil puissant pour automatiser les processus et intégrer les systèmes. Ils vous permettent de recevoir des notifications en temps réel concernant des événements ou des modifications dans votre compte ou les paramètres de votre domaine. En configurant des webhooks, vous pouvez déclencher des actions dans des systèmes externes, mettre à jour des bases de données ou envoyer des notifications en fonction d'événements spécifiques.

L'API Dynadot prend en charge les notifications webhook pour divers événements, tels que l'enregistrement, le transfert, le renouvellement et l'expiration de noms de domaine, afin que vous puissiez prendre les mesures appropriées en réponse.

Pour utiliser les webhooks, vous devez fournir une URL de point de terminaison où les notifications seront envoyées. Vous pouvez configurer l'URL, la clé et le secret de votre webhook dans les paramètres de votre compte. Lorsqu'un événement se produit, Dynadot enverra une requête POST à l'URL spécifiée avec les données pertinentes.

En-tête de requête Webhook

L'en-tête d'une requête Webhook contient des métadonnées sur la requête. Ces métadonnées fournissent un contexte essentiel au serveur pour traiter correctement la requête. Les en-têtes couramment utilisés incluent:

Content-Type

Spécifie le format des données envoyées dans le corps de la requête. Le serveur utilise ces informations pour analyser correctement la requête. Actuellement, la seule valeur acceptable est : application/json

Content-Type: application/json

Autorisation

Toutes les requêtes Webhook incluront une clé Webhook pour l'authentification. Vous pouvez obtenir votre clé Webhook à partir du tableau de bord de votre compte.

Vous pouvez gérer votre WEBHOOK_KEY dans la page des paramètres de l'API

Authorization: Bearer WEBHOOK_KEY

X-Signature

L'en-tête X-Signature est un mécanisme de sécurité obligatoire pour les requêtes transactionnelles, y compris celles qui récupèrent des informations sensibles ou mettent à jour des données. Il garantit l'authenticité, l'intégrité et la non-répudiation des requêtes Webhook en exigeant des clients qu'ils signent la charge utile de la requête à l'aide de HMAC-SHA256.

Pour générer la signature, vous aurez besoin des valeurs suivantes

1. Clé WEBHOOK : Votre clé WEBHOOK unique.

2. Chemin complet et requête: Le chemin complet du point de terminaison WEBHOOK ainsi que les paramètres de requête.

3. X-Request-Id: L'ID de la requête. S'il n'est pas disponible, vous pouvez saisir une chaîne vide.

4. Corps de la requête: Le corps de la requête. S'il est vide ou nul, vous pouvez saisir une chaîne vide.

La chaîne à signer est une combinaison des valeurs mentionnées ci-dessus, concaténées dans l'ordre suivant :

webhookKey + "\n" + fullPathAndQuery + "\n" + (xRequestId or empty String) + "\n" + (requestBody or empty String)

webhookKey = "your_webhook_key"
fullPathAndQuery = "/v2/some/endpoint?param=value"
xRequestId = "unique-request-id"
requestBody = "{\"key\":\"value\"}"

stringToSign = "your_webhook_key\n/v2/some/endpoint?param=value\nunique-request-id\n{\"key\":\"value\"}"

Générer la signature HMAC-SHA256

Après avoir construit stringToSign, calculez la signature en utilisant HMAC-SHA256 avec votre secret comme clé, puis Encoder en Base64 le résultat.

La signature est générée en utilisant les étapes suivantes:

1. Utilisez l'algorithme HMAC-SHA256.

2. Utilisez stringToSign (UTF-8) comme message d'entrée.

3. Utilisez votre secret (UTF-8) comme clé.

4. Encodez la sortie HMAC en Base64 (Base64 standard)

Utilisez le Signature généré comme valeur de X-Signature dans l'en-tête de la requête

X-Signature: {HMAC-SHA256 Signature}

import base64
import hashlib
import hmac
import uuid

def create_signature(webhook_key, webhook_secret, full_path_and_query, x_request_id, request_body=""):
    string_to_sign = (
        webhook_key + "\n" +
        full_path_and_query + "\n" +
        (x_request_id or "") + "\n" +
        (request_body or "")
    )

    digest = hmac.new(
        webhook_secret.encode("utf-8"),
        string_to_sign.encode("utf-8"),
        hashlib.sha256
    ).digest()

    return base64.b64encode(digest).decode("utf-8")

webhook_key = "your_webhook_key"
webhook_secret = "your_secret"
full_path_and_query = "/v2/some/webhook/path"
x_request_id = str(uuid.uuid4())
request_body = ""

x_signature = create_signature(
    webhook_key,
    webhook_secret,
    full_path_and_query,
    x_request_id,
    request_body
)

print("X-Request-ID:", x_request_id)
print("X-Signature:", x_signature)

Format de requête webhook

Format du contenu

Le corps d'une requête webhook contient des informations sur l'événement qui a déclenché la notification. Le format des données du corps est déterminé par l'en-tête Content-Type, qui est généralement application/json.

Le corps de la requête inclut les paramètres suivants:

Exemple :

Paramètres

Le corps de la requête contient les paramètres suivants :

Paramètre	Description
Événement	Le type d'événement qui a déclenché la notification.
event_id	L'id de l'événement qui a déclenché la notification.
horodatage	L'horodatage du moment où l'événement s'est produit.
données	Les données associées à l'événement.

Format de réponse du webhook

Format du contenu

La réponse à une requête webhook sera envoyée au format JSON, selon l'en-tête Content-Type spécifié dans la requête.

Le corps de la réponse contient des informations sur l'état de la requête, telles que si elle a été traitée avec succès ou si elle a rencontré une erreur.

La réponse contient généralement 1 partie : Statut

Exemple :

Limitation de débit

Les requêtes doivent être envoyées via https (socket sécurisé) pour des raisons de sécurité. Une seule requête peut être traitée à la fois, alors veuillez attendre que votre requête actuelle soit terminée avant d'en envoyer une autre.

Vous recevrez différents nombres de threads en fonction du niveau de prix de votre compte :

Niveau de prix	Nombre de threads	Limite de débit
Régulier	1 thread	60/min (1/s)
Bulk	5 threads	600/min (10/sec)
Super Bulk	35 threads	6000/min (100/sec)

Remarque : place_auction_bid & get_auction_bid sont actuellement exemptés de la limite de débit ci-dessus.

Pour la commande d'évaluation de domaine, vous recevrez différents nombres de requêtes autorisées en fonction du niveau de prix de votre compte :

Niveau de prix	Limite de débit
Régulier	50/jour
Bulk	100/jour
Super Bulk	300/jour

Sandbox

L'environnement Sandbox de l'API Dynadot vous permet de tester en toute sécurité vos intégrations API sans affecter votre compte en production ni vos fonds réels.

Comment accéder à la Sandbox

1. Connectez-vous à votre compte Dynadot et accédez à la page des paramètres de l'API :

2. https://www.dynadot.com/account/domain/setting/api.html

3. Générez votre clé API Sandbox et votre clé secrète API Sandbox.

4. Après la génération, veuillez laisser un peu de temps au système pour activer vos clés de bac à sable et créer votre compte de bac à sable.

5. Votre compte Sandbox sera préalimenté d'un solde de 10 000 dans toutes les devises prises en charge à des fins de test.

Utilisation de l'API Sandbox

Les commandes API dans l'environnement Sandbox sont fonctionnellement identiques à l'environnement de production.

La seule différence est l'URL de base:

URL de l'API de production: https://api.dynadot.com

URL de l'API Sandbox : https://api-sandbox.dynadot.com

Notes importantes

Certaines commandes API peuvent être indisponibles dans l'environnement Sandbox. Veuillez vous référer à la documentation de la commande spécifique pour vérifier le libellé "Assistance API Sandbox".

Le Sandbox est principalement conçu pour les tests. Certaines commandes peuvent différer de la Production, et le Sandbox ne peut pas simuler entièrement tous les scénarios complexes possibles présent dans l'environnement de Production.

Aperçu du journal des modifications

Un journal des modifications est un enregistrement détaillé des changements, améliorations, corrections de bugs et nouvelles fonctionnalités introduits dans chaque version de l'API. Il offre de la transparence aux utilisateurs et aux développeurs en documentant l'impact de chaque mise à jour. Il se compose de deux parties clés:

Version de l'API

Cette partie met en avant le système de gestion des versions de l'API, qui aide les développeurs à suivre l'évolution des fonctionnalités et à garantir la compatibilité. Chaque version de l'API est identifiée par un numéro de version unique (par ex., v1.0.1, v2.2.3) et représente une étape ou une version importante. La gestion des versions permet aux utilisateurs de maintenir leurs intégrations avec un minimum de perturbations en optant pour les mises à jour quand ils sont prêts.

Historique des modifications

L'historique des modifications fournit des informations détaillées sur les mises à jour, les corrections de bugs, les dépréciations et les améliorations introduites dans chaque version. Il décrit les changements spécifiques apportés aux points de terminaison, aux paramètres, aux mécanismes d'authentification ou aux formats de réponse. Cette section garantit aux développeurs une transparence totale sur ce qui a changé et leur permet d'adapter leurs implémentations en conséquence. En tenant un journal des modifications clair et détaillé, nous visons à fournir aux développeurs les outils et les informations nécessaires pour gérer les intégrations efficacement et en toute confiance.

Version de l'API

Notre API est actuellement en version v2.0.0

Les codes de version sont utilisés pour identifier et gérer systématiquement les mises à jour de l'API. Ils suivent le format de gestion sémantique des versions (SemVer) :

Chaque composant du code de version remplit un objectif spécifique et aide les développeurs à communiquer efficacement la portée et le type des modifications.

Version majeure

Définition : Représente des changements importants susceptibles de casser la rétrocompatibilité.

Format:

x.<Minor>.x

Exemples : v1.0.0 -> v2.0.0 : une refonte complète de l'API ou des modifications de schéma incompatibles.

Version mineure

Définition : indique des ajouts de fonctionnalités rétrocompatibles.

Format:

x.<Minor>.x

Exemples : v1.0.0 -> v1.1.0 : Ajout de nouveaux points de terminaison ou méthodes tout en conservant la compatibilité ascendante.

Version du correctif

Définition : fait référence à des corrections de bogues rétrocompatibles ou à des améliorations mineures.

Format:

x.x.<Patch>

Exemples: v1.0.0 -> v1.1.0: Correction d'un bug mineur dans un endpoint d'API.

Journal des modifications de l'API

Un journal des modifications est un enregistrement détaillé des changements, améliorations, corrections de bugs et nouvelles fonctionnalités introduits dans chaque version d'un logiciel ou d'une API. Il apporte de la transparence aux utilisateurs et aux développeurs en documentant l'impact de chaque mise à jour.

Une entrée typique dans un journal des modifications comprend :

Description : Une brève explication de ce qui a été modifié.

Composants concernés: Modules spécifiques, points de terminaison ou fonctionnalités impactés par le changement.

Exemple: Ajout de la prise en charge de cette nouvelle commande API <Enregistrement de domaine>

Historique des modifications

Suivez chaque modification apportée à l'API Dynadot.

9 octobre 2025

v2.0.0Nouvelles fonctionnalités et changements clés Environnement sandbox désormais en ligne L'environnement Sandbox est officiellement lancé et disponible pour des tests sécurisés et la validation d'intégration. En-tête X-Signature obligatoire pour les opérations sensibles Pour renforcer la sécurité, l'en-tête X-Signature est désormais obligatoire pour toutes les commandes API sensibles. (Facultatif) Documentation API lisible par machine Nous prenons désormais en charge une documentation API structurée et lisible par machine pour faciliter l'intégration avec des outils automatisés. Accès à la recherche restreint L'accès à certains endpoints liés à la recherche a été restreint pour des raisons de performance et de contrôle des données. Liste blanche IP optimisée Le compte revendeur n'a plus besoin de saisir au moins 1 IP pour utiliser l'API(API RESTful uniquement) Améliorations de la documentation API Sélecteur de version mis à jour sur la page d'accueil de la documentation pour une navigation plus facile Conventions de casse unifiées pour les noms de paramètres Documentation et conseils d'utilisation étendus pour l'endpoint bulk_search Ajout d'une fonctionnalité pour masquer/afficher la navigation latérale

Ajout de paramètres de pagination obligatoires pour améliorer l'efficacité et la cohérence des réponses. page (entier, requis) – Spécifie l'index de la page actuelle, à partir de 1. page_size (entier, obligatoire) – Définit le nombre d'éléments renvoyés par page.get_listings