API dei domini - Elenco dei comandi API

Come iniziare con la nostra API RESTful

L'API di Dynadot è progettata per un'integrazione fluida con i tuoi sistemi. La nostra API presenta URL prevedibili orientati alle risorse, supporta corpi di richiesta codificati in JSON, restituisce risposte codificate in JSON e XML, e aderisce ai metodi HTTP standard, all'autenticazione e ai codici di risposta.

Puoi usare l'API Dynadot sia in modalità test che in modalità live. La modalità è determinata dalla chiave API usata per autenticare le tue richieste. La modalità test ti consente di simulare e convalidare l'integrazione API senza influire sui dati o sulle transazioni reali.

L'API di Dynadot è principalmente incentrata sulla gestione dei domini, sull'elaborazione degli ordini e sui servizi correlati. Puoi eseguire azioni come registrare, trasferire e rinnovare domini, gestire le impostazioni DNS e visualizzare o aggiornare gli ordini dell'account.

Nota bene: Le creazioni, aggiornamenti, eliminazioni in blocco non sono supportati, e ciascuno di quei tipi di richiesta è limitato a un oggetto o azione.

Generazione delle tue chiavi API

Prima di iniziare a effettuare qualsiasi richiesta API, è essenziale generare la tua API Key e il tuo API Secret.

Queste chiavi sono necessarie per l'autenticazione e per garantire la sicurezza delle tue azioni quando interagisci con la nostra API.

Puoi generare sia la Chiave API che il Segreto API tramite la sezione API nelle impostazioni del tuo account.

1. Accedi al tuo account su Dynadot.

2. Vai su Strumenti > API.

3. Genera i tuoi Chiave API e Segreto API da questa pagina.

Unisciti alla nostra Community

Hai idee o suggerimenti? Parla direttamente con i nostri ingegneri professionisti.

Discord

Metodo HTTP

L'API utilizza metodi HTTP standard per eseguire operazioni sulle risorse:

Metodo	Descrizione
GET	Richiesta GET: Recupera informazioni dettagliate su una risorsa specificata
POST	Richiesta POST: crea una nuova risorsa
PUT	Richiesta PUT: Aggiorna completamente la risorsa specificata
DELETE	Richiesta DELETE: Rimuove la risorsa specificata

URL

L'URL di base per tutte le richieste API è:

https://api.dynadot.com/

Il formato dell'URL completo:

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

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

Versione

La versione attuale dell'API è v2.0.0

Quando costruisci l'URL della richiesta API, è sufficiente includere solo la versione major. Gli aggiornamenti minor e patch sono progettati per essere retrocompatibili e non introdurranno modifiche che rompono il tuo codice esistente. Questo garantisce stabilità e allo stesso tempo ti permette di beneficiare di miglioramenti e correzioni incrementali senza dover modificare la tua implementazione.

Quando verranno rilasciate versioni future, manterremo la compatibilità con le versioni precedenti per un certo periodo di tempo. Le nuove funzionalità e le modifiche incompatibili verranno introdotte con incrementi di versione principale.

Intestazione

L'intestazione di una richiesta API contiene metadati sulla richiesta. Questi metadati forniscono il contesto essenziale affinché il server elabori correttamente la richiesta. Le intestazioni comunemente utilizzate includono:

Tipo di contenuto

Specifica il formato dei dati inviati nel corpo della richiesta. Il server utilizza queste informazioni per analizzare correttamente la richiesta. Attualmente l'unico valore accettabile è: application/json

Content-Type: application/json

Accetta

Informa il server del formato di risposta atteso dal client.

Valori possibili: application/json, application/xml

Accept: application/json

Autorizzazione

Tutte le richieste API devono includere una chiave API per l'autenticazione. Puoi ottenere la tua chiave API dalla dashboard del tuo account.

Puoi generare una chiave API nella pagina delle impostazioni API

Authorization: Bearer YOUR_API_KEY

X-Request-ID

L'header X-Request-ID è un header (Opzionale) usato per identificare in modo univoco ogni richiesta API. Se incluso, questo header aiuta a tracciare e correlare le richieste tra sistemi e log, rendendo più facile il debug e il monitoraggio dell'attività API.

Il valore di X-Request-ID deve essere un UUID valido (Identificatore Univoco Universale), seguendo il formato standard: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (ad es., 123e4567-e89b-12d3-a456-426614174000).

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

X-Signature Nuovo

L'header X-Signature è un meccanismo di sicurezza obbligatorio per le richieste transazionali, comprese quelle che recuperano informazioni sensibili o aggiornano dati. Garantisce l'autenticità, l'integrità e la non ripudiabilità delle richieste API richiedendo ai client di firmare il payload della richiesta usando HMAC-SHA256.

Per generare la firma, avrai bisogno dei seguenti valori

1. Chiave API: La tua chiave API univoca.

2. Percorso completo e query: Il percorso completo dell'endpoint API insieme ai parametri di query.

3. X-Request-Id: L'ID della richiesta. Se non è disponibile, puoi inserire una stringa vuota.

4. Corpo della richiesta: Il corpo della richiesta. Se è vuoto o nullo, puoi inserire una stringa vuota.

La stringa da firmare è una combinazione dei valori sopra menzionati, concatenati nel seguente ordine:

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

Genera la firma HMAC-SHA256

Dopo aver costruito stringToSign, calcola la firma utilizzando HMAC-SHA256 con la tua segreto come chiave, quindi Codifica Base64 il risultato.

La firma viene generata utilizzando i seguenti passaggi:

1. Utilizza l'algoritmo HMAC-SHA256.

2. Usa stringToSign (UTF-8) come messaggio di input.

3. Usa il tuo secret (UTF-8) come chiave.

4. Codifica l'output HMAC in Base64 (Base64 standard)

Applica il Firma generato come valore di X-Signature nell'header della richiesta

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

Il corpo di una richiesta API viene utilizzato per inviare dati al server. È comunemente incluso nelle richieste POST, PUT o PATCH (non di solito per richieste GET o DELETE).

Formato del contenuto

Il formato dei dati del body è determinato dall'header Content-Type. Alcuni formati comuni includono:

Casi d'uso tipici

Richieste POST: Il metodo POST viene utilizzato per creare una nuova risorsa sul server. Il corpo della richiesta di solito contiene i dettagli della risorsa..

Richieste PUT: Il metodo PUT viene usato per aggiornare una risorsa esistente sostituendola completamente. Il corpo della richiesta contiene la risorsa aggiornata completa.

Richieste DELETE: Il metodo DELETE viene utilizzato per rimuovere una risorsa esistente dal server. Non ha un corpo della richiesta.

Richieste GET: Il metodo GET viene utilizzato per recuperare una risorsa esistente dal server. Non ha un corpo della richiesta

Formato della risposta

Tutte le risposte dell'API vengono restituite in formato JSON o XML; il formato dei dati del corpo è determinato dall'header Accept, fornendo i dati richiesti o un messaggio di errore, se applicabile.

Formato del contenuto

La risposta in generale contiene 3 parti: Codice, Messaggio, Dati

Codice: Lo stato della richiesta

Messaggio: Ulteriori dettagli sullo stato

Dati: Il corpo della risposta

Gestione degli errori

I codici di stato HTTP sono numeri standardizzati a tre cifre restituiti da un server per indicare l'esito della richiesta di un client. Forniscono informazioni essenziali sul fatto che la richiesta sia stata elaborata correttamente, richieda ulteriori azioni o abbia incontrato un errore. Questi codici sono divisi in cinque categorie, ognuna delle quali rappresenta un tipo distinto di risposta.

I codici di stato della nostra API aderiscono al protocollo HTTP/1.1, uno standard ampiamente accettato che garantisce una comunicazione coerente e affidabile. Utilizzando HTTP/1.1, sfruttiamo funzionalità come connessioni persistenti e caching migliorato per ottimizzare le interazioni client-server.

Panoramica sui webhook

I Webhook sono uno strumento potente per automatizzare processi e integrare sistemi. Ti consentono di ricevere notifiche in tempo reale su eventi o modifiche al tuo account o alle impostazioni del dominio. Configurando i webhook, puoi attivare azioni in sistemi esterni, aggiornare database o inviare notifiche in base a eventi specifici.

L'API di Dynadot supporta notifiche webhook per vari eventi, come la registrazione, il trasferimento, il rinnovo e la scadenza del dominio, così puoi intraprendere le azioni appropriate in risposta.

Per utilizzare i webhook, devi fornire un endpoint URL a cui verranno inviate le notifiche. Puoi configurare l'URL, la chiave e il secret del tuo webhook nelle impostazioni del tuo account. Quando si verifica un evento, Dynadot invierà una richiesta POST all'URL specificato con i dati pertinenti.

Intestazione della richiesta Webhook

L'intestazione di una richiesta Webhook contiene metadati sulla richiesta. Questi metadati forniscono un contesto essenziale per il server per elaborare correttamente la richiesta. Le intestazioni comunemente usate includono:

Tipo di contenuto

Specifica il formato dei dati inviati nel corpo della richiesta. Il server utilizza queste informazioni per analizzare correttamente la richiesta. Attualmente l'unico valore accettabile è: application/json

Content-Type: application/json

Autorizzazione

Tutte le richieste Webhook includeranno una chiave Webhook per l'autenticazione. Puoi ottenere la tua chiave Webhook dalla dashboard del tuo account.

Puoi gestire la tua WEBHOOK_KEY nella pagina delle impostazioni API

Authorization: Bearer WEBHOOK_KEY

X-Signature

L'header X-Signature è un meccanismo di sicurezza obbligatorio per le richieste transazionali, incluse quelle che recuperano informazioni sensibili o aggiornano dati. Garantisce l'autenticità, l'integrità e il non ripudio delle richieste Webhook richiedendo ai client di firmare il payload della richiesta utilizzando HMAC-SHA256.

Per generare la firma, avrai bisogno dei seguenti valori

1. Chiave WEBHOOK: la tua chiave WEBHOOK univoca.

2. Percorso completo e query: Il percorso completo dell'endpoint WEBHOOK insieme ai parametri di query.

3. X-Request-Id: L'ID della richiesta. Se non è disponibile, puoi inserire una stringa vuota.

4. Corpo della richiesta: Il corpo della richiesta. Se è vuoto o nullo, puoi inserire una stringa vuota.

La stringa da firmare è una combinazione dei valori sopra menzionati, concatenati nel seguente ordine:

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

Genera la firma HMAC-SHA256

Dopo aver costruito stringToSign, calcola la firma utilizzando HMAC-SHA256 con la tua segreto come chiave, quindi Codifica Base64 il risultato.

La firma viene generata utilizzando i seguenti passaggi:

1. Utilizza l'algoritmo HMAC-SHA256.

2. Usa stringToSign (UTF-8) come messaggio di input.

3. Usa il tuo secret (UTF-8) come chiave.

4. Codifica l'output HMAC in Base64 (Base64 standard)

Applica il Firma generato come valore di X-Signature nell'header della richiesta

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 della richiesta webhook

Formato del contenuto

Il corpo di una richiesta webhook contiene informazioni sull'evento che ha attivato la notifica. Il formato dei dati del corpo è determinato dall'header Content-Type, che di solito è application/json.

Il corpo della richiesta include i seguenti parametri:

Esempio:

Parametri

Il corpo della richiesta contiene i seguenti parametri:

Parametro	Descrizione
Evento	Il tipo di evento che ha attivato la notifica.
ID evento	L'id dell'evento che ha attivato la notifica.
marca temporale	Il timestamp in cui si è verificato l'evento.
dati	I dati associati all'evento.

Formato della risposta del webhook

Formato del contenuto

La risposta a una richiesta webhook verrà inviata in formato JSON, a seconda dell'header Content-Type specificato nella richiesta.

Il corpo della risposta contiene informazioni sullo stato della richiesta, ad esempio se è stata elaborata correttamente o ha riscontrato un errore.

La risposta in generale contiene 1 parte: Stato

Esempio:

Limitazione della frequenza

Le richieste devono essere inviate tramite https (socket sicuro) per sicurezza. È possibile elaborare solo 1 richiesta alla volta, quindi attendi che la richiesta corrente termini prima di inviarne un'altra.

Riceverai un numero diverso di thread in base al livello di prezzo del tuo account:

Livello di prezzo	Panoramica sui webhook	Limite di frequenza
Regolare	1 thread	60/min (1/sec)
Bulk	5 thread	600/min (10/sec)
Super Bulk	35 thread	6000/min (100/sec)

Nota: place_auction_bid & get_auction_bid sono attualmente esenti dal limite di frequenza sopra indicato.

Per il comando Domain Appraisal, riceverai un numero diverso di richieste consentite in base al livello di prezzo del tuo account:

Livello di prezzo	Limite di frequenza
Regolare	50/giorno
Bulk	100/giorno
Super Bulk	300 al giorno

Sandbox

L'ambiente Sandbox dell'API Dynadot ti consente di testare in sicurezza le tue integrazioni API senza influire sul tuo account live o sui fondi reali.

Come accedere alla Sandbox

1. Accedi al tuo account Dynadot e vai alla pagina delle impostazioni API:

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

3. Genera la tua chiave API Sandbox e la tua chiave segreta API Sandbox.

4. Dopo la generazione, dai un po' di tempo al sistema per attivare le tue chiavi sandbox e creare il tuo account Sandbox.

5. Il tuo account Sandbox sarà prefinanziato con un saldo di 10,000 in tutte le valute supportate a scopo di test.

Utilizzo dell'API Sandbox

I comandi API nell'ambiente Sandbox sono funzionalmente gli stessi dell'ambiente di produzione.

L'unica differenza è l'URL di base:

URL dell'API di produzione: https://api.dynadot.com

URL dell'API sandbox: https://api-sandbox.dynadot.com

Note importanti

Alcuni comandi API potrebbero non essere disponibili nell'ambiente Sandbox. Si prega di fare riferimento alla documentazione specifica del comando per verificare l'etichetta "Sandbox API di supporto".

La Sandbox è progettata principalmente per i test. Alcuni comandi possono differire dalla Produzione, e la Sandbox non può simulare completamente tutti i possibili scenari complessi trovata nell'ambiente di Produzione.

Panoramica del registro delle modifiche

Un Change Log è una registrazione dettagliata dei cambiamenti, miglioramenti, correzioni di bug e nuove funzionalità introdotte in ogni versione dell'API. Fornisce trasparenza per utenti e sviluppatori documentando l'impatto di ogni aggiornamento. È composto da due parti chiave:

Versione API

Questa parte mette in evidenza il sistema di versioning dell'API, che aiuta gli sviluppatori a monitorare l'evoluzione delle funzionalità e garantire la compatibilità. Ogni versione dell'API è identificata da un numero di versione univoco (ad es., v1.0.1, v2.2.3) e rappresenta una tappa significativa o un rilascio. Il versioning consente agli utenti di mantenere le integrazioni con interruzioni minime, optando per gli aggiornamenti quando sono pronti.

Cronologia delle modifiche

La Cronologia delle modifiche fornisce informazioni dettagliate su aggiornamenti, correzioni di bug, deprecazioni e miglioramenti introdotti in ciascuna versione. Delinea le modifiche specifiche apportate agli endpoint, ai parametri, ai meccanismi di autenticazione o ai formati di risposta. Questa sezione garantisce agli sviluppatori la piena trasparenza su ciò che è cambiato e consente loro di adattare le proprie implementazioni di conseguenza. Mantenendo un registro delle modifiche chiaro e dettagliato, miriamo a fornire agli sviluppatori gli strumenti e le informazioni necessarie per gestire le integrazioni in modo efficace e con fiducia.

Versione API

La nostra API è attualmente alla versione v2.0.0

I codici di versione vengono utilizzati per identificare e gestire sistematicamente gli aggiornamenti API. Seguono il formato Semantic Versioning (SemVer):

Ogni componente del codice di versione serve a uno scopo specifico e aiuta gli sviluppatori a comunicare efficacemente la portata e il tipo di modifiche.

Versione principale

Definizione: Rappresenta cambiamenti significativi che potrebbero compromettere la compatibilità con le versioni precedenti.

Formato:

x.<Minor>.x

Esempi: v1.0.0 -> v2.0.0: Una riprogettazione completa dell'API o modifiche allo schema incompatibili.

Versione minore

Definizione: indica aggiunte di funzionalità retrocompatibili.

Formato:

x.<Minor>.x

Esempi: v1.0.0 -> v1.1.0: Aggiunta di nuovi endpoint o metodi mantenendo la retrocompatibilità.

Versione patch

Definizione: Si riferisce a correzioni di bug retrocompatibili o miglioramenti minori.

Formato:

x.x.<Patch>

Esempi: v1.0.0 -> v1.1.0: Correzione di un piccolo bug in un endpoint API.

Registro delle modifiche API

Un Change Log è un registro dettagliato di modifiche, miglioramenti, correzioni di bug e nuove funzionalità introdotte in ogni versione di software o API. Fornisce trasparenza per utenti e sviluppatori documentando l'impatto di ogni aggiornamento.

Una voce tipica in un changelog include:

Descrizione: Una breve spiegazione di ciò che è stato modificato.

Componenti interessati: Moduli, endpoint o funzionalità specifiche interessate dalla modifica.

Esempio: Aggiunto il supporto per questo nuovo comando API <Registrazione dominio>

Cronologia delle modifiche

Tieni traccia di ogni modifica all'API Dynadot.

9 ottobre 2025

v2.0.0Nuove funzionalità e modifiche principali Ambiente Sandbox ora attivo L'ambiente Sandbox è ufficialmente lanciato e disponibile per test sicuri e convalida dell'integrazione. Header X-Signature obbligatorio per le operazioni sensibili Per migliorare la sicurezza, l'header X-Signature è ora obbligatorio per tutti i comandi API sensibili. (Opzionale) Documentazione API leggibile dalle macchine Ora supportiamo documentazione API strutturata e leggibile dalle macchine per facilitare l'integrazione con strumenti automatizzati. Accesso alla ricerca limitato L'accesso ad alcuni endpoint relativi alla ricerca è stato limitato per motivi di prestazioni e controllo dei dati. Whitelisting IP ottimizzato L'account reseller non deve più inserire almeno 1 IP per usare l'API (solo API RESTful) Miglioramenti alla documentazione API Selettore di versione aggiornato nella pagina iniziale della documentazione per facilitare la navigazione Convenzioni unificate per l'uso di maiuscole/minuscole nei nomi dei parametri Documentazione ampliata e linee guida d'uso per l'endpoint bulk_search Aggiunta la funzione per nascondere/mostrare la navigazione laterale

Introdotti parametri di paginazione obbligatori per migliorare l'efficienza e la coerenza delle risposte. page (integer, required) – Specifica l'indice della pagina corrente, a partire da 1. page_size (intero, obbligatorio) – Definisce il numero di elementi restituiti per pagina.get_listings