Domain API - List of API Commands

Dynadot API

Getting Started With Our RESTful API

The Dynadot API is designed for seamless integration with your systems. Our API features predictable resource-oriented URLs, supports JSON-encoded request bodies, returns JSON-encoded and XML-encoded responses, and adheres to standard HTTP methods, authentication, and response codes.You can use the Dynadot API in both test and live modes. The mode is determined by the API key used to authenticate your requests. Test mode allows you to simulate and validate your API integration without affecting live data or transactions.The Dynadot API is primarily focused on domain management, order processing, and related services. You can perform actions such as registering, transferring, and renewing domains, managing DNS settings, and viewing or updating account orders.Please note: The bulk creations, updates, deletes are not supported, and each of those request type is limited to one object or action.

Generating Your API KeysBefore you start making any API requests, it is essential to generate your API Key and API Secret.These keys are required for authentication and to ensure the security of your actions when interacting with our API.You can generate both the API Key and API Secret through the API section in your account settings. 1. Log in to your account at Dynadot. 2. Navigate to Tools > API. 3. Generate your API Key and API Secret from this page.

Join our CommunityHave any ideas or suggestions? Talk directly to our professional engineers.Discord

HTTP MethodThe API uses standard HTTP methods to perform operations on resources:

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

The base URL for all API requests is:https://api.dynadot.com/

The Full URL format: http://api.dynadot.com/restful/version_code/resource/{resource_identify}/action

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

Version

The current version of the API isv1.0.0

When constructing the API request URL, it is only necessary to include the major version. Minor and patch updates are designed to be backward-compatible and will not introduce changes that break your existing code. This ensures stability while allowing you to benefit from incremental improvements and fixes without needing to modify your implementation.When future versions are released, we will maintain backward compatibility for older versions for a period of time. New features and breaking changes will be introduced in major version increments.

HeaderThe header of an API request contains metadata about the request. This metadata provides essential context for the server to process the request properly. Commonly used headers include:

Content-TypeSpecifies the format of the data being sent in the request body. The server uses this information to parse the request correctly. Currently the only acceptable value is: application/json

Content-Type: application/json

AcceptInforms the server of the response format expected by the client.Possible values: application/json, application/xml

Accept: application/json

AuthorizationAll API requests must include an API key for authentication. You can get your API key from your account dashboard. You can generate an API key in API setting page

Authorization: Bearer YOUR_API_KEY

X-Request-IDThe X-Request-ID header is an optional header used to uniquely identify each API request. When included, this header helps track and correlate requests across systems and logs, making it easier to debug and monitor API activity.The value of the X-Request-ID must be a valid UUID (Universally Unique Identifier), following the standard format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (e.g., 123e4567-e89b-12d3-a456-426614174000).

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

X-SignatureThe X-Signature header is a mandatory security mechanism for transactional requests, including those that retrieve sensitive information or update data. It ensures the authenticity, integrity, and non-repudiation of API requests by requiring clients to sign the request payload using HMAC-SHA256.

To generate the signature, you'll need the following values 1. API Key: Your unique API key. 2. Full Path And Query: The full path of the API endpoint along with the query parameters. 3. X-Request-Id: The request ID. If it's not available, you can enter empty string. 4. Request Body: The body of the request. If it's empty or null, you can enter empty string.

The string to sign is a combination of the values mentioned above, concatenated in the following order:

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

Generate the HMAC-SHA256 SignatureAfter constructing the string to sign, you need to apply HMAC-SHA256 encryption using your secret key. This process will create the signature.The signature is generated using the following steps: 1. Use HMAC-SHA256 algorithm. 2. Use the stringToSign as the input message. 3. Use the secret as the key.
Apply the generated signature as the value of X-Signature in the request header

X-Signature: {HMAC-SHA256 Signature}

BodyThe body of an API request is used to send data to the server. It is commonly included in POST, PUT, or PATCH requests (not typically for GET or DELETE requests).

Content FormatThe format of the body data is determined by the Content-Type header. Some common formats include:

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

Typical Use CasesPOST Requests: The POST method is used to create a new resource on the server. The request body usually contains the resource details..PUT Requests: The PUT method is used to update an existing resource by replacing it entirely. The request body contains the complete updated resource.GET Requests: The DELETE method is used to remove an existing resource from the server. It does not have a request body.DELETE Requests: The GET method is used to retrieve an existing resource from the server. It does not have a request body

Response FormatAll API responses are returned in either JSON or XML format, which format of the body data is determined by the Accept header, providing the requested data or an error message, if applicable.

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

Code: The status of the requestMessage: More description of the statusData: The Body of the response

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

Error HandlingHTTP Status Codes are standardized three-digit numbers returned by a server to indicate the outcome of a clients request. They provide essential information about whether the request was successfully processed, requires further action, or encountered an error. These codes are divided into five categories, each representing a distinct type of response.Our API's status codes adhere to the HTTP/1.1 protocol, a widely accepted standard that ensures consistent and reliable communication. By using HTTP/1.1, we leverage features like persistent connections and enhanced caching to optimize client-server interactions.

2xx (Successful): Indicates that the command was received and accepted

200The status code indicates that the request has succeeded.

201The status code indicates that the request has been fulfilled and has resulted in one or more new resources being created.

202The status code indicates that the request has been accepted for processing, but the processing has not been completed.

249The user has sent too many requests in a given amount of time

4xx (Client Error): Signals that the client made an error in the request, such as providing invalid input or lacking proper authorization.

400The status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error.

401The status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource.

402The status code indicates that the request has not been applied due to a payment issue.

403The status code indicates that the server understood the request but refuses to fulfill it.

404The status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists.

409The request could not be completed due to a conflict with the current state of the resource.

5xx (Server Error): Indicates that the server encountered an error or is unable to fulfill the request.

500The status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.

501The status code indicates that the server does not support the functionality required to fulfill the request.

502The status code indicates that the server, while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request.

503The status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay.

504The status code indicates that the server, while acting as a gateway or proxy, did not receive a timely response from an upstream server it needed to access in order to complete the request.

CodeStatus Name

200Success

201Created

202Accepted

249Too many requests

400Bad Request

401Unauthorized

402Payment Required

403Forbidden

404Not Found

409Conflict

500Internal Server Error

501Not Implemented

502Bad Gateway

503Service Unavailable

504Gateway Timeout

Rate LimitingRequests should be sent over https (secure socket) for security. Only 1 request can be processed at a time, so please wait for your current request to finish before sending another request.

You will receive different thread counts based on the price level of your account:

Price level	Account
Regular	1 thread
Bulk	5 threads
Super Bulk	25 threads

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

Change Log Overview

A Change Log is a detailed record of changes, improvements, bug fixes, and new features introduced in each version of the API. It provides transparency for users and developers by documenting the impact of each update. It is composed of two key parts:

API VersionThis part highlights the versioning system of the API, which helps developers track the evolution of features and ensure compatibility. Each API version is identified by a unique version number (e.g., v1.0.1, v2.2.3) and represents a significant milestone or release. Versioning allows users to maintain integrations with minimal disruption by opting into updates when ready.

Change Log HistoryThe Change Log History provides detailed information about updates, bug fixes, deprecations, and enhancements introduced in each version. It outlines specific changes made to endpoints, parameters, authentication mechanisms, or response formats. This section ensures developers have full transparency about what has changed and can adjust their implementations accordingly. By maintaining a clear and detailed change log, we aim to provide developers with the tools and information needed to manage integrations effectively and confidently.

API Version

Our API is currently in versionv1.0.0

Version codes are used to systematically identify and manage API updates. They follow the Semantic Versioning (SemVer) format:

Each component of the version code serves a specific purpose and helps developers communicate the scope and type of changes effectively.

Major VersionDefinition: Represents significant changes that may break backward compatibility.Format: <Major>.x.x

Examples: v1.0.0->v2.0.0: A complete API redesign or incompatible schema changes.

Minor VersionDefinition: Indicates backward-compatible feature additions.Format: x.<Minor>.x

Examples: v1.0.0->v1.1.0: Adding new endpoints or methods while maintaining backward compatibility.

Patch VersionDefinition: Refers to backward-compatible bug fixes or minor improvements.Format: x.x.<Patch>

Examples: v1.0.0->v1.1.0: Fixing a minor bug in an API endpoint.

API Change Log

A Change Log is a detailed record of changes, improvements, bug fixes, and new features introduced in each version of software or an API. It provides transparency for users and developers by documenting the impact of each update.

A typical entry in a change log includes:Description: A brief explanation of what was changed.Affected Components: Specific modules, endpoints, or features impacted by the change.

Example: Added support for this new API command <Domain Register>

Change Log HistoryKeep track of every change to the Dynadot API.

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.