Domain API — Список команд API

Начало работы с нашим RESTful API

API Dynadot разработан для бесшовной интеграции с вашими системами. Наш API использует предсказуемые URL-адреса, ориентированные на ресурсы, поддерживает тела запросов в кодировке JSON, возвращает ответы в кодировке JSON и XML и соответствует стандартным методам HTTP, аутентификации и кодам ответа.

Вы можете использовать API Dynadot как в тестовом, так и в рабочем режиме. Режим определяется ключом API, который используется для аутентификации ваших запросов. Тестовый режим позволяет имитировать и проверять интеграцию с API, не влияя на реальные данные или транзакции.

API Dynadot в первую очередь ориентирован на управление доменами, обработку заказов и связанные с этим услуги. Вы можете выполнять такие действия, как регистрация, перенос и продление доменов, управление настройками DNS, а также просмотр или обновление заказов в аккаунте.

Обратите внимание: Массовые создание, обновление и удаление не поддерживаются, и каждый из этих типов запросов ограничен одним объектом или действием.

Генерация ваших API-ключей

Прежде чем начать выполнять любые API-запросы, необходимо сгенерировать ваш API-ключ и API-секрет.

Эти ключи необходимы для аутентификации и обеспечения безопасности ваших действий при взаимодействии с нашим API.

Вы можете сгенерировать и API Key, и API Secret в разделе API в настройках вашего аккаунта.

1. Войдите в свой аккаунт на Dynadot.

2. Перейдите в Инструменты > API.

3. Сгенерируйте свои Ключ API и Секрет API на этой странице.

Присоединяйтесь к нашему сообществу

Есть идеи или предложения? Поговорите напрямую с нашими профессиональными инженерами.

Discord

HTTP-метод

API использует стандартные HTTP-методы для выполнения операций над ресурсами:

Метод	Описание
GET	GET-запрос: получить подробную информацию об указанном ресурсе
POST	POST-запрос: создать новый ресурс
PUT	PUT-запрос: полное обновление указанного ресурса
DELETE	Запрос DELETE: Удалить указанный ресурс

URL

Базовый URL для всех API-запросов:

https://api.dynadot.com/

Формат полного URL:

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

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

Версия

Текущая версия API — v2.0.0

При построении URL запроса API достаточно указать только основную версию. Минорные и патч-обновления разработаны так, чтобы быть обратно совместимыми, и не будут вносить изменения, нарушающие работу вашего существующего кода. Это обеспечивает стабильность и позволяет получать преимущества от постепенных улучшений и исправлений без необходимости изменять вашу реализацию.

Когда будут выпущены будущие версии, мы будем поддерживать обратную совместимость со старыми версиями в течение некоторого времени. Новые возможности и ломающие изменения будут вводиться при инкременте мажорной версии.

Заголовок

Заголовок API-запроса содержит метаданные о запросе. Эти метаданные предоставляют серверу важный контекст для правильной обработки запроса. К часто используемым заголовкам относятся:

Content-Type

Указывает формат данных, отправляемых в теле запроса. Сервер использует эту информацию для корректного разбора запроса. В настоящее время единственное допустимое значение: application/json

Content-Type: application/json

Принять

Сообщает серверу о формате ответа, ожидаемом клиентом.

Возможные значения: application/json, application/xml

Accept: application/json

Авторизация

Все запросы к API должны содержать ключ API для аутентификации. Вы можете получить свой ключ API в панели управления учетной записи.

Вы можете сгенерировать API-ключ на странице настроек API.

Authorization: Bearer YOUR_API_KEY

X-Request-ID

Заголовок X-Request-ID — это (Необязательно) заголовок, используемый для уникальной идентификации каждого API-запроса. При включении этот заголовок помогает отслеживать и сопоставлять запросы между системами и логами, упрощая отладку и мониторинг активности API.

Значение X-Request-ID должно быть допустимым UUID (универсальный уникальный идентификатор), соответствующим стандартному формату: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (например, 123e4567-e89b-12d3-a456-426614174000).

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

X-Signature Новое

Заголовок X-Signature — это обязательный механизм безопасности для транзакционных запросов, включая те, которые получают конфиденциальную информацию или обновляют данные. Он обеспечивает подлинность, целостность и неотказуемость API-запросов, требуя от клиентов подписывать полезную нагрузку запроса с помощью HMAC-SHA256.

Чтобы сгенерировать подпись, вам понадобятся следующие значения

1. Ключ API: Ваш уникальный API-ключ.

2. Полный путь и строка запроса: Полный путь к конечной точке API вместе с параметрами запроса.

3. X-Request-Id: идентификатор запроса. Если он недоступен, можно ввести пустую строку.

4. Тело запроса: Тело запроса. Если оно пустое или null, можно ввести пустую строку.

Строка для подписи — это комбинация значений, упомянутых выше, объединённых в следующем порядке:

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

Создать подпись HMAC-SHA256

После построения stringToSign вычислите подпись с помощью HMAC-SHA256, используя ваш секрет в качестве ключа, затем Кодировать в Base64 результат.

Подпись создается с помощью следующих шагов:

1. Используйте алгоритм HMAC-SHA256.

2. Используйте stringToSign (UTF-8) в качестве входного сообщения.

3. Используйте ваш секрет (UTF-8) в качестве ключа.

4. Закодируйте вывод HMAC в Base64 (стандартный Base64)

Примените сгенерированный Подпись как значение X-Signature в заголовке запроса

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)

Тело

Тело API-запроса используется для отправки данных на сервер. Обычно оно включается в запросы POST, PUT или PATCH (обычно не в запросы GET или DELETE).

Формат содержимого

Формат данных тела определяется заголовком Content-Type. Некоторые распространенные форматы включают:

Типичные сценарии использования

POST-запросы: Метод POST используется для создания нового ресурса на сервере. Тело запроса обычно содержит сведения о ресурсе..

PUT-запросы: Метод PUT используется для обновления существующего ресурса путём его полной замены. Тело запроса содержит полный обновлённый ресурс.

Запросы DELETE: метод DELETE используется для удаления существующего ресурса с сервера. У него нет тела запроса.

GET-запросы: Метод GET используется для получения существующего ресурса с сервера. У него нет тела запроса

Формат ответа

Все ответы API возвращаются в формате JSON или XML; формат данных тела определяется заголовком Accept, предоставляя запрошенные данные или сообщение об ошибке, если применимо.

Формат содержимого

Ответ обычно содержит 3 части: Код, Сообщение, Данные

Код: статус запроса

Сообщение: Более подробное описание статуса

Данные: Тело ответа

Обработка ошибок

Коды состояния HTTP — это стандартизированные трёхзначные числа, возвращаемые сервером для обозначения результата запроса клиента. Они предоставляют важную информацию о том, был ли запрос успешно обработан, требует ли дальнейших действий или возникла ошибка. Эти коды делятся на пять категорий, каждая из которых представляет отдельный тип ответа.

Коды состояния нашего API соответствуют протоколу HTTP/1.1 — широко признанному стандарту, обеспечивающему согласованную и надёжную связь. Используя HTTP/1.1, мы задействуем такие возможности, как постоянные соединения и улучшенное кэширование, чтобы оптимизировать взаимодействие между клиентом и сервером.

Обзор вебхука

Вебхуки — мощный инструмент для автоматизации процессов и интеграции систем. Они позволяют получать уведомления в реальном времени о событиях или изменениях в вашей учётной записи или настройках домена. Настраивая вебхуки, вы можете запускать действия во внешних системах, обновлять базы данных или отправлять уведомления на основе определённых событий.

API Dynadot поддерживает webhook-уведомления для различных событий, таких как регистрация домена, трансфер, продление и истечение срока, чтобы вы могли предпринимать соответствующие действия в ответ.

Чтобы использовать вебхуки, вам нужно указать URL-эндпоинт, на который будут отправляться уведомления. Вы можете настроить URL вебхука, ключ и секрет в настройках своей учётной записи. Когда происходит событие, Dynadot отправит POST-запрос на указанный URL с соответствующими данными.

Заголовок запроса вебхука

Заголовок запроса вебхука содержит метаданные о запросе. Эти метаданные предоставляют серверу необходимый контекст для правильной обработки запроса. К часто используемым заголовкам относятся:

Content-Type

Указывает формат данных, отправляемых в теле запроса. Сервер использует эту информацию для корректного разбора запроса. В настоящее время единственное допустимое значение: application/json

Content-Type: application/json

Авторизация

Все запросы вебхуков будут содержать ключ вебхука для аутентификации. Вы можете получить свой ключ вебхука в панели управления аккаунтом.

Вы можете управлять своим WEBHOOK_KEY на странице настроек API.

Authorization: Bearer WEBHOOK_KEY

X-Signature

Заголовок X-Signature — это обязательный механизм безопасности для транзакционных запросов, в том числе тех, которые получают конфиденциальную информацию или обновляют данные. Он обеспечивает подлинность, целостность и неотказуемость запросов Webhook, требуя от клиентов подписывать тело запроса с помощью HMAC-SHA256.

Чтобы сгенерировать подпись, вам понадобятся следующие значения

1. Ключ вебхука: Ваш уникальный ключ WEBHOOK.

2. Полный путь и строка запроса: Полный путь к конечной точке WEBHOOK вместе с параметрами запроса.

3. X-Request-Id: идентификатор запроса. Если он недоступен, можно ввести пустую строку.

4. Тело запроса: Тело запроса. Если оно пустое или null, можно ввести пустую строку.

Строка для подписи — это комбинация значений, упомянутых выше, объединённых в следующем порядке:

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

Создать подпись HMAC-SHA256

После построения stringToSign вычислите подпись с помощью HMAC-SHA256, используя ваш секрет в качестве ключа, затем Кодировать в Base64 результат.

Подпись создается с помощью следующих шагов:

1. Используйте алгоритм HMAC-SHA256.

2. Используйте stringToSign (UTF-8) в качестве входного сообщения.

3. Используйте ваш секрет (UTF-8) в качестве ключа.

4. Закодируйте вывод HMAC в Base64 (стандартный Base64)

Примените сгенерированный Подпись как значение X-Signature в заголовке запроса

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)

Формат запроса вебхука

Формат содержимого

Тело запроса вебхука содержит информацию о событии, которое вызвало уведомление. Формат данных тела определяется заголовком Content-Type, который обычно имеет значение application/json.

Тело запроса включает следующие параметры:

Пример:

Параметры

Тело запроса содержит следующие параметры:

Параметр	Описание
Событие	Тип события, которое вызвало уведомление.
ID события	Идентификатор события, которое вызвало уведомление.
метка времени	Отметка времени, когда произошло событие.
данные	Данные, связанные с событием.

Формат ответа вебхука

Формат содержимого

Ответ на запрос вебхука будет отправлен в формате JSON в зависимости от заголовка Content-Type, указанного в запросе.

Тело ответа содержит информацию о статусе запроса, например, был ли он успешно обработан или возникла ошибка.

Ответ в целом содержит 1 часть: Статус

Пример:

Ограничение частоты запросов

Запросы следует отправлять через https (защищённый сокет) для безопасности. Одновременно может обрабатываться только 1 запрос, поэтому, пожалуйста, дождитесь завершения текущего запроса, прежде чем отправлять ещё один запрос.

В зависимости от ценового уровня вашего аккаунта вы будете получать разное количество потоков:

Уровень цен	Количество потоков	Лимит скорости
Обычный	1 поток	60/мин (1/сек)
Опт	5 потоков	600/мин (10/сек)
Супер оптом	35 потоков	6000/мин (100/сек)

Примечание: place_auction_bid и get_auction_bid в настоящее время не подпадают под указанное выше ограничение частоты запросов.

Для команды оценки домена вы будете получать разные разрешённые количества запросов в зависимости от ценового уровня вашего аккаунта:

Уровень цен	Лимит скорости
Обычный	50/день
Опт	100/день
Супер оптом	300/день

Песочница

Среда песочницы Dynadot API позволяет безопасно тестировать интеграции с API, не затрагивая ваш рабочий аккаунт или реальные средства.

Как получить доступ к песочнице

1. Войдите в свою учетную запись Dynadot и перейдите на страницу настроек API:

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

3. Сгенерируйте ваш ключ API Sandbox и секретный ключ API Sandbox.

4. После генерации, пожалуйста, подождите некоторое время, чтобы система активировала ваши ключи песочницы и создала вашу учётную запись Sandbox.

5. Ваша учётная запись Sandbox будет предварительно пополнена балансом 10,000 во всех поддерживаемых валютах для целей тестирования.

Использование API Sandbox

API-команды в среде песочницы функционально не отличаются от команд в рабочей среде.

Единственное отличие — базовый URL:

URL API для продакшена: https://api.dynadot.com

URL API песочницы: https://api-sandbox.dynadot.com

Важные примечания

Некоторые команды API могут быть недоступны в среде Sandbox. Пожалуйста, обратитесь к документации по конкретной команде, чтобы проверить наличие метки "Поддержка API Sandbox".

Песочница предназначена в первую очередь для тестирования. Некоторые команды могут отличаться от продакшена, и Песочница не может полностью имитировать все возможные сложные сценарии, доступные в среде продакшена.

Обзор журнала изменений

Журнал изменений — это подробная запись изменений, улучшений, исправлений ошибок и новых функций, представленных в каждой версии API. Он обеспечивает прозрачность для пользователей и разработчиков, документируя влияние каждого обновления. Он состоит из двух ключевых частей:

Версия API

Эта часть освещает систему версионирования API, которая помогает разработчикам отслеживать развитие функций и обеспечивать совместимость. Каждая версия API идентифицируется уникальным номером версии (например, v1.0.1, v2.2.3) и представляет собой значительную веху или выпуск. Версионирование позволяет пользователям поддерживать интеграции с минимальными нарушениями, подключаясь к обновлениям, когда они будут готовы.

История изменений

История изменений содержит подробную информацию об обновлениях, исправлениях ошибок, устаревших функциях и улучшениях, добавленных в каждой версии. В ней перечислены конкретные изменения, внесённые в эндпоинты, параметры, механизмы аутентификации или форматы ответов. Этот раздел обеспечивает разработчикам полную прозрачность относительно того, что изменилось, и позволяет им соответствующим образом адаптировать свои реализации. Поддерживая чёткий и подробный журнал изменений, мы стремимся предоставить разработчикам инструменты и информацию, необходимые для эффективного и уверенного управления интеграциями.

Версия API

Наш API сейчас находится в версии v2.0.0

Коды версий используются для систематической идентификации и управления обновлениями API. Они следуют формату семантического версионирования (SemVer):

Каждый компонент кода версии служит определённой цели и помогает разработчикам эффективно сообщать об объёме и типе изменений.

Основная версия

Определение: обозначает значительные изменения, которые могут нарушить обратную совместимость.

Формат:

x.<Minor>.x

Примеры: v1.0.0 -> v2.0.0: Полный редизайн API или несовместимые изменения схемы.

Минорная версия

Определение: указывает на добавление обратно совместимых функций.

Формат:

x.<Minor>.x

Примеры: v1.0.0 -> v1.1.0: Добавление новых эндпоинтов или методов с сохранением обратной совместимости.

Версия патча

Определение: относится к обратно совместимым исправлениям ошибок или незначительным улучшениям.

Формат:

x.x.<Patch>

Примеры: v1.0.0 -> v1.1.0: Исправление незначительной ошибки в эндпоинте API.

Журнал изменений API

Журнал изменений — это подробная запись изменений, улучшений, исправлений ошибок и новых функций, представленных в каждой версии программного обеспечения или API. Он обеспечивает прозрачность для пользователей и разработчиков, документируя влияние каждого обновления.

Типичная запись в журнале изменений включает:

Описание: Краткое объяснение того, что было изменено.

Затронутые компоненты: конкретные модули, эндпоинты или функции, затронутые изменением.

Пример: Добавлена поддержка этой новой команды API <Регистрация домена>

История изменений

Следите за каждым изменением в API Dynadot.

9 октября 2025

v2.0.0Новые функции и ключевые изменения Тестовая среда теперь доступна Среда Sandbox официально запущена и доступна для безопасного тестирования и проверки интеграции. Обязательный заголовок X-Signature для чувствительных операций Для повышения безопасности заголовок X-Signature теперь обязателен для всех чувствительных команд API. (Необязательно) Машиночитаемая документация API Теперь мы поддерживаем структурированную, машиночитаемую документацию API для более лёгкой интеграции с автоматизированными инструментами. Доступ к поиску ограничен Доступ к некоторым эндпоинтам, связанным с поиском, был ограничен по соображениям производительности и контроля данных. Оптимизировано внесение IP в белый список Для аккаунта реселлера больше не требуется вводить как минимум 1 IP, чтобы использовать API(только RESTful API) Улучшения документации API Обновлён селектор версий на главной странице документации для более удобной навигации Единые правила регистра для имён параметров Расширена документация и руководство по использованию конечной точки bulk_search Добавлена возможность скрывать/показывать боковую навигацию

Введены обязательные параметры постраничной навигации для повышения эффективности и согласованности ответов. page (целое число, обязательно) – Указывает индекс текущей страницы, начиная с 1. page_size (целое число, обязательно) – Определяет количество элементов, возвращаемых на страницу.get_listings