API de Dominio - Lista de Comandos de API

API de Dynadot

Comenzando con nuestra API RESTful

La API de Dynadot está diseñada para una integración fluida con tus sistemas. Nuestra API cuenta con URLs orientadas a recursos predecibles, soporta cuerpos de solicitud codificados en JSON, devuelve respuestas codificadas en JSON y XML, y se adhiere a los métodos HTTP estándar, autenticación y códigos de respuesta.Puedes utilizar la API de Dynadot tanto en modo de prueba como en modo en vivo. El modo se determina por la clave de API utilizada para autenticar tus solicitudes. El modo de prueba te permite simular y validar tu integración de API sin afectar los datos o 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 configuraciones de DNS y ver o actualizar los pedidos de tu cuenta.Por favor, tenga en cuenta: Las creaciones, actualizaciones y eliminaciones en masa no son compatibles, y cada uno de esos tipos de solicitud está limitado a un objeto o acción.

Generando sus claves APIAntes de comenzar a realizar cualquier solicitud a la API, es esencial generar tu Clave API y tu Secreto 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 API como el Secreto 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 Secreto API desde esta página.

Únete a nuestra comunidad¿Tienes alguna idea o sugerencia? Habla directamente con nuestros ingenieros profesionales.Discord

Método HTTPLa API utiliza métodos HTTP estándar para realizar operaciones en los recursos:

Method	Description
GET	GET Request: Retrieve detailed information about a specified resource
POST	POST Request: Create a new resource
PUT	PUT Request: Fully update the specified resource
DELETE	DELETE Request: Remove the specified resource

URL

La URL base para todas las solicitudes de API es:https://api.dynadot.com/

El formato de URL completa:http://api.dynadot.com/restful/version_code/resource/{resource_identify}/action

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

Version

La versión actual de la API esv2.0.0

Al construir la URL de solicitud de la API, solo es necesario incluir la versión principal. Las actualizaciones menores y de parches están diseñadas para ser compatibles hacia atrás y no introducirán cambios que rompan tu código existente. Esto garantiza estabilidad mientras te permite beneficiarte de mejoras y correcciones incrementales sin necesidad de modificar tu implementación.Cuando se lancen versiones futuras, mantendremos la compatibilidad hacia atrás con versiones anteriores durante un período de tiempo. Se introducirán nuevas características y cambios importantes en incrementos de versiones mayores.

HeaderEl encabezado de una solicitud API 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:

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

Content-Type: application/json

AceptarInforma al servidor sobre el formato de respuesta que espera el cliente.Valores posibles: application/json, application/xml

Accept: application/json

AutorizaciónTodas las solicitudes de API deben incluir una clave de API para la autenticación. Puedes obtener tu clave de API desde el panel de control de tu cuenta.You can generate an API key in API setting page

Authorization: Bearer YOUR_API_KEY

X-Request-IDEl encabezado X-Request-ID es un encabezado opcional utilizado para identificar de manera única cada solicitud de API. Cuando se incluye, este encabezado ayuda a rastrear y correlacionar solicitudes a través de sistemas y registros, facilitando la depuración y el monitoreo de la actividad de la API.El valor de X-Request-ID debe ser un UUID (Identificador Único Universal) válido, siguiendo el formato estándar: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (por ejemplo, 123e4567-e89b-12d3-a456-426614174000).

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

Sure! Here’s the translation of "X-Signature" into Spanish: X-FirmaEl encabezado X-Signature es un mecanismo de seguridad obligatorio para solicitudes transaccionales, incluidas aquellas que recuperan información sensible o actualizan datos. Asegura la autenticidad, integridad y no repudio de las solicitudes de API al requerir que los clientes firmen la carga útil de la solicitud utilizando HMAC-SHA256.

Para generar la firma, necesitarás los siguientes valoresClave API: Tu clave API única.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, puedes 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 = "/v1/some/endpoint?param=value"
xRequestId = "unique-request-id"
requestBody = "{\"key\":\"value\"}"


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

Generar la firma HMAC-SHA256Después de construir la cadena para firmar, necesitas aplicar HMAC-SHA256 encriptación utilizando tu clave secreta. Este proceso generará la firma.La firma se genera utilizando los siguientes pasos:1. Utiliza el algoritmo HMAC-SHA256. 2. Use the stringToSign as the input message.3. Usa el secreto como la clave.
Aplica la firma generada como el valor de X-Signature en el encabezado de la solicitud.

X-Signature: {HMAC-SHA256 Signature}

BodyEl cuerpo de una solicitud API se utiliza para enviar datos al servidor. Comúnmente se incluye en solicitudes POST, PUT o PATCH (no suele utilizarse en solicitudes GET o DELETE).

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

{
    "domainName": "domain.com",
    "showPrice": "yes",
    "currency": "USD"
}

Casos de Uso TípicosSolicitudes POST: El método POST se utiliza para crear un nuevo recurso en el servidor. El cuerpo de la solicitud generalmente contiene los detalles del recurso.Solicitudes PUT: El método PUT se utiliza para actualizar un recurso existente reemplazándolo por completo. El cuerpo de la solicitud contiene el recurso actualizado en su totalidad.DELETE Requests: El método DELETE se utiliza para eliminar un recurso existente del servidor. No tiene un cuerpo de solicitud.GET Requests: El método GET se utiliza para recuperar un recurso existente del servidor. No tiene un cuerpo de solicitud

Response FormatTodas las respuestas de la API se devuelven en formato JSON o XML, y el formato de los datos del cuerpo se determina por el encabezado Accept, proporcionando los datos solicitados o un mensaje de error, si corresponde.

Content FormatThe response in general contains 3 parts: Code, Message, Data

Código: El estado de la solicitudMensaje: Más descripción del estadoDatos: El cuerpo de la respuesta

{
    "Code": "200",
    "Message": "Success",
    "Data": {}
}

Manejo de ErroresLos 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, si requiere una acción adicional o si se encontró un error. Estos códigos se dividen en cinco categorías, cada una representando un tipo distinto de respuesta.Los códigos de estado de nuestra API se adhieren al protocolo HTTP/1.1, un estándar ampliamente aceptado que garantiza una comunicación consistente y confiable. Al utilizar HTTP/1.1, aprovechamos características como conexiones persistentes y un mejor almacenamiento en caché para optimizar las interacciones entre el cliente y el servidor.

2xx (Exitoso): Indica que el comando fue recibido y aceptado.

200El código de estado indica que la solicitud ha tenido éxito.

201El código de estado indica que la solicitud ha sido cumplida y ha resultado en la creación de uno o más nuevos recursos.

202El código de estado indica que la solicitud ha sido aceptada para su procesamiento, pero el procesamiento no se ha completado.

249El usuario ha enviado demasiadas solicitudes en un período de tiempo determinado.

4xx (Error del Cliente): Indica que el cliente cometió un error en la solicitud, como proporcionar una entrada no válida o carecer de la autorización adecuada.

400El código de estado indica que el servidor no puede o no procesará la solicitud debido a algo que se percibe como un error del cliente.

401El código de estado indica que la solicitud no se ha aplicado porque carece de credenciales de autenticación válidas para el recurso objetivo.

402El código de estado indica que la solicitud no se ha aplicado debido a un problema de pago.

403El código de estado indica que el servidor entendió la solicitud pero se niega a cumplirla.

404El código de estado indica que el servidor de origen no encontró una representación actual para el recurso objetivo o no está dispuesto a revelar que existe una.

409La solicitud no se pudo completar debido a un conflicto con el estado actual del recurso.

5xx (Error del Servidor): Indica que el servidor encontró un error o no puede cumplir con la solicitud.

500El código de estado indica que el servidor encontró una condición inesperada que le impidió cumplir con la solicitud.

501El código de estado indica que el servidor no soporta la funcionalidad necesaria para cumplir con la solicitud.

502El código de estado indica que el servidor, al actuar como un gateway o proxy, recibió una respuesta inválida de un servidor de entrada al que accedió mientras intentaba cumplir con la solicitud.

503El código de estado indica que el servidor no puede manejar la solicitud en este momento debido a una sobrecarga temporal o mantenimiento programado, lo que probablemente se resolverá después de un breve retraso.

504El código de estado indica que el servidor, al actuar como un gateway o proxy, no recibió una respuesta oportuna de un servidor ascendente al que necesitaba acceder para completar la solicitud.

de dominio.Nombre del Estado

200Éxito

201Creado

202Aceptado

249Demasiadas solicitudes

400Solicitud incorrecta

401No autorizado

402Pago Requerido

403Prohibido

404No encontrado

409Conflicto

500Error Interno del Servidor

501No implementado

502Puerta de enlace incorrecta

503Servicio no disponible

504Tiempo de espera de la puerta de enlace

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

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

Price level	Thread Count	Rate Limit
Regular	1 thread	60/min (1/sec)
Bulk	5 threads	600/min (10/sec)
Super Bulk	25 threads	6000/min (100/sec)

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

<Response>
  <status>
    <code>429</code>
    <message>Too Many Requests</message>
  </status>
  <error>
    <description>You have reached the maximum allowed requests within the concurrent limit of your account. Please try again later.</description>
  </error>
</Response>

{
  "code": 429,
  "message": "Too Many Requests",
  "error": {
    "description": "You have reached the maximum allowed requests within the concurrent limit of your account. Please try again later."
  }
}

Resumen del Registro de Cambios

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

Versión de la APIEsta parte destaca el sistema de versionado de la API, que ayuda a los desarrolladores a seguir la evolución de las características y garantizar la compatibilidad. Cada versión de la API se identifica con un número de versión único (por ejemplo, v1.0.1, v2.2.3) y representa un hito o lanzamiento significativo. El versionado permite a los usuarios mantener integraciones con una interrupción mínima al optar por actualizaciones cuando estén listos.

Historial de CambiosEl Historial de Cambios proporciona información detallada sobre actualizaciones, correcciones de errores, descontinuaciones y mejoras introducidas en cada versión. Describe los cambios específicos realizados en los puntos finales, 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 con confianza.

Versión de la API

Nuestra API está actualmente en la versiónv2.0.0

Los códigos de versión se utilizan para identificar y gestionar de manera sistemática 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 de manera efectiva el alcance y tipo de cambios.

Versión PrincipalDefinición: Representa cambios significativos que pueden romper la compatibilidad hacia atrás.Format:<Major>.x.x

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

Versión menorDefinición: Indica adiciones de características compatibles hacia atrás.Format:x.<Minor>.x

Ejemplos:v1.0.0->v1.1.0Agregar nuevos puntos finales o métodos mientras se mantiene la compatibilidad hacia atrás.

Versión del parcheDefinición: Se refiere a correcciones de errores compatibles hacia atrás o mejoras menores.Format:x.x.<Patch>

Ejemplos:v1.0.0->v1.1.0Corrigiendo un error menor en un punto final de la API.

Registro de Cambios de la API

Un registro de cambios es un documento detallado de las modificaciones, mejoras, correcciones de errores y nuevas funciones introducidas en cada versión de un software o una API. Proporciona transparencia para 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 específicos, puntos finales o características afectadas por el cambio.

Ejemplo: Se agregó soporte para este nuevo comando de API<Domain Register>

Historial de CambiosMantente al tanto de cada cambio en la API de Dynadot.

March 15, 2025

v1.0.0The Dynadot API 1.0.0 introduces a RESTful interface designed for seamless integration with your systems.

It features predictable resource-oriented URLs, supports standard HTTP methods and authentication, and returns responses in both JSON and XML formats.

Each request processes a single object or action, as bulk updates are not supported.

This version focuses on core domain management, order processing, and related services.
Users can register, transfer, and renew domains, manage DNS settings, view or update account orders, as well as access functionalities for aftermarket, site builder, email hosting, and more.

To facilitate collaboration and support, we provide a dedicated Discord channel where users can discuss API usage, share feedback, and receive updates.

October 9, 2025

v2.0.0New Features & Key Changes " Sandbox Environment Now Live � The Sandbox environment is officially launched and available for safe testing and integration validation. " Mandatory X-Signature Header for Sensitive Operations � To enhance security, the X-Signature header is now enforced for all sensitive API commands. " (Optional) Machine-Readable API Documentation � We now support structured, machine-readable API documentation for easier integration with automated tools. " Search Access Restricted � Access to certain search-related endpoints has been restricted for performance and data control reasons. " IP whitelisting optimized � Reseller account no longer required to enter at least 1 IP to use API(RESTful API only) API Documentation Improvements " Updated version selector on the documentation landing page for easier navigation " Unified casing conventions across parameter names " Expanded documentation and usage guidance for the bulk_search endpoint " Added feature to hide/show side navigation

Introduced mandatory paging parameters to improve response efficiency and consistency. � page (integer, required) Specifies the current page index, starting from 1. � page_size (integer, required) Defines the number of items returned per page.get_listings

March 15, 2025
October 9, 2025

Ver carrito