Pemberitahuan Beta: Dokumentasi API ini masih Beta. Endpoint, field, kode kesalahan, dan perilaku dapat berubah tanpa pemberitahuan dan kompatibilitas mundur tidak dijamin. Hindari mengandalkannya untuk alur kerja produksi yang kritis.

Memulai dengan RESTful API Kami

API Dynadot dirancang untuk integrasi yang mulus dengan sistem Anda. API kami memiliki URL berorientasi sumber daya yang dapat diprediksi, mendukung isi permintaan yang dikodekan JSON, mengembalikan respons yang dikodekan JSON dan XML, serta mengikuti metode HTTP standar, autentikasi, dan kode respons.

Anda dapat menggunakan API Dynadot dalam mode uji maupun live. Mode ditentukan oleh kunci API yang digunakan untuk mengautentikasi permintaan Anda. Mode uji memungkinkan Anda menyimulasikan dan memvalidasi integrasi API tanpa memengaruhi data atau transaksi live.

API Dynadot terutama berfokus pada manajemen domain, pemrosesan pesanan, dan layanan terkait. Anda dapat melakukan tindakan seperti mendaftarkan, mentransfer, dan memperpanjang domain, mengelola pengaturan DNS, serta melihat atau memperbarui pesanan akun.

Harap diperhatikan: Pembuatan, pembaruan, penghapusan massal tidak didukung, dan setiap jenis permintaan tersebut dibatasi hanya untuk satu objek atau tindakan.

Membuat Kunci API Anda

Sebelum Anda mulai membuat permintaan API apa pun, sangat penting untuk membuat API Key dan API Secret Anda.

Kunci-kunci ini diperlukan untuk autentikasi dan untuk memastikan keamanan tindakan Anda saat berinteraksi dengan API kami.

Anda dapat membuat API Key dan API Secret melalui bagian API di pengaturan akun Anda.

1. Masuk ke akun Anda di Dynadot.

2. Navigasi ke Alat > API.

3. Hasilkan Kunci API dan API Secret Anda dari halaman ini.

Bergabunglah dengan Komunitas kami

Punya ide atau saran? Bicara langsung dengan engineer profesional kami.

Discord

Metode HTTP

API menggunakan metode HTTP standar untuk melakukan operasi pada sumber daya:

MetodeDeskripsi
GETPermintaan GET: Mengambil informasi rinci tentang sumber daya yang ditentukan
POSTPermintaan POST: Buat sumber daya baru
PUTPermintaan PUT: Perbarui sepenuhnya sumber daya yang ditentukan
DELETEPermintaan DELETE: Hapus resource yang ditentukan

URL

URL dasar untuk semua permintaan API adalah:

https://api.dynadot.com/

Format URL lengkap:

http://api.dynadot.com/restful/version_code/resource/{resource_identify}/action
Contoh :
https://api.dynadot.com/restful/v2/domains/{domain_name}/search

Versi

Versi API saat ini adalah v2.0.0

Saat menyusun URL permintaan API, Anda hanya perlu menyertakan versi major. Pembaruan minor dan patch dirancang agar kompatibel dengan versi sebelumnya dan tidak akan menimbulkan perubahan yang merusak kode yang sudah ada. Ini menjaga stabilitas sekaligus memungkinkan Anda mendapatkan manfaat dari peningkatan dan perbaikan bertahap tanpa perlu mengubah implementasi Anda.

Saat versi mendatang dirilis, kami akan mempertahankan kompatibilitas mundur untuk versi lama selama jangka waktu tertentu. Fitur baru dan perubahan yang tidak kompatibel akan diperkenalkan pada kenaikan versi utama.

Tajuk

Header dari permintaan API berisi metadata tentang permintaan tersebut. Metadata ini memberikan konteks penting bagi server untuk memproses permintaan dengan benar. Header yang umum digunakan meliputi:

Content-Type

Menentukan format data yang dikirim dalam body permintaan. Server menggunakan informasi ini untuk memproses permintaan dengan benar. Saat ini satu-satunya nilai yang dapat diterima adalah: application/json

Contoh :
Content-Type: application/json

Terima

Memberi tahu server tentang format respons yang diharapkan oleh klien.

Nilai yang mungkin: application/json, application/xml

Contoh :
Accept: application/json

Otorisasi

Semua permintaan API harus menyertakan kunci API untuk autentikasi. Anda bisa mendapatkan kunci API dari dasbor akun Anda.

Anda dapat membuat API key di halaman pengaturan API
Contoh Header Autentikasi :
Authorization: Bearer YOUR_API_KEY

X-Request-ID

Header X-Request-ID adalah header (Opsional) yang digunakan untuk mengidentifikasi setiap permintaan API secara unik. Jika disertakan, header ini membantu melacak dan menghubungkan permintaan di seluruh sistem dan log, sehingga memudahkan proses debug dan pemantauan aktivitas API.

Nilai X-Request-ID harus berupa UUID (Pengenal Unik Universal) yang valid, mengikuti format standar: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (contoh: 123e4567-e89b-12d3-a456-426614174000).

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

X-Signature Baru

Header X-Signature adalah mekanisme keamanan wajib untuk permintaan transaksional, termasuk yang mengambil informasi sensitif atau memperbarui data. Ini memastikan keaslian, integritas, dan non-repudiasi permintaan API dengan mewajibkan klien menandatangani payload permintaan menggunakan HMAC-SHA256.

Untuk menghasilkan tanda tangan, Anda memerlukan nilai-nilai berikut

1. Kunci API: Kunci API unik Anda.

2. Path Lengkap dan Query: Path lengkap dari endpoint API beserta parameter query.

3. X-Request-Id: ID permintaan. Jika tidak tersedia, Anda dapat memasukkan string kosong.

4. Body Permintaan: Body dari permintaan. Jika kosong atau null, Anda dapat memasukkan string kosong.

String yang akan ditandatangani adalah kombinasi dari nilai-nilai yang disebutkan di atas, yang digabungkan dalam urutan berikut:

apiKey + "\n" + fullPathAndQuery + "\n" + (xRequestId or empty String) + "\n" + (requestBody or empty String)
Contoh
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\"}"
Hasilkan Tanda Tangan HMAC-SHA256

Setelah membangun stringToSign, hitung tanda tangan menggunakan HMAC-SHA256 dengan rahasia Anda sebagai kunci, lalu Enkode Base64 hasilnya.

Tanda tangan dihasilkan menggunakan langkah-langkah berikut:

1. Gunakan algoritma HMAC-SHA256.

2. Gunakan stringToSign (UTF-8) sebagai pesan masukan.

3. Gunakan secret Anda (UTF-8) sebagai kunci.

4. Enkode keluaran HMAC dalam Base64 (Base64 standar)

Terapkan Tanda Tangan yang dihasilkan sebagai nilai dari X-Signature pada header request

Example :
X-Signature: {HMAC-SHA256 Signature}
Example Code :
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)

Isi

Body permintaan API digunakan untuk mengirim data ke server. Biasanya disertakan dalam permintaan POST, PUT, atau PATCH (biasanya tidak untuk permintaan GET atau DELETE).

Format Konten

Format data body ditentukan oleh header Content-Type. Beberapa format umum meliputi:

JSON

Kasus Penggunaan Umum

Permintaan POST: Metode POST digunakan untuk membuat resource baru di server. Body request biasanya berisi detail resource..

Permintaan PUT: Metode PUT digunakan untuk memperbarui sumber daya yang sudah ada dengan menggantinya sepenuhnya. Body permintaan berisi sumber daya lengkap yang telah diperbarui.

Permintaan DELETE: Metode DELETE digunakan untuk menghapus sumber daya yang ada dari server. Tidak memiliki body permintaan.

Permintaan GET: Metode GET digunakan untuk mengambil sumber daya yang sudah ada dari server. Tidak memiliki body permintaan

Format Respons

Semua respons API dikembalikan dalam format JSON atau XML. Format data body ditentukan oleh header Accept, yang menyediakan data yang diminta atau pesan error, jika berlaku.

Format Konten

Secara umum, respons berisi 3 bagian: Code, Message, Data

Kode: Status permintaan

Pesan: Deskripsi lebih lanjut tentang status

Data: Body dari respons

JSON/XML

Penanganan Kesalahan

Kode Status HTTP adalah angka tiga digit terstandarisasi yang dikembalikan oleh server untuk menunjukkan hasil permintaan klien. Kode ini memberikan informasi penting tentang apakah permintaan berhasil diproses, memerlukan tindakan lebih lanjut, atau mengalami error. Kode-kode ini dibagi menjadi lima kategori, masing-masing mewakili jenis respons yang berbeda.

Kode status API kami mengikuti protokol HTTP/1.1, standar yang diterima secara luas yang memastikan komunikasi yang konsisten dan andal. Dengan menggunakan HTTP/1.1, kami memanfaatkan fitur seperti koneksi persisten dan caching yang ditingkatkan untuk mengoptimalkan interaksi klien-server.

2xx (Berhasil): Menunjukkan bahwa perintah telah diterima dan disetujui
4xx (Kesalahan Klien): Menandakan bahwa klien melakukan kesalahan dalam permintaan, seperti memberikan input yang tidak valid atau tidak memiliki otorisasi yang sesuai.
5xx (Kesalahan Server): Menunjukkan bahwa server mengalami kesalahan atau tidak dapat memenuhi permintaan.

Ringkasan Webhook

Webhook adalah alat yang ampuh untuk mengotomatiskan proses dan mengintegrasikan sistem. Webhook memungkinkan Anda menerima notifikasi real-time tentang peristiwa atau perubahan pada pengaturan akun atau domain Anda. Dengan mengonfigurasi webhook, Anda dapat memicu tindakan di sistem eksternal, memperbarui basis data, atau mengirim notifikasi berdasarkan peristiwa tertentu.

API Dynadot mendukung notifikasi webhook untuk berbagai peristiwa, seperti pendaftaran domain, transfer, perpanjangan, dan kedaluwarsa, sehingga Anda dapat mengambil tindakan yang sesuai sebagai respons.

Untuk menggunakan webhook, Anda perlu menyediakan endpoint URL tempat notifikasi akan dikirim. Anda dapat mengonfigurasi URL webhook, key, dan secret Anda di pengaturan akun. Saat peristiwa terjadi, Dynadot akan mengirim permintaan POST ke URL yang ditentukan dengan data yang relevan.

Header Permintaan Webhook

Header dari permintaan Webhook berisi metadata tentang permintaan tersebut. Metadata ini memberikan konteks penting agar server dapat memproses permintaan dengan benar. Header yang umum digunakan meliputi:

Content-Type

Menentukan format data yang dikirim dalam body permintaan. Server menggunakan informasi ini untuk memproses permintaan dengan benar. Saat ini satu-satunya nilai yang dapat diterima adalah: application/json

Contoh :
Content-Type: application/json

Otorisasi

Semua permintaan Webhook akan menyertakan kunci Webhook untuk autentikasi. Anda bisa mendapatkan kunci Webhook dari dasbor akun Anda.

Anda dapat mengelola WEBHOOK_KEY Anda di halaman pengaturan API
Contoh Header Autentikasi :
Authorization: Bearer WEBHOOK_KEY

X-Signature

Header X-Signature adalah mekanisme keamanan wajib untuk permintaan transaksional, termasuk permintaan yang mengambil informasi sensitif atau memperbarui data. Ini memastikan keaslian, integritas, dan non-repudiasi permintaan Webhook dengan mewajibkan klien menandatangani payload permintaan menggunakan HMAC-SHA256.

Untuk menghasilkan tanda tangan, Anda memerlukan nilai-nilai berikut

1. Kunci WEBHOOK: Kunci WEBHOOK unik Anda.

2. Path Lengkap dan Query: Jalur lengkap endpoint WEBHOOK beserta parameter kueri.

3. X-Request-Id: ID permintaan. Jika tidak tersedia, Anda dapat memasukkan string kosong.

4. Body Permintaan: Body dari permintaan. Jika kosong atau null, Anda dapat memasukkan string kosong.

String yang akan ditandatangani adalah kombinasi dari nilai-nilai yang disebutkan di atas, yang digabungkan dalam urutan berikut:

webhookKey + "\n" + fullPathAndQuery + "\n" + (xRequestId or empty String) + "\n" + (requestBody or empty String)
Contoh
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\"}"
Hasilkan Tanda Tangan HMAC-SHA256

Setelah membangun stringToSign, hitung tanda tangan menggunakan HMAC-SHA256 dengan rahasia Anda sebagai kunci, lalu Enkode Base64 hasilnya.

Tanda tangan dihasilkan menggunakan langkah-langkah berikut:

1. Gunakan algoritma HMAC-SHA256.

2. Gunakan stringToSign (UTF-8) sebagai pesan masukan.

3. Gunakan secret Anda (UTF-8) sebagai kunci.

4. Enkode keluaran HMAC dalam Base64 (Base64 standar)

Terapkan Tanda Tangan yang dihasilkan sebagai nilai dari X-Signature pada header request

Example :
X-Signature: {HMAC-SHA256 Signature}
Example Code :
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)

Format Permintaan Webhook

Format Konten

Isi dari permintaan webhook berisi informasi tentang peristiwa yang memicu notifikasi. Format data isi ditentukan oleh header Content-Type, yang biasanya application/json.

Body dari permintaan mencakup parameter berikut:

Contoh:

JSON/XML

Parameter

Isi permintaan berisi parameter berikut:

ParameterDeskripsi
AcaraJenis peristiwa yang memicu notifikasi.
event_idID dari event yang memicu notifikasi.
stempel waktuStempel waktu saat peristiwa terjadi.
dataData yang terkait dengan peristiwa tersebut.

Format Respons Webhook

Format Konten

Respons terhadap permintaan webhook akan dikirim dalam format JSON, bergantung pada header Content-Type yang ditentukan dalam permintaan.

Body respons berisi informasi tentang status permintaan, seperti apakah berhasil diproses atau mengalami kesalahan.

Respons umumnya berisi 1 bagian: Status

Contoh:

JSON/XML

Pembatasan Laju

Permintaan harus dikirim melalui https (secure socket) demi keamanan. Hanya 1 permintaan yang dapat diproses pada satu waktu, jadi harap tunggu permintaan Anda saat ini selesai sebelum mengirim permintaan lain.

Anda akan menerima jumlah thread yang berbeda berdasarkan tingkat harga akun Anda:

Tingkat hargaJumlah ThreadBatas Laju
Biasa1 thread60/menit (1/detik)
Bulk5 thread600/menit (10/detik)
Super Bulk35 utas6000/menit (100/detik)

Catatan: place_auction_bid & get_auction_bid saat ini dikecualikan dari batas laju di atas.

Contoh :

Untuk Perintah Penilaian Domain, Anda akan menerima jumlah permintaan yang diizinkan berbeda berdasarkan tingkat harga akun Anda:

Tingkat hargaBatas Laju
Biasa50/hari
Bulk100/hari
Super Bulk300/hari
Contoh :

Sandbox

Lingkungan Sandbox API Dynadot memungkinkan Anda menguji integrasi API dengan aman tanpa memengaruhi akun live atau dana asli Anda.

Cara Mengakses Sandbox

1. Masuk ke akun Dynadot Anda dan buka halaman pengaturan API:

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

3. Hasilkan Kunci Sandbox API dan Kunci Rahasia Sandbox API Anda.

4. Setelah dibuat, harap tunggu beberapa saat agar sistem mengaktifkan kunci sandbox Anda dan membuat akun Sandbox Anda.

5. Akun Sandbox Anda akan diisi sebelumnya dengan saldo 10,000 dalam semua mata uang yang didukung untuk tujuan pengujian.

Menggunakan API Sandbox

Perintah API di lingkungan Sandbox secara fungsional sama dengan lingkungan produksi.

Satu-satunya perbedaannya adalah URL dasar:

Catatan Penting

Beberapa perintah API mungkin tidak tersedia di lingkungan Sandbox. Silakan merujuk ke dokumentasi perintah spesifik untuk memeriksa label "Dukungan API Sandbox".

Sandbox dirancang terutama untuk pengujian. Perintah tertentu mungkin berbeda dari Production, dan Sandbox tidak dapat sepenuhnya mensimulasikan semua skenario kompleks yang mungkin yang ada di lingkungan Production.

Ringkasan Change Log

Change Log adalah catatan rinci tentang perubahan, peningkatan, perbaikan bug, dan fitur baru yang diperkenalkan di setiap versi API. Ini memberikan transparansi bagi pengguna dan pengembang dengan mendokumentasikan dampak dari setiap pembaruan. Ini terdiri dari dua bagian utama:

Versi API

Bagian ini menyoroti sistem versi API, yang membantu pengembang melacak evolusi fitur dan memastikan kompatibilitas. Setiap versi API diidentifikasi dengan nomor versi unik (misalnya, v1.0.1, v2.2.3) dan mewakili tonggak atau rilis yang signifikan. Pembuatan versi memungkinkan pengguna mempertahankan integrasi dengan gangguan minimal dengan memilih pembaruan saat siap.

Riwayat Log Perubahan

Riwayat Change Log memberikan informasi terperinci tentang pembaruan, perbaikan bug, depresiasi, dan peningkatan yang diperkenalkan di setiap versi. Ini menguraikan perubahan spesifik yang dilakukan pada endpoint, parameter, mekanisme autentikasi, atau format respons. Bagian ini memastikan pengembang memiliki transparansi penuh tentang apa yang telah berubah dan dapat menyesuaikan implementasi mereka sesuai kebutuhan. Dengan menjaga change log yang jelas dan terperinci, kami bertujuan memberi pengembang alat dan informasi yang diperlukan untuk mengelola integrasi secara efektif dan percaya diri.

Versi API

API kami saat ini dalam versi v2.0.0

Kode versi digunakan untuk mengidentifikasi dan mengelola pembaruan API secara sistematis. Mereka mengikuti format Semantic Versioning (SemVer):

<Major><Minor><Patch>

Setiap komponen dari kode versi memiliki tujuan tertentu dan membantu pengembang mengomunikasikan cakupan dan jenis perubahan secara efektif.

Versi Mayor

Definisi: Mewakili perubahan signifikan yang dapat merusak kompatibilitas mundur.

Format:

x.<Minor>.x
Contoh: v1.0.0 -> v2.0.0: Perombakan API secara menyeluruh atau perubahan skema yang tidak kompatibel.

Versi Minor

Definisi: Menunjukkan penambahan fitur yang kompatibel mundur.

Format:

x.<Minor>.x
Contoh: v1.0.0 -> v1.1.0: Menambahkan endpoint atau metode baru sambil tetap menjaga kompatibilitas mundur.

Versi Patch

Definisi: Mengacu pada perbaikan bug yang kompatibel mundur atau peningkatan kecil.

Format:

x.x.<Patch>
Contoh: v1.0.0 -> v1.1.0: Memperbaiki bug kecil di endpoint API.

Log Perubahan API

Log Perubahan adalah catatan rinci tentang perubahan, peningkatan, perbaikan bug, dan fitur baru yang diperkenalkan pada setiap versi perangkat lunak atau API. Ini memberikan transparansi bagi pengguna dan pengembang dengan mendokumentasikan dampak dari setiap pembaruan.

Entri umum dalam log perubahan mencakup:

Deskripsi: Penjelasan singkat tentang apa yang diubah.

Komponen yang Terdampak: Modul, endpoint, atau fitur spesifik yang terdampak oleh perubahan.

Contoh: Menambahkan dukungan untuk perintah API baru ini <Registrasi Domain>

Riwayat Log Perubahan

Pantau setiap perubahan pada API Dynadot.

9 Oktober 2025
v2.0.0Fitur Baru & Perubahan Penting Lingkungan Sandbox Kini Telah Aktif Lingkungan Sandbox resmi diluncurkan dan tersedia untuk pengujian aman serta validasi integrasi. Header X-Signature Wajib untuk Operasi Sensitif Untuk meningkatkan keamanan, header X-Signature kini diwajibkan untuk semua perintah API yang sensitif. (Opsional) Dokumentasi API yang Dapat Dibaca Mesin Kami sekarang mendukung dokumentasi API terstruktur yang dapat dibaca mesin untuk integrasi yang lebih mudah dengan alat otomatis. Akses Pencarian Dibatasi Akses ke beberapa endpoint terkait pencarian telah dibatasi untuk alasan performa dan kontrol data. Whitelisting IP dioptimalkan Akun reseller tidak lagi diwajibkan memasukkan minimal 1 IP untuk menggunakan API (hanya RESTful API) Peningkatan Dokumentasi API Pemilih versi yang diperbarui di halaman utama dokumentasi agar navigasi lebih mudah Konvensi kapitalisasi disatukan di seluruh nama parameter Memperluas dokumentasi dan panduan penggunaan untuk endpoint bulk_search Menambahkan fitur untuk menyembunyikan/menampilkan navigasi samping
Memperkenalkan parameter paging wajib untuk meningkatkan efisiensi dan konsistensi respons. page (integer, wajib) – Menentukan indeks halaman saat ini, dimulai dari 1. page_size (integer, required) – Menentukan jumlah item yang dikembalikan per halaman.get_listings