बीटा सूचना: यह API दस्तावेज़ बीटा में है. एंडपॉइंट, फ़ील्ड, त्रुटि कोड और व्यवहार बिना सूचना के बदल सकते हैं और बैकवर्ड अनुकूलता की गारंटी नहीं है. महत्वपूर्ण प्रोडक्शन वर्कफ़्लो के लिए इस पर निर्भर रहने से बचें.

हमारे RESTful API के साथ शुरुआत करें

Dynadot API आपके सिस्टम्स के साथ सीमलेस इंटीग्रेशन के लिए डिज़ाइन किया गया है। हमारा API पूर्वानुमेय resource-oriented URLs प्रदान करता है, JSON-encoded request bodies को सपोर्ट करता है, JSON-encoded और XML-encoded responses लौटाता है, और मानक HTTP methods, authentication, और response codes का पालन करता है।

आप Dynadot API का उपयोग टेस्ट और लाइव दोनों मोड में कर सकते हैं। मोड उस API कुंजी से निर्धारित होता है जिसका उपयोग आपके अनुरोधों को प्रमाणित करने के लिए किया जाता है। टेस्ट मोड आपको लाइव डेटा या लेन-देन को प्रभावित किए बिना अपने API इंटीग्रेशन को सिम्युलेट और सत्यापित करने की सुविधा देता है।

Dynadot API मुख्य रूप से डोमेन प्रबंधन, ऑर्डर प्रोसेसिंग, और संबंधित सेवाओं पर केंद्रित है। आप डोमेन रजिस्टर करने, ट्रांसफर करने, और रिन्यू करने, DNS सेटिंग्स प्रबंधित करने, और अकाउंट ऑर्डर देखने या अपडेट करने जैसी क्रियाएँ कर सकते हैं।

कृपया ध्यान दें: बल्क क्रिएशन, अपडेट, डिलीट समर्थित नहीं हैं, और उनमें से प्रत्येक अनुरोध प्रकार एक ऑब्जेक्ट या क्रिया तक सीमित है।

अपनी API Keys जनरेट करना

कोई भी API रिक्वेस्ट शुरू करने से पहले, अपनी API Key और API Secret जनरेट करना आवश्यक है।

ये कुंजियाँ प्रमाणीकरण के लिए आवश्यक हैं और हमारे API के साथ इंटरैक्ट करते समय आपकी क्रियाओं की सुरक्षा सुनिश्चित करने के लिए भी।

आप अपनी अकाउंट सेटिंग्स के API सेक्शन से API Key और API Secret दोनों जनरेट कर सकते हैं.

1. Dynadot पर अपने खाते में लॉग इन करें.

2. उपकरण > API पर जाएँ.

3. इस पेज से अपना API कुंजी और API सीक्रेट जनरेट करें।

हमारे समुदाय से जुड़ें

कोई विचार या सुझाव है? सीधे हमारे पेशेवर इंजीनियरों से बात करें।

डिस्कॉर्ड

HTTP मेथड

API संसाधनों पर ऑपरेशन करने के लिए मानक HTTP विधियों का उपयोग करता है:

मेथडविवरण
GETGET अनुरोध: निर्दिष्ट संसाधन के बारे में विस्तृत जानकारी प्राप्त करें
POSTPOST अनुरोध: नया रिसोर्स बनाएं
PUTPUT अनुरोध: निर्दिष्ट संसाधन को पूरी तरह अपडेट करें
DELETEDELETE अनुरोध: निर्दिष्ट रिसोर्स को हटाएं

यूआरएल

सभी API अनुरोधों के लिए आधार URL है:

https://api.dynadot.com/

पूर्ण URL प्रारूप:

http://api.dynadot.com/restful/version_code/resource/{resource_identify}/action
उदाहरण :
https://api.dynadot.com/restful/v2/domains/{domain_name}/search

संस्करण

API का वर्तमान वर्शन v2.0.0 है

API अनुरोध URL बनाते समय, केवल मेजर संस्करण शामिल करना आवश्यक है. माइनर और पैच अपडेट बैकवर्ड-कम्पैटिबल होने के लिए डिज़ाइन किए गए हैं और आपके मौजूदा कोड को तोड़ने वाले बदलाव नहीं लाएँगे. यह स्थिरता सुनिश्चित करता है जबकि आपको अपने इम्प्लीमेंटेशन को संशोधित किए बिना वृद्धिशील सुधारों और फिक्स का लाभ उठाने देता है.

जब भविष्य के वर्ज़न रिलीज़ होंगे, तो हम कुछ समय के लिए पुराने वर्ज़न के लिए बैकवर्ड कम्पैटिबिलिटी बनाए रखेंगे. नई सुविधाएँ और ब्रेकिंग बदलाव मेजर वर्ज़न इंक्रीमेंट में पेश किए जाएँगे.

शीर्षक

API अनुरोध का हेडर अनुरोध के बारे में मेटाडेटा रखता है। यह मेटाडेटा सर्वर को अनुरोध को ठीक से संसाधित करने के लिए आवश्यक संदर्भ प्रदान करता है। सामान्यतः उपयोग किए जाने वाले हेडर में शामिल हैं:

कंटेंट-टाइप

रिक्वेस्ट बॉडी में भेजे जा रहे डेटा का फ़ॉर्मेट निर्दिष्ट करता है। सर्वर इस जानकारी का उपयोग रिक्वेस्ट को सही ढंग से पार्स करने के लिए करता है। वर्तमान में एकमात्र स्वीकार्य मान है: application/json

उदाहरण :
Content-Type: application/json

स्वीकार करें

सर्वर को बताता है कि क्लाइंट किस रिस्पॉन्स फॉर्मेट की अपेक्षा करता है.

संभावित मान: application/json, application/xml

उदाहरण :
Accept: application/json

प्राधिकरण

सभी API अनुरोधों में ऑथेंटिकेशन के लिए एक API key शामिल होना चाहिए. आप अपनी API key अपने अकाउंट डैशबोर्ड से प्राप्त कर सकते हैं.

आप API सेटिंग पेज में एक API key जनरेट कर सकते हैं
प्रमाणीकरण हेडर उदाहरण :
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)।

उदाहरण :
X-Request-ID: 550e8400-e29b-41d4-a716-446655440000

X-Signature नया

X-Signature हेडर लेन-देन संबंधी अनुरोधों के लिए एक अनिवार्य सुरक्षा तंत्र है, जिनमें संवेदनशील जानकारी प्राप्त करने या डेटा अपडेट करने वाले अनुरोध भी शामिल हैं. यह API अनुरोधों की प्रामाणिकता, अखंडता और नॉन-रिप्यूडिएशन सुनिश्चित करता है, क्योंकि यह क्लाइंट्स से अपेक्षा करता है कि वे HMAC-SHA256 का उपयोग करके अनुरोध पेलोड पर हस्ताक्षर करें.

हस्ताक्षर जनरेट करने के लिए, आपको निम्नलिखित मानों की आवश्यकता होगी

1. API कुंजी: आपकी अद्वितीय API कुंजी.

2. पूर्ण पथ और क्वेरी: क्वेरी पैरामीटर्स के साथ API एंडपॉइंट का पूरा पथ.

3. X-Request-Id: अनुरोध आईडी। यदि यह उपलब्ध नहीं है, तो आप खाली स्ट्रिंग दर्ज कर सकते हैं।

4. रिक्वेस्ट बॉडी: रिक्वेस्ट की बॉडी। अगर यह खाली है या null है, तो आप खाली स्ट्रिंग दर्ज कर सकते हैं।

साइन की जाने वाली स्ट्रिंग ऊपर बताए गए मानों का संयोजन है, जो निम्नलिखित क्रम में जोड़ा गया है:

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\"}"
HMAC-SHA256 हस्ताक्षर जनरेट करें

stringToSign बनाने के बाद, अपनी सीक्रेट को key के रूप में उपयोग करके HMAC-SHA256 से सिग्नेचर की गणना करें, फिर परिणाम को Base64-एन्कोड करें करें।

सिग्नेचर निम्नलिखित चरणों का उपयोग करके जनरेट किया जाता है:

1. HMAC-SHA256 एल्गोरिदम का उपयोग करें.

2. इनपुट मैसेज के रूप में stringToSign (UTF-8) का इस्तेमाल करें.

3. अपने सीक्रेट (UTF-8) को कुंजी के रूप में उपयोग करें.

4. HMAC आउटपुट को Base64 (स्टैंडर्ड Base64) में एनकोड करें

जनरेट किए गए हस्ताक्षर को अनुरोध हेडर में X-Signature के मान के रूप में लागू करें

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)

बॉडी

API रिक्वेस्ट की बॉडी का उपयोग सर्वर को डेटा भेजने के लिए किया जाता है। यह आमतौर पर POST, PUT, या PATCH रिक्वेस्ट्स में शामिल होती है (आमतौर पर GET या DELETE रिक्वेस्ट्स के लिए नहीं)।

कंटेंट फॉर्मेट

बॉडी डेटा का प्रारूप Content-Type हेडर द्वारा निर्धारित होता है. कुछ सामान्य प्रारूपों में शामिल हैं:

JSON

सामान्य उपयोग के मामले

POST अनुरोध: सर्वर पर नया रिसोर्स बनाने के लिए POST मेथड का उपयोग किया जाता है. रिक्वेस्ट बॉडी में आमतौर पर रिसोर्स का विवरण होता है..

PUT अनुरोध: PUT मेथड का उपयोग किसी मौजूदा रिसोर्स को पूरी तरह बदलकर अपडेट करने के लिए किया जाता है। रिक्वेस्ट बॉडी में पूरा अपडेटेड रिसोर्स होता है।

DELETE अनुरोध: DELETE विधि का उपयोग सर्वर से किसी मौजूदा संसाधन को हटाने के लिए किया जाता है. इसमें रिक्वेस्ट बॉडी नहीं होती.

GET अनुरोध: GET विधि का उपयोग सर्वर से किसी मौजूदा संसाधन को प्राप्त करने के लिए किया जाता है. इसमें रिक्वेस्ट बॉडी नहीं होती

रिस्पॉन्स फॉर्मेट

सभी API प्रतिक्रियाएँ JSON या XML फ़ॉर्मैट में लौटाई जाती हैं, बॉडी डेटा का फ़ॉर्मैट Accept हेडर द्वारा निर्धारित होता है, और लागू होने पर अनुरोधित डेटा या त्रुटि संदेश प्रदान करती हैं।

कंटेंट फॉर्मेट

प्रतिक्रिया में सामान्यतः 3 भाग होते हैं: Code, Message, Data

कोड: अनुरोध की स्थिति

संदेश: स्थिति का अधिक विवरण

डेटा: प्रतिक्रिया की बॉडी

JSON/XML

एरर हैंडलिंग

HTTP स्थिति कोड मानकीकृत तीन-अंकीय संख्याएँ होती हैं जो सर्वर द्वारा क्लाइंट के अनुरोध के परिणाम को दर्शाने के लिए लौटाई जाती हैं। वे इस बारे में आवश्यक जानकारी देती हैं कि अनुरोध सफलतापूर्वक संसाधित हुआ, आगे की कार्रवाई की आवश्यकता है, या कोई त्रुटि हुई। ये कोड पाँच श्रेणियों में विभाजित हैं, जिनमें से प्रत्येक प्रतिक्रिया के एक अलग प्रकार को दर्शाती है।

हमारे API के स्टेटस कोड HTTP/1.1 प्रोटोकॉल का पालन करते हैं, जो एक व्यापक रूप से स्वीकृत मानक है जो सुसंगत और विश्वसनीय संचार सुनिश्चित करता है. HTTP/1.1 का उपयोग करके, हम क्लाइंट-सर्वर इंटरैक्शन को अनुकूलित करने के लिए पर्सिस्टेंट कनेक्शन और उन्नत कैशिंग जैसी सुविधाओं का लाभ उठाते हैं.

2xx (सफल): यह दर्शाता है कि कमांड प्राप्त और स्वीकृत हो गया था
4xx (क्लाइंट त्रुटि): यह संकेत देता है कि क्लाइंट ने अनुरोध में कोई त्रुटि की है, जैसे अमान्य इनपुट देना या उचित प्राधिकरण का अभाव होना.
5xx (सर्वर त्रुटि): इंगित करता है कि सर्वर को कोई त्रुटि मिली है या वह अनुरोध पूरा नहीं कर पा रहा है.

वेबहुक अवलोकन

वेबहुक्स प्रक्रियाओं को स्वचालित करने और सिस्टम्स को एकीकृत करने के लिए एक शक्तिशाली टूल हैं. ये आपको आपके अकाउंट या डोमेन सेटिंग्स में होने वाली घटनाओं या बदलावों के बारे में रीयल-टाइम नोटिफिकेशन प्राप्त करने देते हैं. वेबहुक्स कॉन्फ़िगर करके, आप बाहरी सिस्टम्स में कार्रवाइयाँ ट्रिगर कर सकते हैं, डेटाबेस अपडेट कर सकते हैं, या विशिष्ट इवेंट्स के आधार पर नोटिफिकेशन भेज सकते हैं.

Dynadot API विभिन्न इवेंट्स के लिए webhook नोटिफिकेशन्स का समर्थन करता है, जैसे डोमेन रजिस्ट्रेशन, ट्रांसफर, रिन्यूअल और एक्सपायरी, ताकि आप जवाब में उपयुक्त कार्रवाई कर सकें।

वेबहुक का उपयोग करने के लिए, आपको एक URL एंडपॉइंट प्रदान करना होगा जहाँ सूचनाएँ भेजी जाएँगी. आप अपने वेबहुक URL, कुंजी, और सीक्रेट को अपने खाता सेटिंग्स में कॉन्फ़िगर कर सकते हैं. जब कोई ईवेंट होता है, तो Dynadot निर्दिष्ट URL पर प्रासंगिक डेटा के साथ एक POST अनुरोध भेजेगा.

वेबहुक रिक्वेस्ट हेडर

Webhook अनुरोध का हेडर अनुरोध के बारे में मेटाडेटा रखता है। यह मेटाडेटा सर्वर को अनुरोध को ठीक से प्रोसेस करने के लिए आवश्यक संदर्भ प्रदान करता है। सामान्यतः उपयोग किए जाने वाले हेडर में शामिल हैं:

कंटेंट-टाइप

रिक्वेस्ट बॉडी में भेजे जा रहे डेटा का फ़ॉर्मेट निर्दिष्ट करता है। सर्वर इस जानकारी का उपयोग रिक्वेस्ट को सही ढंग से पार्स करने के लिए करता है। वर्तमान में एकमात्र स्वीकार्य मान है: application/json

उदाहरण :
Content-Type: application/json

प्राधिकरण

सभी Webhook अनुरोधों में ऑथेंटिकेशन के लिए एक Webhook key शामिल होगी। आप अपनी Webhook key अपने अकाउंट डैशबोर्ड से प्राप्त कर सकते हैं।

आप अपने WEBHOOK_KEY को API सेटिंग्स पेज में मैनेज कर सकते हैं
प्रमाणीकरण हेडर उदाहरण :
Authorization: Bearer WEBHOOK_KEY

X-Signature

X-Signature हेडर ट्रांजैक्शनल अनुरोधों के लिए एक अनिवार्य सुरक्षा तंत्र है, जिनमें संवेदनशील जानकारी प्राप्त करने या डेटा अपडेट करने वाले अनुरोध भी शामिल हैं। यह Webhook अनुरोधों की प्रामाणिकता, अखंडता और नॉन-रिप्यूडिएशन सुनिश्चित करता है, क्योंकि यह क्लाइंट्स से अपेक्षा करता है कि वे HMAC-SHA256 का उपयोग करके रिक्वेस्ट पेलोड पर हस्ताक्षर करें।

हस्ताक्षर जनरेट करने के लिए, आपको निम्नलिखित मानों की आवश्यकता होगी

1. वेबहुक कुंजी: आपकी अद्वितीय WEBHOOK कुंजी।

2. पूर्ण पथ और क्वेरी: क्वेरी पैरामीटर्स के साथ WEBHOOK एंडपॉइंट का पूरा पाथ.

3. X-Request-Id: अनुरोध आईडी। यदि यह उपलब्ध नहीं है, तो आप खाली स्ट्रिंग दर्ज कर सकते हैं।

4. रिक्वेस्ट बॉडी: रिक्वेस्ट की बॉडी। अगर यह खाली है या null है, तो आप खाली स्ट्रिंग दर्ज कर सकते हैं।

साइन की जाने वाली स्ट्रिंग ऊपर बताए गए मानों का संयोजन है, जो निम्नलिखित क्रम में जोड़ा गया है:

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\"}"
HMAC-SHA256 हस्ताक्षर जनरेट करें

stringToSign बनाने के बाद, अपनी सीक्रेट को key के रूप में उपयोग करके HMAC-SHA256 से सिग्नेचर की गणना करें, फिर परिणाम को Base64-एन्कोड करें करें।

सिग्नेचर निम्नलिखित चरणों का उपयोग करके जनरेट किया जाता है:

1. HMAC-SHA256 एल्गोरिदम का उपयोग करें.

2. इनपुट मैसेज के रूप में stringToSign (UTF-8) का इस्तेमाल करें.

3. अपने सीक्रेट (UTF-8) को कुंजी के रूप में उपयोग करें.

4. HMAC आउटपुट को Base64 (स्टैंडर्ड Base64) में एनकोड करें

जनरेट किए गए हस्ताक्षर को अनुरोध हेडर में X-Signature के मान के रूप में लागू करें

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)

वेबहुक अनुरोध प्रारूप

कंटेंट फॉर्मेट

वेबहुक अनुरोध की बॉडी में उस इवेंट के बारे में जानकारी होती है जिसने सूचना ट्रिगर की. बॉडी डेटा का प्रारूप Content-Type हेडर द्वारा निर्धारित होता है, जो आमतौर पर application/json होता है.

अनुरोध की बॉडी में निम्नलिखित पैरामीटर शामिल हैं:

उदाहरण:

JSON/XML

पैरामीटर

रिक्वेस्ट की बॉडी में निम्नलिखित पैरामीटर होते हैं:

पैरामीटरविवरण
आयोजननोटिफिकेशन ट्रिगर करने वाले इवेंट का प्रकार।
इवेंट_आईडीजिस इवेंट ने नोटिफिकेशन ट्रिगर किया उसकी id.
टाइमस्टैम्पजिस समय घटना हुई उसका टाइमस्टैम्प।
डेटाइवेंट से जुड़ा डेटा।

वेबहुक प्रतिक्रिया प्रारूप

कंटेंट फॉर्मेट

वेबहुक अनुरोध की प्रतिक्रिया JSON फ़ॉर्मैट में भेजी जाएगी, जो अनुरोध में निर्दिष्ट Content-Type हेडर पर निर्भर करती है।

रिस्पॉन्स बॉडी में अनुरोध की स्थिति के बारे में जानकारी होती है, जैसे कि वह सफलतापूर्वक प्रोसेस हुआ या कोई एरर आया।

प्रतिक्रिया में आम तौर पर 1 भाग होता है: स्थिति

उदाहरण:

JSON/XML

रेट लिमिटिंग

सुरक्षा के लिए अनुरोध https (सुरक्षित सॉकेट) पर भेजे जाने चाहिए। एक समय में केवल 1 अनुरोध प्रोसेस किया जा सकता है, इसलिए कृपया दूसरा अनुरोध भेजने से पहले अपने वर्तमान अनुरोध के पूरा होने का इंतज़ार करें।

आपको अपने अकाउंट के प्राइस लेवल के आधार पर अलग-अलग थ्रेड काउंट मिलेंगे:

मूल्य स्तरथ्रेड काउंटरेट लिमिट
नियमित1 थ्रेड60/मिनट (1/सेकंड)
बल्क5 थ्रेड्स600/मिनट (10/सेकंड)
सुपर बल्क35 थ्रेड्स6000/मिनट (100/सेकंड)

नोट: place_auction_bid और get_auction_bid वर्तमान में उपरोक्त रेट लिमिट से छूट प्राप्त हैं।

उदाहरण :

डोमेन अप्प्रेज़ल कमांड के लिए, आपके अकाउंट के प्राइस लेवल के आधार पर आपको अलग-अलग अनुमत रिक्वेस्ट काउंट मिलेंगे:

मूल्य स्तररेट लिमिट
नियमित50/दिन
बल्क100/दिन
सुपर बल्क300/दिन
उदाहरण :

सैंडबॉक्स

Dynadot API Sandbox वातावरण आपको आपके लाइव खाते या असली फंड को प्रभावित किए बिना अपने API इंटीग्रेशन को सुरक्षित रूप से परखने की सुविधा देता है।

सैंडबॉक्स तक कैसे पहुँचें

1. अपने Dynadot खाते में लॉग इन करें और API सेटिंग्स पेज पर नेविगेट करें:

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

3. अपनी API Sandbox Key और API Sandbox Secret Key जनरेट करें.

4. जनरेट करने के बाद, कृपया सिस्टम को अपनी सैंडबॉक्स कीज़ सक्रिय करने और आपका सैंडबॉक्स अकाउंट बनाने के लिए कुछ समय दें।

5. आपके Sandbox अकाउंट को परीक्षण उद्देश्यों के लिए सभी समर्थित करेंसियों में 10,000 के बैलेंस के साथ प्री-फंड किया जाएगा।

Sandbox API का उपयोग करना

सैंडबॉक्स परिवेश में API कमांड कार्यात्मक रूप से प्रोडक्शन परिवेश के समान हैं।

केवल अंतर बेस URL है:

प्रोडक्शन API URL: https://api.dynadot.com

सैंडबॉक्स API URL: https://api-sandbox.dynadot.com

महत्वपूर्ण नोट्स

सैंडबॉक्स वातावरण में कुछ API कमांड उपलब्ध नहीं हो सकते हैं। कृपया "API सैंडबॉक्स सपोर्ट" लेबल की जाँच के लिए संबंधित कमांड डॉक्यूमेंटेशन देखें।

सैंडबॉक्स मुख्य रूप से टेस्टिंग के लिए डिज़ाइन किया गया है। कुछ कमांड प्रोडक्शन से अलग हो सकते हैं, और सैंडबॉक्स सभी संभव जटिल परिदृश्यों को पूरी तरह से सिम्युलेट नहीं कर सकता प्रोडक्शन एनवायरनमेंट में पाया जाता है।

चेंज लॉग अवलोकन

Change Log API के हर version में पेश किए गए changes, improvements, bug fixes, और new features का विस्तृत रिकॉर्ड होता है। यह हर update के प्रभाव को document करके users और developers के लिए transparency प्रदान करता है। यह दो मुख्य भागों से बना है:

API संस्करण

यह भाग API की वर्जनिंग प्रणाली पर प्रकाश डालता है, जो डेवलपर्स को फीचर्स के विकास को ट्रैक करने और संगतता सुनिश्चित करने में मदद करता है। प्रत्येक API वर्जन को एक अद्वितीय वर्जन नंबर (जैसे, v1.0.1, v2.2.3) से पहचाना जाता है और यह एक महत्वपूर्ण माइलस्टोन या रिलीज़ को दर्शाता है। वर्जनिंग उपयोगकर्ताओं को तैयार होने पर अपडेट में ऑप्ट-इन करके न्यूनतम व्यवधान के साथ इंटीग्रेशन बनाए रखने की सुविधा देती है।

परिवर्तन लॉग इतिहास

Change Log History प्रत्येक संस्करण में पेश किए गए अपडेट, बग फ़िक्स, डेप्रिकेशन और एन्हांसमेंट के बारे में विस्तृत जानकारी देता है। यह एंडपॉइंट, पैरामीटर, प्रमाणीकरण तंत्र या रिस्पॉन्स फ़ॉर्मेट में किए गए विशिष्ट बदलावों की रूपरेखा देता है। यह अनुभाग सुनिश्चित करता है कि डेवलपर्स को इस बारे में पूरी पारदर्शिता हो कि क्या बदला है और वे अपने इम्प्लीमेंटेशन को तदनुसार समायोजित कर सकें। एक स्पष्ट और विस्तृत चेंज लॉग बनाए रखकर, हमारा लक्ष्य डेवलपर्स को इंटीग्रेशन को प्रभावी ढंग से और आत्मविश्वास के साथ प्रबंधित करने के लिए आवश्यक टूल्स और जानकारी प्रदान करना है।

API संस्करण

हमारा API वर्तमान में संस्करण v2.0.0 में है

संस्करण कोड का उपयोग API अपडेट को व्यवस्थित रूप से पहचानने और प्रबंधित करने के लिए किया जाता है। वे Semantic Versioning (SemVer) प्रारूप का पालन करते हैं:

<Major><Minor><Patch>

वर्ज़न कोड का प्रत्येक घटक एक विशिष्ट उद्देश्य पूरा करता है और डेवलपर्स को परिवर्तनों के दायरे और प्रकार को प्रभावी ढंग से संप्रेषित करने में मदद करता है.

प्रमुख संस्करण

परिभाषा: यह महत्वपूर्ण बदलावों को दर्शाता है जो बैकवर्ड कम्पैटिबिलिटी को तोड़ सकते हैं।

प्रारूप:

x.<Minor>.x
उदाहरण: v1.0.0 -> v2.0.0: पूर्ण API पुनःडिज़ाइन या असंगत स्कीमा परिवर्तन.

माइनर वर्शन

परिभाषा: पश्चगामी-संगत फ़ीचर जोड़ों को दर्शाता है।

प्रारूप:

x.<Minor>.x
उदाहरण: v1.0.0 -> v1.1.0: बैकवर्ड संगतता बनाए रखते हुए नए एंडपॉइंट्स या मेथड्स जोड़ना.

पैच संस्करण

परिभाषा: बैकवर्ड-संगत बग फिक्स या मामूली सुधारों को दर्शाता है।

प्रारूप:

x.x.<Patch>
उदाहरण: v1.0.0 -> v1.1.0: API एंडपॉइंट में एक मामूली बग ठीक करना.

API चेंज लॉग

चेंज लॉग सॉफ़्टवेयर या API के प्रत्येक संस्करण में पेश किए गए परिवर्तनों, सुधारों, बग फिक्स और नई सुविधाओं का विस्तृत रिकॉर्ड होता है. यह प्रत्येक अपडेट के प्रभाव को दर्ज करके उपयोगकर्ताओं और डेवलपर्स के लिए पारदर्शिता प्रदान करता है.

चेंज लॉग में एक सामान्य प्रविष्टि में ये शामिल होते हैं:

विवरण: क्या बदला गया इसका संक्षिप्त विवरण.

प्रभावित घटक: बदलाव से प्रभावित विशिष्ट मॉड्यूल, एंडपॉइंट या सुविधाएँ।

उदाहरण: इस नए API कमांड <डोमेन रजिस्टर> के लिए सपोर्ट जोड़ा गया

परिवर्तन लॉग इतिहास

Dynadot API में हर बदलाव पर नज़र रखें.

9 अक्टूबर, 2025
v2.0.0नई सुविधाएँ और मुख्य बदलाव सैंडबॉक्स एनवायरनमेंट अब लाइव है सैंडबॉक्स वातावरण आधिकारिक रूप से लॉन्च हो गया है और सुरक्षित परीक्षण तथा इंटीग्रेशन वैलिडेशन के लिए उपलब्ध है. संवेदनशील कार्यों के लिए अनिवार्य X-Signature हेडर सुरक्षा बढ़ाने के लिए, अब सभी संवेदनशील API कमांड के लिए X-Signature हेडर लागू किया गया है. (वैकल्पिक) मशीन-रीडेबल API डॉक्युमेंटेशन अब हम संरचित, मशीन-पठनीय API दस्तावेज़ का समर्थन करते हैं ताकि ऑटोमेटेड टूल्स के साथ एकीकरण आसान हो। सर्च एक्सेस प्रतिबंधित परफ़ॉर्मेंस और डेटा नियंत्रण कारणों से कुछ सर्च-संबंधित एंडपॉइंट्स तक पहुँच प्रतिबंधित कर दी गई है. IP व्हाइटलिस्टिंग को अनुकूलित किया गया API(केवल RESTful API) का उपयोग करने के लिए अब Reseller खाते में कम से कम 1 IP दर्ज करना आवश्यक नहीं है API डॉक्युमेंटेशन में सुधार आसान नेविगेशन के लिए डॉक्युमेंटेशन लैंडिंग पेज पर वर्शन सेलेक्टर को अपडेट किया गया। पैरामीटर नामों में एकीकृत कैसिंग कन्वेंशन bulk_search एंडपॉइंट के लिए दस्तावेज़ीकरण और उपयोग मार्गदर्शन का विस्तार किया गया साइड नेविगेशन को छिपाने/दिखाने की सुविधा जोड़ी गई
रेस्पॉन्स दक्षता और निरंतरता बेहतर करने के लिए अनिवार्य पेजिंग पैरामीटर पेश किए गए। page (इंटीजर, आवश्यक) – वर्तमान पेज इंडेक्स निर्दिष्ट करता है, जो 1 से शुरू होता है. page_size (integer, required) – प्रति पृष्ठ लौटाए जाने वाले आइटमों की संख्या निर्धारित करता है।get_listings