API de domínios - Lista de comandos da API

Primeiros passos com nossa API RESTful

A API da Dynadot foi projetada para integração perfeita com seus sistemas. Nossa API apresenta URLs previsíveis orientadas a recursos, oferece suporte a corpos de solicitação codificados em JSON, retorna respostas codificadas em JSON e XML e segue métodos HTTP, autenticação e códigos de resposta padrão.

Você pode usar a API da Dynadot nos modos de teste e produção. O modo é determinado pela chave de API usada para autenticar suas solicitações. O modo de teste permite simular e validar sua integração com a API sem afetar dados ou transações em produção.

A API da Dynadot concentra-se principalmente no gerenciamento de domínios, processamento de pedidos e serviços relacionados. Você pode realizar ações como registrar, transferir e renovar domínios, gerenciar configurações de DNS e visualizar ou atualizar pedidos da conta.

Por favor, note: As criações, atualizações e exclusões em massa não são suportadas, e cada um desses tipos de requisição é limitado a um objeto ou ação.

Gerando suas chaves de API

Antes de começar a fazer quaisquer solicitações de API, é essencial gerar sua API Key e API Secret.

Essas chaves são necessárias para autenticação e para garantir a segurança das suas ações ao interagir com nossa API.

Você pode gerar tanto a Chave de API quanto o Segredo de API através da seção API nas configurações da sua conta.

1. Faça login na sua conta na Dynadot.

2. Navegue até Ferramentas > API.

3. Gere seu Chave de API e Segredo da API nesta página.

Junte-se à nossa comunidade

Tem alguma ideia ou sugestão? Fale diretamente com nossos engenheiros profissionais.

Discord

Método HTTP

A API usa métodos HTTP padrão para realizar operações em recursos:

Método	Descrição
GET	Requisição GET: Obter informações detalhadas sobre um recurso especificado
POST	Requisição POST: Criar um novo recurso
PUT	Requisição PUT: Atualizar totalmente o recurso especificado
DELETE	Requisição DELETE: Remove o recurso especificado

URL

A URL base para todas as solicitações de API é:

https://api.dynadot.com/

O formato completo da URL:

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

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

Versão

A versão atual da API é v2.0.0

Ao construir a URL de solicitação da API, é necessário incluir apenas a versão principal. Atualizações menores e de patch são projetadas para serem compatíveis com versões anteriores e não introduzirão mudanças que quebrem seu código existente. Isso garante estabilidade enquanto permite que você se beneficie de melhorias incrementais e correções sem precisar modificar sua implementação.

Quando versões futuras forem lançadas, manteremos a compatibilidade retroativa para versões mais antigas por um período de tempo. Novos recursos e alterações que quebram compatibilidade serão introduzidos em incrementos de versão principal.

Cabeçalho

O cabeçalho de uma solicitação de API contém metadados sobre a solicitação. Esses metadados fornecem contexto essencial para que o servidor processe a solicitação corretamente. Cabeçalhos comumente usados incluem:

Content-Type

Especifica o formato dos dados sendo enviados no corpo da requisição. O servidor usa esta informação para analisar a requisição corretamente. Atualmente o único valor aceitável é: application/json

Content-Type: application/json

Aceitar

Informa ao servidor o formato de resposta esperado pelo cliente.

Valores possíveis: application/json, application/xml

Accept: application/json

Autorização

Todas as solicitações de API devem incluir uma chave de API para autenticação. Você pode obter sua chave de API no painel da sua conta.

Você pode gerar uma chave de API na página de configuração da API

Authorization: Bearer YOUR_API_KEY

X-Request-ID

O cabeçalho X-Request-ID é um cabeçalho (Opcional) usado para identificar de forma exclusiva cada requisição de API. Quando incluído, esse cabeçalho ajuda a rastrear e correlacionar requisições entre sistemas e logs, facilitando a depuração e o monitoramento da atividade da API.

O valor do X-Request-ID deve ser um UUID válido (Identificador Único Universal), seguindo o formato padrão: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (por exemplo, 123e4567-e89b-12d3-a456-426614174000).

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

X-Signature Novo

O cabeçalho X-Signature é um mecanismo de segurança obrigatório para solicitações transacionais, incluindo aquelas que recuperam informações confidenciais ou atualizam dados. Ele garante a autenticidade, a integridade e o não repúdio das solicitações de API, exigindo que os clientes assinem o payload da solicitação usando HMAC-SHA256.

Para gerar a assinatura, você precisará dos seguintes valores

1. Chave de API: Sua chave de API exclusiva.

2. Caminho Completo e Consulta: O caminho completo do endpoint da API junto com os parâmetros de consulta.

3. X-Request-Id: O ID da requisição. Se não estiver disponível, você pode inserir uma string vazia.

4. Corpo da solicitação: O corpo da solicitação. Se estiver vazio ou nulo, você pode inserir uma string vazia.

A string a ser assinada é uma combinação dos valores mencionados acima, concatenados na seguinte ordem:

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

Gerar a assinatura HMAC-SHA256

Depois de construir stringToSign, calcule a assinatura usando HMAC-SHA256 com sua segredo como chave, depois Codificar em Base64 o resultado.

A assinatura é gerada usando as seguintes etapas:

1. Use o algoritmo HMAC-SHA256.

2. Use stringToSign (UTF-8) como a mensagem de entrada.

3. Use seu segredo (UTF-8) como a chave.

4. Codifique a saída do HMAC em Base64 (Base64 padrão)

Aplique o Assinatura gerado como o valor de X-Signature no cabeçalho da requisição

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)

Corpo

O corpo de uma requisição de API é usado para enviar dados ao servidor. É comumente incluído em requisições POST, PUT ou PATCH (normalmente não em requisições GET ou DELETE).

Formato do Conteúdo

O formato dos dados do corpo é determinado pelo cabeçalho Content-Type. Alguns formatos comuns incluem:

Casos de uso típicos

Requisições POST: O método POST é usado para criar um novo recurso no servidor. O corpo da solicitação geralmente contém os detalhes do recurso..

Requisições PUT: O método PUT é usado para atualizar um recurso existente substituindo-o por completo. O corpo da solicitação contém o recurso atualizado completo.

Requisições DELETE: O método DELETE é usado para remover um recurso existente do servidor. Não possui corpo de requisição.

Requisições GET: O método GET é usado para recuperar um recurso existente do servidor. Não possui corpo de requisição

Formato da Resposta

Todas as respostas da API são retornadas no formato JSON ou XML; o formato dos dados do corpo é determinado pelo cabeçalho Accept, fornecendo os dados solicitados ou uma mensagem de erro, se aplicável.

Formato do Conteúdo

A resposta em geral contém 3 partes: Código, Mensagem, Dados

Código: O status da requisição

Mensagem: Mais detalhes sobre o status

Dados: O corpo da resposta

Tratamento de erros

Códigos de status HTTP são números padronizados de três dígitos retornados por um servidor para indicar o resultado da solicitação de um cliente. Eles fornecem informações essenciais sobre se a solicitação foi processada com sucesso, requer ação adicional ou encontrou um erro. Esses códigos são divididos em cinco categorias, cada uma representando um tipo distinto de resposta.

Os códigos de status da nossa API seguem o protocolo HTTP/1.1, um padrão amplamente aceito que garante uma comunicação consistente e confiável. Ao usar HTTP/1.1, aproveitamos recursos como conexões persistentes e cache aprimorado para otimizar as interações entre cliente e servidor.

Visão geral do Webhook

Webhooks são uma ferramenta poderosa para automatizar processos e integrar sistemas. Eles permitem que você receba notificações em tempo real sobre eventos ou mudanças nas configurações da sua conta ou do seu domínio. Ao configurar webhooks, você pode disparar ações em sistemas externos, atualizar bancos de dados ou enviar notificações com base em eventos específicos.

A API da Dynadot oferece suporte a notificações webhook para vários eventos, como registro de domínio, transferência, renovação e expiração, para que você possa tomar as medidas apropriadas em resposta.

Para usar webhooks, você precisa fornecer um endpoint de URL para onde as notificações serão enviadas. Você pode configurar a URL, a chave e o segredo do seu webhook nas configurações da sua conta. Quando um evento ocorrer, a Dynadot enviará uma solicitação POST para a URL especificada com os dados relevantes.

Cabeçalho da solicitação de webhook

O cabeçalho de uma solicitação Webhook contém metadados sobre a solicitação. Esses metadados fornecem contexto essencial para que o servidor processe a solicitação corretamente. Cabeçalhos comumente usados incluem:

Content-Type

Especifica o formato dos dados sendo enviados no corpo da requisição. O servidor usa esta informação para analisar a requisição corretamente. Atualmente o único valor aceitável é: application/json

Content-Type: application/json

Autorização

Todas as requisições de Webhook incluirão uma chave de Webhook para autenticação. Você pode obter sua chave de Webhook no painel da sua conta.

Você pode gerenciar sua WEBHOOK_KEY na página de configurações da API

Authorization: Bearer WEBHOOK_KEY

X-Signature

O cabeçalho X-Signature é um mecanismo de segurança obrigatório para solicitações transacionais, incluindo aquelas que recuperam informações sensíveis ou atualizam dados. Ele garante a autenticidade, integridade e não repúdio das solicitações de Webhook ao exigir que os clientes assinem o payload da solicitação usando HMAC-SHA256.

Para gerar a assinatura, você precisará dos seguintes valores

1. Chave do WEBHOOK: Sua chave WEBHOOK exclusiva.

2. Caminho Completo e Consulta: O caminho completo do endpoint do WEBHOOK junto com os parâmetros de consulta.

3. X-Request-Id: O ID da requisição. Se não estiver disponível, você pode inserir uma string vazia.

4. Corpo da solicitação: O corpo da solicitação. Se estiver vazio ou nulo, você pode inserir uma string vazia.

A string a ser assinada é uma combinação dos valores mencionados acima, concatenados na seguinte ordem:

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

Gerar a assinatura HMAC-SHA256

Depois de construir stringToSign, calcule a assinatura usando HMAC-SHA256 com sua segredo como chave, depois Codificar em Base64 o resultado.

A assinatura é gerada usando as seguintes etapas:

1. Use o algoritmo HMAC-SHA256.

2. Use stringToSign (UTF-8) como a mensagem de entrada.

3. Use seu segredo (UTF-8) como a chave.

4. Codifique a saída do HMAC em Base64 (Base64 padrão)

Aplique o Assinatura gerado como o valor de X-Signature no cabeçalho da requisição

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)

Formato da requisição de Webhook

Formato do Conteúdo

O corpo de uma requisição de webhook contém informações sobre o evento que disparou a notificação. O formato dos dados do corpo é determinado pelo cabeçalho Content-Type, que normalmente é application/json.

O corpo da solicitação inclui os seguintes parâmetros:

Exemplo:

Parâmetros

O corpo da requisição contém os seguintes parâmetros:

Parâmetro	Descrição
Evento	O tipo de evento que acionou a notificação.
ID do evento	O ID do evento que acionou a notificação.
Data e hora	O carimbo de data/hora em que o evento ocorreu.
dados	Os dados associados ao evento.

Formato de resposta do Webhook

Formato do Conteúdo

A resposta a uma solicitação de webhook será enviada no formato JSON, dependendo do cabeçalho Content-Type especificado na solicitação.

O corpo da resposta contém informações sobre o status da requisição, como se ela foi processada com sucesso ou se encontrou um erro.

A resposta em geral contém 1 parte: Status

Exemplo:

Limitação de Taxa

As solicitações devem ser enviadas por https (soquete seguro) por segurança. Apenas 1 solicitação pode ser processada por vez, então aguarde a solicitação atual terminar antes de enviar outra solicitação.

Você receberá diferentes números de threads com base no nível de preço da sua conta:

Nível de preço	Contagem de threads	Limite de taxa
Regular	1 thread	60/min (1/seg)
Em Lote	5 threads	600/min (10/seg)
Super Bulk	35 threads	6000/min (100/seg)

Nota: place_auction_bid & get_auction_bid estão atualmente isentos do limite de taxa acima.

Para o Comando de Avaliação de Domínio, você receberá diferentes contagens de solicitações permitidas com base no nível de preço da sua conta:

Nível de preço	Limite de taxa
Regular	50/dia
Em Lote	100/dia
Super Bulk	300/dia

Sandbox

O ambiente Sandbox da API da Dynadot permite testar suas integrações de API com segurança sem afetar sua conta ativa ou fundos reais.

Como acessar o Sandbox

1. Faça login na sua conta Dynadot e navegue até a página de configurações da API:

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

3. Gere sua Chave de API do Sandbox e sua Chave Secreta de API do Sandbox.

4. Após a geração, aguarde algum tempo para que o sistema ative suas chaves de sandbox e crie sua conta Sandbox.

5. A sua conta Sandbox será pré-carregada com um saldo de 10,000 em todas as moedas suportadas para fins de teste.

Usando a API Sandbox

Os comandos da API no ambiente Sandbox são funcionalmente iguais aos do ambiente de produção.

A única diferença é a URL base:

URL da API de produção: https://api.dynadot.com

URL da API de sandbox: https://api-sandbox.dynadot.com

Notas importantes

Alguns comandos da API podem estar indisponíveis no ambiente Sandbox. Consulte a documentação específica do comando para verificar o rótulo "Suporte ao Sandbox de API".

O Sandbox foi projetado principalmente para testes. Alguns comandos podem ser diferentes da Produção, e o Sandbox não consegue simular completamente todos os cenários complexos possíveis encontrado no ambiente de Produção.

Visão Geral do Log de Alterações

Um Registro de Alterações é um registro detalhado de mudanças, melhorias, correções de bugs e novos recursos introduzidos em cada versão da API. Ele fornece transparência para usuários e desenvolvedores ao documentar o impacto de cada atualização. É composto por duas partes principais:

Versão da API

Esta parte destaca o sistema de versionamento da API, que ajuda os desenvolvedores a acompanhar a evolução dos recursos e garantir a compatibilidade. Cada versão da API é identificada por um número de versão exclusivo (por exemplo, v1.0.1, v2.2.3) e representa um marco ou lançamento significativo. O versionamento permite que os usuários mantenham integrações com o mínimo de interrupção ao optar por atualizações quando estiverem prontos.

Histórico de alterações

O Histórico de Alterações fornece informações detalhadas sobre atualizações, correções de bugs, depreciações e melhorias introduzidas em cada versão. Ele descreve mudanças específicas feitas em endpoints, parâmetros, mecanismos de autenticação ou formatos de resposta. Esta seção garante que os desenvolvedores tenham total transparência sobre o que mudou e possam ajustar suas implementações de acordo. Ao manter um registro de alterações claro e detalhado, nosso objetivo é fornecer aos desenvolvedores as ferramentas e informações necessárias para gerenciar integrações de forma eficaz e confiante.

Versão da API

Nossa API está atualmente na versão v2.0.0

Os códigos de versão são usados para identificar e gerenciar sistematicamente as atualizações da API. Eles seguem o formato de Versionamento Semântico (SemVer):

Cada componente do código de versão tem uma finalidade específica e ajuda os desenvolvedores a comunicar o escopo e o tipo de alterações de forma eficaz.

Versão principal

Definição: Representa mudanças significativas que podem quebrar a compatibilidade com versões anteriores.

Formato:

x.<Minor>.x

Exemplos: v1.0.0 -> v2.0.0: Uma reformulação completa da API ou alterações de esquema incompatíveis.

Versão secundária

Definição: Indica adições de recursos compatíveis com versões anteriores.

Formato:

x.<Minor>.x

Exemplos: v1.0.0 -> v1.1.0: Adicionar novos endpoints ou métodos mantendo a compatibilidade com versões anteriores.

Versão do Patch

Definição: Refere-se a correções de bugs compatíveis com versões anteriores ou melhorias menores.

Formato:

x.x.<Patch>

Exemplos: v1.0.0 -> v1.1.0: Corrigindo um bug menor em um endpoint de API.

Registro de Alterações da API

Um changelog é um registro detalhado de alterações, melhorias, correções de bugs e novos recursos introduzidos em cada versão de um software ou de uma API. Ele proporciona transparência para usuários e desenvolvedores ao documentar o impacto de cada atualização.

Uma entrada típica em um changelog inclui:

Descrição: Uma breve explicação do que foi alterado.

Componentes afetados: Módulos, endpoints ou recursos específicos afetados pela alteração.

Exemplo: Adicionado suporte para este novo comando de API <Registro de Domínio>

Histórico de alterações

Acompanhe cada alteração na API da Dynadot.

9 de outubro de 2025

v2.0.0Novos Recursos & Alterações Principais Ambiente Sandbox Agora Disponível O ambiente Sandbox foi lançado oficialmente e está disponível para testes seguros e validação de integração. Cabeçalho X-Signature obrigatório para operações sensíveis Para aumentar a segurança, o cabeçalho X-Signature agora é exigido em todos os comandos sensíveis da API. (Opcional) Documentação da API legível por máquina Agora oferecemos suporte à documentação de API estruturada e legível por máquina para facilitar a integração com ferramentas automatizadas. Acesso à pesquisa restrito O acesso a certos endpoints relacionados à pesquisa foi restrito por motivos de desempenho e controle de dados. Lista de permissões de IP otimizada Não é mais necessário que a conta de revendedor insira pelo menos 1 IP para usar a API (somente API RESTful) Melhorias na documentação da API Seletor de versão atualizado na página inicial da documentação para facilitar a navegação Convenções de uso de maiúsculas e minúsculas unificadas em nomes de parâmetros Documentação e orientações de uso ampliadas para o endpoint bulk_search Adicionado recurso para ocultar/exibir navegação lateral

Introduzidos parâmetros de paginação obrigatórios para melhorar a eficiência e a consistência das respostas. page (integer, required) – Especifica o índice da página atual, começando em 1. page_size (inteiro, obrigatório) – Define o número de itens retornados por página.get_listings