RESTful API
Beta Notice: This API documentation is Beta. Endpoints, fields, error codes, and behaviors may change without notice and backward compatibility is not guaranteed. Avoid relying on it for critical production workflows.
Начало работы с нашим RESTful API
API Dynadot разработан для бесшовной интеграции с вашими системами. Наш API предлагает предсказуемые URL-адреса, ориентированные на ресурсы, поддерживает запросы с телами, закодированными в формате JSON, возвращает ответы в формате JSON и XML, а также соответствует стандартным методам HTTP, аутентификации и кодам ответов.Вы можете использовать API Dynadot как в тестовом, так и в рабочем режимах. Режим определяется по API-ключу, который используется для аутентификации ваших запросов. Тестовый режим позволяет вам симулировать и проверять вашу интеграцию API, не влияя на реальные данные или транзакции.API Dynadot в первую очередь ориентирован на управление доменами, обработку заказов и сопутствующие услуги. Вы можете выполнять такие действия, как регистрация, передача и продление доменов, управление настройками DNS, а также просмотр или обновление заказов в аккаунте.Обратите внимание: Массовое создание, обновление и удаление не поддерживаются, и каждый из этих типов запросов ограничен одним объектом или действием.
Генерация ваших API-ключейПрежде чем начать делать какие-либо запросы к API, необходимо сгенерировать ваш API Key и API Secret.Эти ключи необходимы для аутентификации и обеспечения безопасности ваших действий при взаимодействии с нашим API.Вы можете сгенерировать как API Key, так и API Secret в разделе API в настройках вашего аккаунта.1. Войдите в свой аккаунт на Dynadot.2. Перейдите в Инструменты > API.Сгенерируйте свой API Key и API Secret на этой странице.


Присоединяйтесь к нашему сообществуЕсть идеи или предложения? Поговорите напрямую с нашими профессиональными инженерами.Discord
HTTP МетодAPI использует стандартные методы HTTP для выполнения операций с ресурсами:
MethodDescription
GETGET Request: Retrieve detailed information about a specified resource
POSTPOST Request: Create a new resource
PUTPUT Request: Fully update the specified resource
DELETEDELETE Request: Remove the specified resource
URL
Базовый URL для всех API-запросов:https://api.dynadot.com/
Формат полного URL:http://api.dynadot.com/restful/version_code/resource/{resource_identify}/action
Example :
https://api.dynadot.com/restful/v2/domains/{domain_name}/search
Version
Текущая версия API составляетv1.0.0
При формировании URL-адреса API-запроса необходимо указывать только основную версию. Небольшие и патч-обновления разработаны с учетом обратной совместимости и не будут вносить изменения, которые могут нарушить работу вашего существующего кода. Это обеспечивает стабильность, позволяя вам получать преимущества от постепенных улучшений и исправлений без необходимости модификации вашей реализации.При выпуске будущих версий мы будем поддерживать обратную совместимость со старыми версиями в течение определенного времени. Новые функции и значительные изменения будут вводиться в рамках основных версий.
HeaderЗаголовок API-запроса содержит метаданные о запросе. Эти метаданные предоставляют важный контекст для правильной обработки запроса сервером. Обычно используемые заголовки включают:
Content-TypeУказывает формат данных, отправляемых в теле запроса. Сервер использует эту информацию для правильного разбора запроса. В настоящее время единственным допустимым значением является: application/json
Example :
Content-Type: application/json
ПринятьИнформирует сервер о формате ответа, ожидаемом клиентом.Возможные значения: application/json, application/xml
Example :
Accept: application/json
АвторизацияВсе запросы к API должны включать API-ключ для аутентификации. Вы можете получить свой API-ключ на панели управления вашего аккаунта.You can generate an API key in API setting page
Пример заголовка аутентификации:
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).
Example :
X-Request-ID: 550e8400-e29b-41d4-a716-446655440000
X-SignatureNewЗаголовок X-Signature является обязательным механизмом безопасности для транзакционных запросов, включая те, которые извлекают конфиденциальную информацию или обновляют данные. Он обеспечивает подлинность, целостность и невозможность отказа от API-запросов, требуя от клиентов подписывать полезную нагрузку запроса с использованием HMAC-SHA256.
Чтобы сгенерировать подпись, вам понадобятся следующие значенияAPI-ключ: Ваш уникальный API-ключ.2. Полный путь и запрос: Полный путь к конечной точке API вместе с параметрами запроса.3. X-Request-Id: Идентификатор запроса. Если он недоступен, вы можете ввести пустую строку.4. Тело запроса: Тело запроса. Если оно пустое или равно null, вы можете ввести пустую строку.
Строка для подписи представляет собой комбинацию указанных выше значений, соединённых в следующем порядке:
apiKey + "\n" + fullPathAndQuery + "\n" + (xRequestId or empty String) + "\n" + (requestBody or empty String)
Example
apiKey = "your_api_key"
fullPathAndQuery = "/v2/some/endpoint?param=value"
xRequestId = "unique-request-id"
requestBody = "{\"key\":\"value\"}"


stringToSign = "your_api_key\n/v2/some/endpoint?param=value\nunique-request-id\n{\"key\":\"value\"}"
Сгенерируйте подпись HMAC-SHA256После формирования строки для подписи вам необходимо применить HMAC-SHA256 шифрование с использованием вашего секретного ключа. Этот процесс создаст подпись.Подпись создается с использованием следующих шагов:1. Используйте алгоритм HMAC-SHA256. 2. Use the stringToSign as the input message.Используйте секрет в качестве ключа.
Примените сгенерированную подпись в качестве значения X-Signature в заголовке запроса.
Example :
X-Signature: {HMAC-SHA256 Signature}
BodyТело API-запроса используется для отправки данных на сервер. Обычно оно включается в запросы POST, PUT или PATCH (не обычно для запросов GET или DELETE).
Content FormatФормат данных тела определяется заголовком Content-Type. Некоторые распространенные форматы включают:
JSON
{
    "domainName": "domain.com",
    "showPrice": "yes",
    "currency": "USD"
}
Типичные случаи использованияPOST Запросы: Метод POST используется для создания нового ресурса на сервере. Тело запроса обычно содержит детали ресурса.PUT Запросы: Метод PUT используется для обновления существующего ресурса путем его полного замещения. Тело запроса содержит полностью обновленный ресурс.DELETE запросы: Метод DELETE используется для удаления существующего ресурса с сервера. У него нет тела запроса.GET Запросы: Метод GET используется для получения существующего ресурса с сервера. У него нет тела запроса
Response FormatВсе ответы API возвращаются в формате JSON или XML, при этом формат данных тела определяется заголовком Accept, предоставляя запрашиваемые данные или сообщение об ошибке, если это необходимо.
Content FormatThe response in general contains 3 parts: Code, Message, Data
Код: Статус запросаСообщение: Более подробное описание статусаДанные: Тело ответа
JSON/XML
{
    "Code": 200,
    "Message": "Success",
    "Data": {}
}
Обработка ошибокКоды состояния HTTP — это стандартизированные трехзначные числа, которые сервер возвращает, чтобы указать результат запроса клиента. Они предоставляют важную информацию о том, был ли запрос успешно обработан, требует ли он дальнейших действий или возникла ошибка. Эти коды делятся на пять категорий, каждая из которых представляет собой отдельный тип ответа.Коды состояния нашего API соответствуют протоколу HTTP/1.1, широко принятому стандарту, который обеспечивает последовательное и надежное взаимодействие. Используя HTTP/1.1, мы используем такие функции, как постоянные соединения и улучшенное кэширование, чтобы оптимизировать взаимодействие между клиентом и сервером.
2xx (Успешно): Указывает на то, что команда была получена и принята.
200Код состояния указывает на то, что запрос выполнен успешно.
201Код состояния указывает на то, что запрос был выполнен, и в результате было создано одно или несколько новых ресурсов.
202Код состояния указывает на то, что запрос принят для обработки, но обработка еще не завершена.
4xx (Ошибка клиента): Указывает на то, что клиент допустил ошибку в запросе, например, предоставив недопустимый ввод или не имея надлежащей авторизации.
400Код состояния указывает на то, что сервер не может или не будет обрабатывать запрос из-за того, что воспринимается как ошибка клиента.
401Код состояния указывает на то, что запрос не был выполнен, так как отсутствуют действительные учетные данные для аутентификации целевого ресурса.
402Код статуса указывает на то, что запрос не был выполнен из-за проблемы с оплатой.
403Код состояния указывает на то, что сервер понял запрос, но отказывается его выполнить.
404Код состояния указывает на то, что исходный сервер не нашел актуальное представление для целевого ресурса или не желает раскрывать, что такое представление существует.
409Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса.
429Пользователь отправил слишком много запросов за короткий промежуток времени.
5xx (Ошибка сервера): Указывает на то, что сервер столкнулся с ошибкой или не может выполнить запрос.
500Код состояния указывает на то, что сервер столкнулся с неожиданным условием, которое помешало ему выполнить запрос.
501Код состояния указывает на то, что сервер не поддерживает функциональность, необходимую для выполнения запроса.
502Код состояния указывает на то, что сервер, действуя в качестве шлюза или прокси, получил недействительный ответ от входящего сервера, к которому он обращался при попытке выполнить запрос.
503Код состояния указывает на то, что сервер в данный момент не может обработать запрос из-за временной перегрузки или запланированного обслуживания, которое, вероятно, будет устранено после некоторой задержки.
504Код состояния указывает на то, что сервер, действуя как шлюз или прокси, не получил своевременный ответ от вышестоящего сервера, к которому ему нужно было получить доступ для завершения запроса.
КодСтатус Название
200Успех
201Создано
202Принято
400Неверный запрос
401Неавторизованный
402Требуется оплата
403Запрещено
404Не найдено
409Конфликт
429Слишком много запросов
500Внутренняя ошибка сервера
501Не реализовано
502Плохой шлюз
503Сервис недоступен
504Таймаут шлюза
Обзор вебхуков
Вебхуки — это мощный инструмент для автоматизации процессов и интеграции систем. Они позволяют получать уведомления в реальном времени о событиях или изменениях в вашем аккаунте или настройках домена. Настроив вебхуки, вы можете запускать действия во внешних системах, обновлять базы данных или отправлять уведомления на основе конкретных событий.API Dynadot поддерживает вебхуки для различных событий, таких как регистрация домена, передача, продление и истечение срока действия. Вы можете настроить вебхуки для получения уведомлений об этих событиях и принятия соответствующих мер в ответ.Чтобы использовать вебхуки, вам нужно указать URL-эндпоинт, куда будут отправляться уведомления. Вы можете настроить вебхуки в настройках вашего аккаунта и указать события, о которых хотите получать уведомления. Когда происходит событие, сервер отправит POST-запрос на указанный URL с соответствующими данными.
Заголовок запроса вебхукаЗаголовок запроса Webhook содержит метаданные о запросе. Эти метаданные предоставляют важный контекст для сервера, чтобы правильно обработать запрос. Часто используемые заголовки включают:
Content-TypeУказывает формат данных, отправляемых в теле запроса. Сервер использует эту информацию для правильного разбора запроса. В настоящее время единственным допустимым значением является: application/json
Example :
Content-Type: application/json
АвторизацияВсе запросы вебхуков должны включать ключ вебхука для аутентификации. Вы можете получить свой ключ вебхука из панели управления вашего аккаунта.You can generate an WEBHOOK_KEY key in API setting page
Пример заголовка аутентификации:
Authorization: WEBHOOK_KEY
X-ПодписьЗаголовок X-Signature — это обязательный механизм безопасности для транзакционных запросов, включая те, которые извлекают конфиденциальную информацию или обновляют данные. Он обеспечивает подлинность, целостность и неотказуемость запросов вебхуков, требуя от клиентов подписывать полезную нагрузку запроса с помощью HMAC-SHA256.
Чтобы сгенерировать подпись, вам понадобятся следующие значения1. WEBHOOK Key: Ваш уникальный WEBHOOK ключ.2. Полный путь и запрос: Полный путь к эндпоинту WEBHOOK вместе с параметрами запроса.3. X-Request-Id: Идентификатор запроса. Если он недоступен, вы можете ввести пустую строку.4. Тело запроса: Тело запроса. Если оно пустое или равно null, вы можете ввести пустую строку.
Строка для подписи представляет собой комбинацию указанных выше значений, соединённых в следующем порядке:
webhookKey + "\n" + fullPathAndQuery + "\n" + (xRequestId or empty String) + "\n" + (requestBody or empty String)
Example
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После формирования строки для подписи вам необходимо применить HMAC-SHA256 шифрование с использованием вашего секретного ключа. Этот процесс создаст подпись.Подпись создается с использованием следующих шагов:1. Используйте алгоритм HMAC-SHA256. 2. Use the stringToSign as the input message.Используйте секрет в качестве ключа.
Примените сгенерированную подпись в качестве значения X-Signature в заголовке запроса.
Example :
X-Signature: {HMAC-SHA256 Signature}
Формат запроса вебхука
Content FormatТело запроса вебхука содержит информацию о событии, которое вызвало уведомление. Формат данных тела определяется заголовком Content-Type, который обычно имеет значение application/json.Тело запроса включает следующие параметры:Прыклад:
JSON/XML
{
  "Event": "domain_registration",
  "EventId": 12345,
  "Timestamp": "2022-01-01T12:00:00Z",
  "Data": {
    "DomainName": "example.com",
    "RegistrationDate": "2022-01-01",
    "ExpirationDate": "2023-01-01",
    "Registrant": {
      "Name": "JohnDoe",
      "Email": "[email protected]",
      "Phone": "+1.1234567890"
    }
  }
}
ПараметрыТело запроса содержит следующие параметры:
ParameterDescription
EventThe type of event that triggered the notification.
EventIdThe id of the event that triggered the notification.
TimestampThe timestamp when the event occurred.
DataThe data associated with the event.
Формат ответа вебхука
Content FormatОтвет на запрос вебхука будет отправлен в формате JSON, в зависимости от заголовка Content-Type, указанного в запросе.Тело ответа содержит информацию о статусе запроса, например, был ли он успешно обработан или возникла ошибка.The response in general contains 3 parts: Code, Message, DataПрыклад:
JSON/XML
{
    "EventId": 123,
    "Status": "200",
    "Message": "Success"
}
Ограничение скоростиЗапросы должны отправляться по https (защищенный сокет) для обеспечения безопасности. Только 1 запрос может обрабатываться одновременно, поэтому, пожалуйста, дождитесь завершения вашего текущего запроса, прежде чем отправлять другой.
Вы получите разные количества нитей в зависимости от уровня цен вашего аккаунта:
Price levelThread CountRate Limit
Regular1 thread60/min (1/sec)
Bulk5 threads600/min (10/sec)
Super Bulk25 threads6000/min (100/sec)
Примечание: place_auction_bid & get_auction_bid в настоящее время освобождены от указанного ограничения скорости.
Example :
<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."
  }
}
ПесочницаПесочница API Dynadot позволяет безопасно тестировать ваши интеграции API, не затрагивая ваш реальный аккаунт или средства.
Как получить доступ к песочнице
1. Войдите в свой аккаунт Dynadot и перейдите на страницу настроек API:2. https://www.dynadot.com/account/domain/setting/api.html3. Сгенерируйте ваш API Sandbox Key и API Sandbox Secret Key.4. После генерации, пожалуйста, дайте системе некоторое время для активации ваших тестовых ключей и создания вашего тестового аккаунта.5. Ваш тестовый аккаунт будет предварительно пополнен балансом в размере 10 000 во всех поддерживаемых валютах для целей тестирования.
Использование Sandbox APIAPI-команды в среде Sandbox функционально такие же, как в производственной среде.Единственное отличие — это базовый URL:
URL API для продакшена:https://api.dynadot.comURL API для песочницы:https://api-sandbox.dynadot.com
Важные примечания
Некоторые команды API могут быть недоступны в тестовой среде. Пожалуйста, обратитесь к документации по конкретной команде, чтобы проверить наличие метки "Support API Sandbox".Sandbox предназначен в первую очередь для тестирования. Некоторые команды могут отличаться от Production, и Sandbox не может полностью имитировать все возможные сложные сценарии, встречающиеся в производственной среде.
Обзор журнала изменений
Журнал изменений — это подробная запись изменений, улучшений, исправлений ошибок и новых функций, введенных в каждой версии API. Он обеспечивает прозрачность для пользователей и разработчиков, документируя влияние каждого обновления. Журнал состоит из двух ключевых частей:
Версия APIЭта часть подчеркивает систему версионирования API, которая помогает разработчикам отслеживать эволюцию функций и обеспечивать совместимость. Каждая версия API идентифицируется уникальным номером версии (например, v1.0.1, v2.2.3) и представляет собой значимую веху или релиз. Версионирование позволяет пользователям поддерживать интеграции с минимальными перебоями, выбирая обновления, когда они готовы.
История измененийИстория изменений предоставляет подробную информацию об обновлениях, исправлениях ошибок, устареваниях и улучшениях, введенных в каждой версии. Она описывает конкретные изменения, внесенные в конечные точки, параметры, механизмы аутентификации или форматы ответов. Этот раздел обеспечивает полную прозрачность для разработчиков относительно того, что изменилось, и позволяет им соответственно корректировать свои реализации. Поддерживая четкий и детализированный журнал изменений, мы стремимся предоставить разработчикам инструменты и информацию, необходимые для эффективного и уверенного управления интеграциями.
Версия API
Наше API в настоящее время находится на версииv1.0.0
Коды версий используются для систематической идентификации и управления обновлениями API. Они следуют формату семантического версионирования (SemVer):
<Major><Minor><Patch>
Каждый компонент кода версии выполняет определенную функцию и помогает разработчикам эффективно передавать объем и тип изменений.
Основная версияОпределение: Представляет собой значительные изменения, которые могут нарушить обратную совместимость.Format:<Major>.x.x
Примеры:v1.0.0->v2.0.0Полный редизайн API или несовместимые изменения схемы.
Небольшая версияОпределение: Указывает на добавление функций, совместимых с предыдущими версиями.Format:x.<Minor>.x
Примеры:v1.0.0->v1.1.0Добавление новых конечных точек или методов при сохранении обратной совместимости.
Версия патчаОпределение: Относится к обратнос совместимым исправлениям ошибок или незначительным улучшениям.Format:x.x.<Patch>
Примеры:v1.0.0->v1.1.0Исправление незначительной ошибки в конечной точке API.
Журнал изменений API
Журнал изменений — это подробная запись изменений, улучшений, исправлений ошибок и новых функций, введенных в каждой версии программного обеспечения или API. Он обеспечивает прозрачность для пользователей и разработчиков, документируя влияние каждого обновления.
Типичная запись в журнале изменений включает:Описание: Краткое объяснение того, что было изменено.Затронутые компоненты: Конкретные модули, конечные точки или функции, на которые повлиял данный изменения.
Пример: Добавлена поддержка этой новой команды API<Domain Register>
История измененийСледите за всеми изменениями в API 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.
Чат в Интернете