API de dominios - Lista de comandos de API

Primeros pasos con nuestra API RESTful

La API de Dynadot está diseñada para una integración perfecta con sus sistemas. Nuestra API ofrece URLs predecibles orientadas a recursos, admite cuerpos de solicitud codificados en JSON, devuelve respuestas codificadas en JSON y XML, y cumple con los métodos HTTP estándar, la autenticación y los códigos de respuesta.

Puedes usar la API de Dynadot tanto en modo de prueba como en modo en vivo. El modo se determina por la clave de API que se usa para autenticar tus solicitudes. El modo de prueba te permite simular y validar tu integración con la API sin afectar datos ni transacciones en vivo.

La API de Dynadot se centra principalmente en la gestión de dominios, el procesamiento de pedidos y servicios relacionados. Puedes realizar acciones como registrar, transferir y renovar dominios, gestionar la configuración de DNS y ver o actualizar los pedidos de la cuenta.

Por favor ten en cuenta: Las creaciones, actualizaciones y eliminaciones masivas no son compatibles, y cada uno de esos tipos de solicitud está limitado a un objeto o acción.

Generación de tus claves de API

Antes de empezar a hacer solicitudes a la API, es esencial que generes tu clave de API y tu secreto de API.

Estas claves son necesarias para la autenticación y para garantizar la seguridad de tus acciones al interactuar con nuestra API.

Puedes generar tanto la clave de API como el secreto de API a través de la sección API en la configuración de tu cuenta.

1. Inicia sesión en tu cuenta en Dynadot.

2. Navega a Herramientas > API.

3. Genera tu Clave API y tu Secreto de API desde esta página.

Únete a nuestra comunidad

¿Tienes ideas o sugerencias? Habla directamente con nuestros ingenieros profesionales.

Discord

Método HTTP

La API utiliza métodos HTTP estándar para realizar operaciones sobre recursos:

Método	Descripción
GET	Solicitud GET: Obtener información detallada sobre un recurso especificado
POST	Solicitud POST: Crear un nuevo recurso
PUT	Solicitud PUT: Actualiza completamente el recurso especificado
DELETE	Solicitud DELETE: Elimina el recurso especificado.

URL

La URL base para todas las solicitudes de API es:

https://api.dynadot.com/

El formato de la URL completa:

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

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

Versión

La versión actual de la API es v2.0.0

Al construir la URL de solicitud de la API, solo es necesario incluir la versión principal. Las actualizaciones menores y de parche están diseñadas para ser compatibles con versiones anteriores y no introducirán cambios que rompan tu código existente. Esto garantiza la estabilidad y, al mismo tiempo, te permite beneficiarte de mejoras y correcciones incrementales sin necesidad de modificar tu implementación.

Cuando se publiquen futuras versiones, mantendremos la compatibilidad hacia atrás para las versiones anteriores durante un periodo de tiempo. Las nuevas funciones y los cambios que rompen compatibilidad se introducirán en incrementos de versión mayor.

Encabezado

El encabezado de una solicitud de API contiene metadatos sobre la solicitud. Estos metadatos proporcionan el contexto esencial para que el servidor procese la solicitud correctamente. Los encabezados de uso común incluyen:

Tipo de contenido

Especifica el formato de los datos que se envían en el cuerpo de la solicitud. El servidor usa esta información para analizar la solicitud correctamente. Actualmente, el único valor aceptable es: application/json

Content-Type: application/json

Aceptar

Informa al servidor sobre el formato de respuesta que espera el cliente.

Valores posibles: application/json, application/xml

Accept: application/json

Autorización

Todas las solicitudes de API deben incluir una clave de API para la autenticación. Puedes obtener tu clave de API desde el panel de tu cuenta.

Puedes generar una clave de API en la página de configuración de la API

Authorization: Bearer YOUR_API_KEY

X-Request-ID

El encabezado X-Request-ID es un encabezado (Opcional) que se usa para identificar de forma única cada solicitud a la API. Cuando se incluye, este encabezado ayuda a rastrear y correlacionar solicitudes entre sistemas y registros, lo que facilita la depuración y el monitoreo de la actividad de la API.

El valor de X-Request-ID debe ser un UUID válido (Identificador único universal), siguiendo el formato estándar: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (p. ej., 123e4567-e89b-12d3-a456-426614174000).

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

X-Signature Nuevo

El encabezado X-Signature es un mecanismo de seguridad obligatorio para las solicitudes transaccionales, incluidas las que recuperan información sensible o actualizan datos. Garantiza la autenticidad, la integridad y el no repudio de las solicitudes a la API al exigir que los clientes firmen la carga útil de la solicitud usando HMAC-SHA256.

Para generar la firma, necesitarás los siguientes valores

1. Clave API: Tu clave única de API.

2. Ruta completa y consulta: La ruta completa del endpoint de la API junto con los parámetros de consulta.

3. X-Request-Id: El ID de la solicitud. Si no está disponible, puede ingresar una cadena vacía.

4. Cuerpo de la solicitud: El cuerpo de la solicitud. Si está vacío o es nulo, puedes ingresar una cadena vacía.

La cadena a firmar es una combinación de los valores mencionados anteriormente, concatenados en el siguiente orden:

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\"}"

Generar la firma HMAC-SHA256

Después de construir stringToSign, calcula la firma usando HMAC-SHA256 con tu secreto como clave, luego Codificar en Base64 el resultado.

La firma se genera siguiendo estos pasos:

1. Utilice el algoritmo HMAC-SHA256.

2. Usa stringToSign (UTF-8) como mensaje de entrada.

3. Usa tu secreto (UTF-8) como clave.

4. Codifica la salida del HMAC en Base64 (Base64 estándar)

Aplica el Firma generado como el valor de X-Signature en el encabezado de la solicitud

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)

Cuerpo

El cuerpo de una solicitud de API se utiliza para enviar datos al servidor. Por lo general, se incluye en solicitudes POST, PUT o PATCH (no suele usarse en solicitudes GET o DELETE).

Formato del contenido

El formato de los datos del cuerpo está determinado por el encabezado Content-Type. Algunos formatos comunes incluyen:

Casos de uso típicos

Solicitudes POST: El método POST se utiliza para crear un nuevo recurso en el servidor. El cuerpo de la solicitud normalmente contiene los detalles del recurso..

Solicitudes PUT: El método PUT se usa para actualizar un recurso existente reemplazándolo por completo. El cuerpo de la solicitud contiene el recurso actualizado completo.

Solicitudes DELETE: El método DELETE se utiliza para eliminar un recurso existente del servidor. No tiene un cuerpo de solicitud..

Solicitudes GET: El método GET se utiliza para recuperar un recurso existente del servidor. No tiene un cuerpo de solicitud.

Formato de respuesta

Todas las respuestas de la API se devuelven en formato JSON o XML; el formato de los datos del cuerpo lo determina el encabezado Accept, y proporcionan los datos solicitados o un mensaje de error, si corresponde.

Formato del contenido

La respuesta en general contiene 3 partes: Código, Mensaje, Datos

Código: El estado de la solicitud

Mensaje: Descripción adicional del estado

Datos: El cuerpo de la respuesta

Manejo de errores

Los códigos de estado HTTP son números estandarizados de tres dígitos que devuelve un servidor para indicar el resultado de la solicitud de un cliente. Proporcionan información esencial sobre si la solicitud se procesó correctamente, requiere más acciones o encontró un error. Estos códigos se dividen en cinco categorías, cada una representa un tipo distinto de respuesta.

Los códigos de estado de nuestra API siguen el protocolo HTTP/1.1, un estándar ampliamente aceptado que garantiza una comunicación consistente y fiable. Al usar HTTP/1.1, aprovechamos funciones como las conexiones persistentes y el almacenamiento en caché mejorado para optimizar las interacciones cliente-servidor.

Descripción general de Webhook

Los webhooks son una herramienta poderosa para automatizar procesos e integrar sistemas. Te permiten recibir notificaciones en tiempo real sobre eventos o cambios en tu cuenta o en la configuración de tus dominios. Al configurar webhooks, puedes desencadenar acciones en sistemas externos, actualizar bases de datos o enviar notificaciones basadas en eventos específicos.

La API de Dynadot admite notificaciones de webhook para varios eventos, como el registro, la transferencia, la renovación y la expiración de dominios, para que puedas tomar las medidas adecuadas en respuesta.

Para usar webhooks, necesitas proporcionar un endpoint de URL donde se enviarán las notificaciones. Puedes configurar la URL, la clave y el secreto de tu webhook en la configuración de tu cuenta. Cuando ocurre un evento, Dynadot enviará una solicitud POST a la URL especificada con los datos relevantes.

Encabezado de solicitud de Webhook

El encabezado de una solicitud de Webhook contiene metadatos sobre la solicitud. Estos metadatos proporcionan un contexto esencial para que el servidor procese la solicitud correctamente. Los encabezados comúnmente utilizados incluyen:

Tipo de contenido

Especifica el formato de los datos que se envían en el cuerpo de la solicitud. El servidor usa esta información para analizar la solicitud correctamente. Actualmente, el único valor aceptable es: application/json

Content-Type: application/json

Autorización

Todas las solicitudes de Webhook incluirán una clave de Webhook para autenticación. Puedes obtener tu clave de Webhook desde el panel de tu cuenta.

Puedes gestionar tu WEBHOOK_KEY en la página de configuración de la API

Authorization: Bearer WEBHOOK_KEY

X-Signature

El encabezado X-Signature es un mecanismo de seguridad obligatorio para las solicitudes transaccionales, incluidas las que recuperan información sensible o actualizan datos. Garantiza la autenticidad, la integridad y el no repudio de las solicitudes de Webhook al exigir que los clientes firmen la carga útil de la solicitud usando HMAC-SHA256.

Para generar la firma, necesitarás los siguientes valores

1. Clave de WEBHOOK: Tu clave única de WEBHOOK.

2. Ruta completa y consulta: La ruta completa del endpoint de WEBHOOK junto con los parámetros de consulta.

3. X-Request-Id: El ID de la solicitud. Si no está disponible, puede ingresar una cadena vacía.

4. Cuerpo de la solicitud: El cuerpo de la solicitud. Si está vacío o es nulo, puedes ingresar una cadena vacía.

La cadena a firmar es una combinación de los valores mencionados anteriormente, concatenados en el siguiente orden:

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\"}"

Generar la firma HMAC-SHA256

Después de construir stringToSign, calcula la firma usando HMAC-SHA256 con tu secreto como clave, luego Codificar en Base64 el resultado.

La firma se genera siguiendo estos pasos:

1. Utilice el algoritmo HMAC-SHA256.

2. Usa stringToSign (UTF-8) como mensaje de entrada.

3. Usa tu secreto (UTF-8) como clave.

4. Codifica la salida del HMAC en Base64 (Base64 estándar)

Aplica el Firma generado como el valor de X-Signature en el encabezado de la solicitud

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)

Formato de solicitud de webhook

Formato del contenido

El cuerpo de una solicitud de webhook contiene información sobre el evento que desencadenó la notificación. El formato de los datos del cuerpo está determinado por el encabezado Content-Type, que normalmente es application/json.

El cuerpo de la solicitud incluye los siguientes parámetros:

Ejemplo:

Parámetros

El cuerpo de la solicitud contiene los siguientes parámetros:

Parámetro	Descripción
Evento	El tipo de evento que activó la notificación.
ID de evento	El id del evento que desencadenó la notificación.
Marca de tiempo	La marca de tiempo en que ocurrió el evento.
datos	Los datos asociados con el evento.

Formato de respuesta del webhook

Formato del contenido

La respuesta a una solicitud de webhook se enviará en formato JSON, según el encabezado Content-Type especificado en la solicitud.

El cuerpo de la respuesta contiene información sobre el estado de la solicitud, como si se procesó correctamente o se encontró un error.

La respuesta en general contiene 1 parte: Estado

Ejemplo:

Limitación de tasa

Las solicitudes deben enviarse a través de https (socket seguro) por seguridad. Solo se puede procesar 1 solicitud a la vez, así que espera a que termine tu solicitud actual antes de enviar otra.

Recibirás diferentes cantidades de hilos según el nivel de precio de tu cuenta:

Nivel de precios	Número de hilos	Límite de velocidad
Regular	1 hilo	60/min (1/sec)
Bulk	5 hilos	600/min (10/sec)
Súper Masivo	35 hilos	6000/min (100/seg)

Nota: place_auction_bid & get_auction_bid actualmente están exentos del límite de velocidad anterior.

Para el comando de Tasación de Dominios, recibirás diferentes cantidades de solicitudes permitidas según el nivel de precio de tu cuenta:

Nivel de precios	Límite de velocidad
Regular	50/día
Bulk	100/día
Súper Masivo	300/día

Sandbox

El entorno Sandbox de la API de Dynadot te permite probar tus integraciones de API de forma segura sin afectar tu cuenta activa ni tus fondos reales.

Cómo acceder al entorno de pruebas

1. Inicia sesión en tu cuenta de Dynadot y ve a la página de configuración de la API:

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

3. Genere su Clave de API Sandbox y su Clave Secreta de API Sandbox.

4. Después de la generación, por favor permite un tiempo para que el sistema active tus claves de sandbox y cree tu cuenta de Sandbox.

5. Tu cuenta de Sandbox se prefinanciará con un saldo de 10,000 en todas las monedas compatibles para fines de prueba.

Uso de la API de Sandbox

Los comandos de la API en el entorno Sandbox son funcionalmente los mismos que en el entorno de producción.

La única diferencia es la URL base:

URL de la API de producción: https://api.dynadot.com

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

Notas importantes

Algunos comandos de la API pueden no estar disponibles en el entorno Sandbox. Consulta la documentación específica del comando para verificar la etiqueta "Sandbox de API de soporte".

El Sandbox está diseñado principalmente para pruebas. Ciertos comandos pueden diferir de Producción, y el no puede simular por completo todos los posibles escenarios complejos de Sandbox que se encuentra en el entorno de Producción.

Descripción general del registro de cambios

Un registro de cambios es un registro detallado de los cambios, mejoras, correcciones de errores y nuevas funciones introducidas en cada versión de la API. Proporciona transparencia a usuarios y desarrolladores al documentar el impacto de cada actualización. Se compone de dos partes clave:

Versión de la API

Esta parte destaca el sistema de versionado de la API, que ayuda a los desarrolladores a seguir la evolución de las funciones y garantizar la compatibilidad. Cada versión de la API se identifica con un número de versión único (p. ej., v1.0.1, v2.2.3) y representa un hito o lanzamiento importante. El versionado permite a los usuarios mantener las integraciones con mínimas interrupciones al optar por las actualizaciones cuando estén listos.

Historial de cambios

El historial de cambios proporciona información detallada sobre actualizaciones, correcciones de errores, depreciaciones y mejoras introducidas en cada versión. Describe cambios específicos realizados en endpoints, parámetros, mecanismos de autenticación o formatos de respuesta. Esta sección garantiza que los desarrolladores tengan total transparencia sobre lo que ha cambiado y puedan ajustar sus implementaciones en consecuencia. Al mantener un registro de cambios claro y detallado, nuestro objetivo es proporcionar a los desarrolladores las herramientas y la información necesarias para gestionar integraciones de manera efectiva y segura.

Versión de la API

Nuestra API está actualmente en la versión v2.0.0

Los códigos de versión se utilizan para identificar y gestionar sistemáticamente las actualizaciones de la API. Siguen el formato de Versionado Semántico (SemVer):

Cada componente del código de versión cumple un propósito específico y ayuda a los desarrolladores a comunicar el alcance y el tipo de cambios de manera efectiva.

Versión principal

Definición: representa cambios importantes que pueden romper la compatibilidad con versiones anteriores.

Formato:

x.<Minor>.x

Ejemplos: v1.0.0 -> v2.0.0: Un rediseño completo de la API o cambios de esquema incompatibles.

Versión menor

Definición: Indica adiciones de funciones compatibles con versiones anteriores.

Formato:

x.<Minor>.x

Ejemplos: v1.0.0 -> v1.1.0: Agregar nuevos endpoints o métodos manteniendo la compatibilidad con versiones anteriores.

Versión de parche

Definición: Se refiere a correcciones de errores compatibles con versiones anteriores o mejoras menores.

Formato:

x.x.<Patch>

Ejemplos: v1.0.0 -> v1.1.0: Corrección de un error menor en un endpoint de API.

Registro de cambios de la API

Un registro de cambios es un historial detallado de los cambios, mejoras, correcciones de errores y nuevas funciones introducidas en cada versión de un software o una API. Proporciona transparencia a los usuarios y desarrolladores al documentar el impacto de cada actualización.

Una entrada típica en un registro de cambios incluye:

Descripción: Una breve explicación de lo que se cambió.

Componentes afectados: Módulos, endpoints o características específicas afectadas por el cambio.

Ejemplo: Se añadió soporte para este nuevo comando de API <Registro de dominio>

Historial de cambios

Mantente al tanto de cada cambio en la API de Dynadot.

9 de octubre de 2025

v2.0.0Nuevas funciones & cambios clave El entorno Sandbox ya está disponible El entorno Sandbox se lanza oficialmente y está disponible para pruebas seguras y validación de integración. Encabezado X-Signature obligatorio para operaciones sensibles Para mejorar la seguridad, ahora se exige el encabezado X-Signature en todos los comandos sensibles de la API. (Opcional) Documentación de API legible por máquina Ahora admitimos documentación de API estructurada y legible por máquina para facilitar la integración con herramientas automatizadas. Acceso a la búsqueda restringido El acceso a ciertos endpoints relacionados con la búsqueda se ha restringido por motivos de rendimiento y control de datos. Lista blanca de IP optimizada La cuenta de revendedor ya no requiere ingresar al menos 1 IP para usar la API (solo API RESTful) Mejoras en la documentación de la API Selector de versión actualizado en la página de inicio de la documentación para facilitar la navegación Convenciones unificadas de mayúsculas y minúsculas en los nombres de parámetros Se amplió la documentación y la guía de uso para el endpoint bulk_search Se añadió la función para ocultar/mostrar la navegación lateral

Se introdujeron parámetros de paginación obligatorios para mejorar la eficiencia y la consistencia de las respuestas. page (entero, obligatorio) – Especifica el índice de la página actual, comenzando desde 1. page_size (entero, obligatorio) – Define la cantidad de elementos devueltos por página.get_listings