API de Domínio - Lista de Comandos de API

API do Dynadot

Começando com Nossa API RESTful

A API da Dynadot é projetada para uma integração perfeita com seus sistemas. Nossa API apresenta URLs orientadas a recursos previsíveis, suporta corpos de solicitação codificados em JSON, retorna respostas codificadas em JSON e XML, e adere aos métodos HTTP padrão, autenticação e códigos de resposta.Você pode usar a API da Dynadot tanto em modo de teste quanto em modo ao vivo. O modo é determinado pela chave da API utilizada para autenticar suas solicitações. O modo de teste permite que você simule e valide sua integração com a API sem afetar dados ou transações ao vivo.A API Dynadot é principalmente voltada para a gestão 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 solicitação é limitado a um objeto ou ação.

Gerando suas Chaves de APIAntes de começar a fazer qualquer solicitação à API, é essencial gerar sua Chave da API e Segredo da API.Essas chaves são necessárias para autenticação e para garantir a segurança de suas ações ao interagir com nossa API.Você pode gerar tanto a Chave da API quanto o Segredo da API na seção de API nas configurações da sua conta.1. Faça login na sua conta na Dynadot.2. Navegue até Ferramentas > API.3. Gere sua Chave de API e Segredo de API a partir desta página.

Junte-se à nossa ComunidadeTem alguma ideia ou sugestão? Fale diretamente com nossos engenheiros profissionais.Discord

Método HTTPA API utiliza métodos HTTP padrão para realizar operações em recursos:

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

A URL base para todas as solicitações da API é:https://api.dynadot.com/

O formato completo da URL:Sure! Here’s the translation of your text into Portuguese: http://api.dynadot.com/restful/version_code/resource/{resource_identify}/action

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

Versão

A versão atual da API év

Ao construir a URL de solicitação da API, é necessário incluir apenas a versão principal. Atualizações menores e de correção 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 e correções incrementais sem precisar modificar sua implementação.Quando versões futuras forem lançadas, manteremos a compatibilidade com versões anteriores por um período de tempo. Novos recursos e mudanças significativas serão introduzidos em incrementos de versão principal.

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

Content-TypeEspecifica o formato dos dados que estão sendo enviados no corpo da solicitação. O servidor usa essa informação para analisar a solicitação corretamente. Atualmente, o único valor aceitável é: application/json

Content-Type: application/json

AceitarInforma o servidor sobre o formato de resposta esperado pelo cliente.Valores possíveis: application/json, application/xml

Accept: application/json

AutorizaçãoTodas 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.You can generate an API key in API setting page

Authorization: Bearer YOUR_API_KEY

X-Request-IDO cabeçalho X-Request-ID é um cabeçalho opcional usado para identificar de forma única cada solicitação de API. Quando incluído, esse cabeçalho ajuda a rastrear e correlacionar solicitaçõ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 (Identificador Único Universal) válido, 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-AssinaturaO 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 da API, exigindo que os clientes assinem o payload da solicitação usando HMAC-SHA256.

Para gerar a assinatura, você precisará dos seguintes valoresChave da 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 solicitaçã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 = "/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\"}"

Gerar a Assinatura HMAC-SHA256Após construir a string a ser assinada, você precisa aplicar a criptografia HMAC-SHA256 usando sua chave secreta. Esse processo criará a assinatura.A assinatura é gerada utilizando os seguintes passos:1. Utilize o algoritmo HMAC-SHA256.Sure! Please provide the text you would like me to translate into Portuguese.3. Use o segredo como a chave.
Aplique a assinatura gerada como o valor de X-Signature no cabeçalho da solicitação.

X-Signature: {HMAC-SHA256 Signature}

BodyO corpo de uma solicitação de API é utilizado para enviar dados ao servidor. Ele é comumente incluído em solicitações POST, PUT ou PATCH (não é típico para solicitações GET ou DELETE).

Sure! Please provide the text you would like me to translate into Portuguese.O formato dos dados do corpo é determinado pelo cabeçalho Content-Type. Alguns formatos comuns incluem:

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

Casos de Uso TípicosSolicitações POST: O método POST é utilizado 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 é utilizado para atualizar um recurso existente, substituindo-o completamente. O corpo da requisição contém o recurso atualizado na íntegra.Solicitações GET: O método DELETE é utilizado para remover um recurso existente do servidor. Ele não possui um corpo de solicitação.Solicitações DELETE: O método GET é utilizado para recuperar um recurso existente do servidor. Ele não possui um corpo de solicitação

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

Sure! Please provide the text you would like me to translate into Portuguese.Sure! Please provide the text you would like me to translate into Portuguese.

Código: O status da solicitaçãoMensagem: Mais descrição do statusDados: O corpo da resposta

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

Tratamento de ErrosOs 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, se requer uma ação adicional ou se 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 utilizar o HTTP/1.1, aproveitamos recursos como conexões persistentes e cache aprimorado para otimizar as interações entre cliente e servidor.

2xx (Bem-sucedido): Indica que o comando foi recebido e aceito

200O código de status indica que a solicitação foi bem-sucedida.

201O código de status indica que a solicitação foi atendida e resultou na criação de um ou mais novos recursos.

202O código de status indica que a solicitação foi aceita para processamento, mas o processamento não foi concluído.

249O usuário enviou muitas solicitações em um determinado período de tempo.

4xx (Erro do Cliente): Indica que o cliente cometeu um erro na solicitação, como fornecer uma entrada inválida ou não ter a devida autorização.

400O código de status indica que o servidor não pode ou não irá processar a solicitação devido a algo que é percebido como um erro do cliente.

401O código de status indica que a solicitação não foi aplicada porque falta credenciais de autenticação válidas para o recurso de destino.

402O código de status indica que a solicitação não foi aplicada devido a um problema de pagamento.

403O código de status indica que o servidor entendeu a solicitação, mas se recusa a atendê-la.

404O código de status indica que o servidor de origem não encontrou uma representação atual para o recurso de destino ou não está disposto a revelar que uma existe.

409A solicitação não pôde ser concluída devido a um conflito com o estado atual do recurso.

5xx (Erro do Servidor): Indica que o servidor encontrou um erro ou não consegue atender à solicitação.

500O código de status indica que o servidor encontrou uma condição inesperada que o impediu de atender à solicitação.

501O código de status indica que o servidor não suporta a funcionalidade necessária para atender à solicitação.

502O código de status indica que o servidor, ao atuar como um gateway ou proxy, recebeu uma resposta inválida de um servidor de entrada que acessou ao tentar atender à solicitação.

503O código de status indica que o servidor está atualmente incapaz de processar a solicitação devido a uma sobrecarga temporária ou manutenção programada, que provavelmente será resolvida após algum atraso.

504O código de status indica que o servidor, ao atuar como um gateway ou proxy, não recebeu uma resposta em tempo hábil de um servidor upstream que precisava acessar para concluir a solicitação.

CódigoNome do Status

200Sucesso

201Criado

202Aceito

249Muitas solicitações

400Solicitação Inválida

401Não autorizado

402Pagamento Necessário

403Proibido

404Não Encontrado

409Conflito

500Erro Interno do Servidor

501Não Implementado

502Gateway Ruim

503Serviço Indisponível

504Tempo de Espera do Gateway Excedido

Limitação de TaxaAs solicitações devem ser enviadas por https (socket seguro) para garantir a segurança. Apenas 1 solicitação pode ser processada por vez, portanto, aguarde a conclusão da sua solicitação atual antes de enviar outra.

Você receberá diferentes contagens de fios com base no nível de preço da sua conta:

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

Visão Geral do Registro 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 oferece transparência para usuários e desenvolvedores ao documentar o impacto de cada atualização. É composto por duas partes principais:

Versão da APIEsta parte destaca o sistema de versionamento da API, que ajuda os desenvolvedores a acompanhar a evolução das funcionalidades e garantir a compatibilidade. Cada versão da API é identificada por um número de versão único (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 mínima interrupção, optando por atualizações quando estiverem prontos.

Histórico de AlteraçõesO Histórico de Registro de Alterações fornece informações detalhadas sobre atualizações, correções de bugs, desativaçõ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ãov

Códigos de versão são utilizados para identificar e gerenciar atualizações da API de forma sistemática. Eles seguem o formato de Versionamento Semântico (SemVer):

Sure! Please provide the text you would like me to translate to Portuguese.Sure! Please provide the text you would like me to translate to Portuguese.Sure! Please provide the text you would like me to translate into Portuguese.

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

Versão PrincipalDefinição: Representa mudanças significativas que podem quebrar a compatibilidade retroativa.Of course! Please provide the text you would like me to translate into Portuguese.<Major>.x.x

Exemplos:v1.0.0->v2.0.0Uma redesign completa da API ou mudanças de esquema incompatíveis.

Versão MenorDefinição: Indica adições de recursos que são compatíveis com versões anteriores.Of course! Please provide the text you would like me to translate into Portuguese.x.<Minor>.x

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

Versão do PatchDefinição: Refere-se a correções de bugs ou melhorias menores que são compatíveis com versões anteriores.Of course! Please provide the text you would like me to translate into Portuguese.x.x.<Patch>

Exemplos:v1.0.0->v1.1.0Corrigindo um pequeno erro em um endpoint da API.

Registro de Alterações da API

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

Uma entrada típica em um registro de alterações inclui:Descrição: Uma breve explicação sobre o que foi alterado.Componentes Afetados: Módulos, endpoints ou funcionalidades específicas impactadas pela mudança.

Exemplo: Suporte adicionado para este novo comando da APISure! Here’s the translation of your text into Portuguese: <Registro de Domínio>

Histórico de AlteraçõesAcompanhe todas as alterações na API da Dynadot.