Domain API - List of API Commands

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 Keys

Before 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 Community

Have any ideas or suggestions? Talk directly to our professional engineers.

Discord

HTTP Method

The 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/v2/domains/{domain_name}/search

Version

The current version of the API is v2.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.

Header

The 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-Type

Specifies 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

Accept

Informs the server of the response format expected by the client.

Possible values: application/json, application/xml

Accept: application/json

Authorization

All 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-ID

The 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-Signature New

The 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 = "/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\"}"

Generate the HMAC-SHA256 Signature

After constructing stringToSign, compute the signature using HMAC-SHA256 with your secret as the key, then Base64-encode the result.

The signature is generated using the following steps:

1. Use HMAC-SHA256 algorithm.

2. Use stringToSign (UTF-8) as the input message.

3. Use your secret (UTF-8) as the key.

4. Encode the HMAC output in Base64 (standard Base64)

Apply the generated signature as the value of X-Signature in the request header

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)

Body

The 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 Format

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

Typical Use Cases

POST 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.

DELETE Requests: The DELETE method is used to remove an existing resource from the server. It does not have a request body.

GET Requests: The GET method is used to retrieve an existing resource from the server. It does not have a request body

Response Format

All 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 Format

The response in general contains 3 parts: Code, Message, Data

Code: The status of the request

Message: More description of the status

Data: The Body of the response

Error Handling

HTTP Status Codes are standardized three-digit numbers returned by a server to indicate the outcome of a client’s 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.

Webhook Overview

Webhooks are a powerful tool for automating processes and integrating systems. They allow you to receive real-time notifications about events or changes in your account or domain settings. By configuring webhooks, you can trigger actions in external systems, update databases, or send notifications based on specific events.

The Dynadot API supports webhook notifications for various events, such as domain registration, transfer, renewal, and expiration, so you can take appropriate actions in response.

To use webhooks, you need to provide a URL endpoint where the notifications will be sent. You can configure your webhook URL, key, and secret in your account settings. When an event occurs, Dynadot will send a POST request to the specified URL with the relevant data.

Webhook Request Header

The header of a Webhook request contains metadata about the request. This metadata provides essential context for the server to process the request properly. Commonly used headers include:

Content-Type

Specifies 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

Authorization

All Webhook requests will include an Webhook key for authentication. You can get your Webhook key from your account dashboard.

You can manage your WEBHOOK_KEY in the API settings page

Authorization: Bearer WEBHOOK_KEY

X-Signature

The 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 Webhook requests by requiring clients to sign the request payload using HMAC-SHA256.

To generate the signature, you'll need the following values

1. WEBHOOK Key: Your unique WEBHOOK key.

2. Full Path And Query: The full path of the WEBHOOK 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:

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

Generate the HMAC-SHA256 Signature

After constructing stringToSign, compute the signature using HMAC-SHA256 with your secret as the key, then Base64-encode the result.

The signature is generated using the following steps:

1. Use HMAC-SHA256 algorithm.

2. Use stringToSign (UTF-8) as the input message.

3. Use your secret (UTF-8) as the key.

4. Encode the HMAC output in Base64 (standard Base64)

Apply the generated signature as the value of X-Signature in the request header

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)

Webhook Request Format

Content Format

The body of a webhook request contains information about the event that triggered the notification. The format of the body data is determined by the Content-Type header, which is typically application/json.

The body of the request includes the following parameters:

Example:

Parameters

The body of the request contains the following parameters:

Parameter	Description
event	The type of event that triggered the notification.
event_id	The id of the event that triggered the notification.
timestamp	The timestamp when the event occurred.
data	The data associated with the event.

Webhook Response Format

Content Format

The response to a webhook request will be sent in JSON format, depending on the Content-Type header specified in the request.

The response body contains information about the status of the request, such as whether it was processed successfully or encountered an error.

The response in general contains 1 part: Status

Example:

Rate Limiting

Requests 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	Thread Count	Rate Limit
Regular	1 thread	60/min (1/sec)
Bulk	5 threads	600/min (10/sec)
Super Bulk	35 threads	6000/min (100/sec)

Note: place_auction_bid & get_auction_bid are currently exempt from the above rate limit.

For Domain Appraisal Command, you will receive different allowed request counts based on the price level of your account:

Price level	Rate Limit
Regular	50/day
Bulk	100/day
Super Bulk	300/day

Sandbox

The Dynadot API Sandbox environment allows you to safely test your API integrations without affecting your live account or real funds.

How to Access the Sandbox

1. Log in to your Dynadot account and navigate to the API settings page:

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

3. Generate your API Sandbox Key and API Sandbox Secret Key.

4. After generation, please allow some time for the system to activate your sandbox keys and create your Sandbox account.

5. Your Sandbox account will be pre-funded with a balance of 10,000 in all supported currencies for testing purposes.

Using the Sandbox API

The API commands in the Sandbox environment are functionally the same as the production environment.

The only difference is the base URL:

Production API URL: https://api.dynadot.com

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

Important Notes

Some API commands may be unavailable in the Sandbox environment. Please refer to the specific command documentation to check for the "Support API Sandbox" label.

The Sandbox is designed primarily for testing. Certain commands may differ from Production, and the Sandbox cannot fully simulate all possible complex scenarios found in the Production environment.

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 Version

This 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 History

The 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 version v2.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 Version

Definition: Represents significant changes that may break backward compatibility.

Format:

x.<Minor>.x

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

Minor Version

Definition: 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 Version

Definition: 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 History

Keep track of every change to the Dynadot API.

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