रिस्टफुल एपीआई
Beta Notice: This API documentation is Beta. Endpoints, fields, error codes, and behaviors may change without notice and backward compatibility is not guaranteed. Avoid relying on it for critical production workflows.
हमारे RESTful API के साथ शुरुआत करना
Dynadot API आपके सिस्टम के साथ सहज एकीकरण के लिए डिज़ाइन किया गया है। हमारा API पूर्वानुमानित संसाधन-आधारित URLs, JSON-कोडित अनुरोध निकायों का समर्थन करता है, JSON-कोडित और XML-कोडित प्रतिक्रियाएँ लौटाता है, और मानक HTTP विधियों, प्रमाणीकरण, और प्रतिक्रिया कोडों का पालन करता है।आप Dynadot API का उपयोग परीक्षण और लाइव दोनों मोड में कर सकते हैं। मोड उस API कुंजी द्वारा निर्धारित होता है जिसका उपयोग आपके अनुरोधों को प्रमाणित करने के लिए किया जाता है। परीक्षण मोड आपको अपने API एकीकरण का अनुकरण और मान्य करने की अनुमति देता है बिना लाइव डेटा या लेनदेन को प्रभावित किए।Dynadot API मुख्य रूप से डोमेन प्रबंधन, ऑर्डर प्रोसेसिंग और संबंधित सेवाओं पर केंद्रित है। आप डोमेन पंजीकरण, स्थानांतरण और नवीनीकरण, DNS सेटिंग्स का प्रबंधन, और खाता ऑर्डर को देखने या अपडेट करने जैसी क्रियाएँ कर सकते हैं।कृपया ध्यान दें: थोक निर्माण, अपडेट, और हटाने का समर्थन नहीं किया जाता है, और इन प्रत्येक अनुरोध प्रकार की सीमा एक वस्तु या क्रिया तक होती है।
आपके API कुंजी उत्पन्न करनाकिसी भी API अनुरोध करने से पहले, आपके लिए अपने API कुंजी और API गुप्त को उत्पन्न करना आवश्यक है।ये कुंजियाँ प्रमाणीकरण के लिए आवश्यक हैं और हमारे API के साथ बातचीत करते समय आपके कार्यों की सुरक्षा सुनिश्चित करने के लिए हैं।आप अपने खाता सेटिंग्स के API सेक्शन के माध्यम से API Key और API Secret दोनों उत्पन्न कर सकते हैं।1. अपने Dynadot खाते में लॉग इन करें।2. Tools > API पर जाएं।3. इस पृष्ठ से अपना API Key और API Secret उत्पन्न करें।


हमारे समुदाय में शामिल होंक्या आपके पास कोई विचार या सुझाव हैं? हमारे पेशेवर इंजीनियरों से सीधे बात करें।Discord
HTTP विधिAPI संसाधनों पर संचालन करने के लिए मानक HTTP विधियों का उपयोग करता है:
MethodDescription
GETGET Request: Retrieve detailed information about a specified resource
POSTPOST Request: Create a new resource
PUTPUT Request: Fully update the specified resource
DELETEDELETE Request: Remove the specified resource
यूआरएल
सभी API अनुरोधों के लिए आधार URL है:https://api.dynadot.com/
पूर्ण URL प्रारूप:http://api.dynadot.com/restful/version_code/resource/{resource_identify}/action
Example :
https://api.dynadot.com/restful/v2/domains/{domain_name}/search
संस्करण
API का वर्तमान संस्करण हैv2.0.0
API अनुरोध URL बनाते समय, केवल प्रमुख संस्करण को शामिल करना आवश्यक है। छोटे और पैच अपडेट को पिछले संस्करणों के साथ संगत बनाने के लिए डिज़ाइन किया गया है और ये आपके मौजूदा कोड को तोड़ने वाले परिवर्तन नहीं लाएंगे। यह स्थिरता सुनिश्चित करता है जबकि आपको बिना अपने कार्यान्वयन को संशोधित किए क्रमिक सुधारों और फिक्सेस का लाभ उठाने की अनुमति देता है।जब भविष्य के संस्करण जारी किए जाएंगे, हम पुराने संस्करणों के लिए एक निश्चित समय अवधि के लिए पीछे की संगतता बनाए रखेंगे। नए फीचर्स और महत्वपूर्ण बदलाव मुख्य संस्करण वृद्धि में पेश किए जाएंगे।
HeaderAPI अनुरोध का हेडर अनुरोध के बारे में मेटाडेटा शामिल करता है। यह मेटाडेटा सर्वर को अनुरोध को सही तरीके से संसाधित करने के लिए आवश्यक संदर्भ प्रदान करता है। सामान्यतः उपयोग किए जाने वाले हेडर में शामिल हैं:
Content-Typeयह अनुरोध के शरीर में भेजे जा रहे डेटा के प्रारूप को निर्दिष्ट करता है। सर्वर इस जानकारी का उपयोग अनुरोध को सही ढंग से पार्स करने के लिए करता है। वर्तमान में केवल एक स्वीकार्य मान है: application/json
Example :
Content-Type: application/json
स्वीकृत करेंक्लाइंट द्वारा अपेक्षित प्रतिक्रिया प्रारूप के बारे में सर्वर को सूचित करता है।संभावित मान: application/json, application/xml
Example :
Accept: application/json
अधिकारितासभी API अनुरोधों में प्रमाणीकरण के लिए एक API कुंजी शामिल होनी चाहिए। आप अपनी API कुंजी अपने खाते के डैशबोर्ड से प्राप्त कर सकते हैं।You can generate an API key in API setting page
प्रमाणीकरण हेडर उदाहरण :
Authorization: Bearer YOUR_API_KEY
X-Request-IDX-Request-ID हेडर एक वैकल्पिक हेडर है जिसका उपयोग प्रत्येक API अनुरोध की अद्वितीय पहचान के लिए किया जाता है। जब इसे शामिल किया जाता है, तो यह हेडर सिस्टम और लॉग के बीच अनुरोधों को ट्रैक और संबंधित करने में मदद करता है, जिससे API गतिविधियों को डिबग और मॉनिटर करना आसान हो जाता है।X-Request-ID का मान एक मान्य UUID (यूनिवर्सली यूनिक आइडेंटिफायर) होना चाहिए, जो मानक प्रारूप का पालन करता है: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (जैसे, 123e4567-e89b-12d3-a456-426614174000)।
Example :
X-Request-ID: 550e8400-e29b-41d4-a716-446655440000
X-SignatureNewX-Signature हेडर लेन-देन संबंधी अनुरोधों के लिए एक अनिवार्य सुरक्षा तंत्र है, जिसमें संवेदनशील जानकारी प्राप्त करने या डेटा को अपडेट करने वाले अनुरोध शामिल हैं। यह API अनुरोधों की प्रामाणिकता, अखंडता, और अस्वीकरण न करने की सुनिश्चितता प्रदान करता है, क्योंकि यह ग्राहकों को अनुरोध पेलोड को HMAC-SHA256 का उपयोग करके साइन करने की आवश्यकता करता है।
हस्ताक्षर उत्पन्न करने के लिए, आपको निम्नलिखित मानों की आवश्यकता होगीAPI कुंजी: आपकी अद्वितीय API कुंजी।2. पूर्ण पथ और क्वेरी: API एंडपॉइंट का पूर्ण पथ साथ ही क्वेरी पैरामीटर।3. X-Request-Id: अनुरोध आईडी। यदि यह उपलब्ध नहीं है, तो आप खाली स्ट्रिंग दर्ज कर सकते हैं।4. अनुरोध का शरीर: अनुरोध का शरीर। यदि यह खाली या शून्य है, तो आप खाली स्ट्रिंग दर्ज कर सकते हैं।
साइन करने के लिए स्ट्रिंग उपरोक्त उल्लेखित मानों का एक संयोजन है, जिसे निम्नलिखित क्रम में जोड़ा गया है:
apiKey + "\n" + fullPathAndQuery + "\n" + (xRequestId or empty String) + "\n" + (requestBody or empty String)
Example
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 बनाने के बाद, हस्ताक्षर की गणना करें HMAC-SHA256 का उपयोग करके अपने secret को कुंजी के रूप में, फिर परिणाम को Base64-encode करें।हस्ताक्षर निम्नलिखित चरणों का उपयोग करके उत्पन्न किया जाता है:HMAC-SHA256 एल्गोरिदम का उपयोग करें।2. stringToSign (UTF-8) को इनपुट संदेश के रूप में उपयोग करें।3. अपने secret (UTF-8) को कुंजी के रूप में उपयोग करें।4. HMAC आउटपुट को Base64 (मानक Base64) में एनकोड करें
हस्ताक्षर को अनुरोध हेडर में X-Signature के मान के रूप में लागू करें।
Example :
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)
BodyAPI अनुरोध का शरीर सर्वर को डेटा भेजने के लिए उपयोग किया जाता है। यह आमतौर पर POST, PUT, या PATCH अनुरोधों में शामिल होता है (GET या DELETE अनुरोधों के लिए सामान्यतः नहीं)।
Content Formatशरीर डेटा का प्रारूप Content-Type हेडर द्वारा निर्धारित किया जाता है। कुछ सामान्य प्रारूपों में शामिल हैं:
JSON
{
    "domainName": "domain.com",
    "showPrice": "yes",
    "currency": "USD"
}
सामान्य उपयोग के मामलेPOST अनुरोध: POST विधि का उपयोग सर्वर पर एक नया संसाधन बनाने के लिए किया जाता है। अनुरोध का शरीर आमतौर पर संसाधन विवरणों को शामिल करता है।PUT अनुरोध: PUT विधि का उपयोग एक मौजूदा संसाधन को पूरी तरह से बदलकर अपडेट करने के लिए किया जाता है। अनुरोध का शरीर पूर्ण अपडेटेड संसाधन को शामिल करता है।DELETE अनुरोध: DELETE विधि का उपयोग सर्वर से मौजूदा संसाधन को हटाने के लिए किया जाता है। इसमें अनुरोध बॉडी नहीं होतीGET अनुरोध: GET विधि का उपयोग सर्वर से मौजूदा संसाधन को पुनः प्राप्त करने के लिए किया जाता है। इसमें अनुरोध बॉडी नहीं होती
Response Formatसभी API प्रतिक्रियाएँ JSON या XML प्रारूप में लौटाई जाती हैं, जिसमें शरीर के डेटा का प्रारूप Accept हेडर द्वारा निर्धारित किया जाता है, जो अनुरोधित डेटा या एक त्रुटि संदेश प्रदान करता है, यदि लागू हो।
Content FormatThe response in general contains 3 parts: कोड, संदेश, डेटा
कोड: अनुरोध की स्थितिसंदेश: स्थिति का अधिक विवरणडेटा: प्रतिक्रिया का मुख्य भाग
JSON/XML
{
    "Code": 200,
    "Message": "Success",
    "Data": {}
}
त्रुटि प्रबंधनHTTP स्थिति कोड मानकीकृत तीन अंकों की संख्याएँ हैं जो एक सर्वर द्वारा क्लाइंट के अनुरोध के परिणाम को दर्शाने के लिए लौटाई जाती हैं। ये यह जानकारी प्रदान करते हैं कि क्या अनुरोध को सफलतापूर्वक संसाधित किया गया, क्या आगे की कार्रवाई की आवश्यकता है, या क्या कोई त्रुटि हुई है। इन कोडों को पाँच श्रेणियों में विभाजित किया गया है, प्रत्येक एक विशिष्ट प्रकार की प्रतिक्रिया का प्रतिनिधित्व करती है।हमारे API के स्थिति कोड HTTP/1.1 प्रोटोकॉल का पालन करते हैं, जो एक व्यापक रूप से स्वीकृत मानक है जो लगातार और विश्वसनीय संचार सुनिश्चित करता है। HTTP/1.1 का उपयोग करके, हम स्थायी कनेक्शनों और उन्नत कैशिंग जैसी सुविधाओं का लाभ उठाते हैं ताकि क्लाइंट-सर्वर इंटरैक्शन को अनुकूलित किया जा सके।
2xx (सफल): यह दर्शाता है कि आदेश प्राप्त हुआ और स्वीकार किया गया।
200स्थिति कोड यह दर्शाता है कि अनुरोध सफल रहा है।
201स्थिति कोड यह दर्शाता है कि अनुरोध को पूरा कर लिया गया है और इसके परिणामस्वरूप एक या एक से अधिक नए संसाधनों का निर्माण हुआ है।
202स्थिति कोड यह दर्शाता है कि अनुरोध को संसाधित करने के लिए स्वीकार कर लिया गया है, लेकिन संसाधन प्रक्रिया पूरी नहीं हुई है।
4xx (क्लाइंट त्रुटि): यह संकेत करता है कि क्लाइंट ने अनुरोध में एक त्रुटि की है, जैसे कि अमान्य इनपुट प्रदान करना या उचित प्राधिकरण की कमी होना।
400स्थिति कोड यह दर्शाता है कि सर्वर अनुरोध को संसाधित नहीं कर सकता या नहीं करेगा क्योंकि इसे क्लाइंट त्रुटि के रूप में देखा जाता है।
401स्थिति कोड यह दर्शाता है कि अनुरोध लागू नहीं किया गया है क्योंकि इसमें लक्षित संसाधन के लिए मान्य प्रमाणीकरण क्रेडेंशियल्स की कमी है।
402स्थिति कोड यह दर्शाता है कि भुगतान समस्या के कारण अनुरोध लागू नहीं किया गया है।
403स्थिति कोड यह दर्शाता है कि सर्वर ने अनुरोध को समझ लिया है लेकिन इसे पूरा करने से इनकार कर रहा है।
404स्थिति कोड यह दर्शाता है कि मूल सर्वर ने लक्षित संसाधन के लिए वर्तमान प्रतिनिधित्व नहीं पाया या यह बताने के लिए तैयार नहीं है कि ऐसा कोई प्रतिनिधित्व मौजूद है।
409अनुरोध को संसाधन की वर्तमान स्थिति के साथ संघर्ष के कारण पूरा नहीं किया जा सका।
429उपयोगकर्ता ने दिए गए समय में बहुत अधिक अनुरोध भेजे हैं।
5xx (सर्वर त्रुटि): यह दर्शाता है कि सर्वर को एक त्रुटि का सामना करना पड़ा है या यह अनुरोध को पूरा करने में असमर्थ है।
500स्थिति कोड यह दर्शाता है कि सर्वर को एक अप्रत्याशित स्थिति का सामना करना पड़ा, जिसने उसे अनुरोध को पूरा करने से रोक दिया।
501स्थिति कोड यह दर्शाता है कि सर्वर उस कार्यक्षमता का समर्थन नहीं करता है जो अनुरोध को पूरा करने के लिए आवश्यक है।
502स्थिति कोड यह दर्शाता है कि सर्वर, जो एक गेटवे या प्रॉक्सी के रूप में कार्य कर रहा है, ने एक इनबाउंड सर्वर से एक अमान्य प्रतिक्रिया प्राप्त की, जिसे उसने अनुरोध को पूरा करने का प्रयास करते समय एक्सेस किया।
503स्थिति कोड यह दर्शाता है कि सर्वर वर्तमान में अस्थायी ओवरलोड या निर्धारित रखरखाव के कारण अनुरोध को संभालने में असमर्थ है, जो संभवतः कुछ देरी के बाद हल हो जाएगा।
504स्थिति कोड यह दर्शाता है कि सर्वर, जो एक गेटवे या प्रॉक्सी के रूप में कार्य कर रहा था, को उस अपस्ट्रीम सर्वर से समय पर प्रतिक्रिया नहीं मिली, जिसे उसे अनुरोध को पूरा करने के लिए एक्सेस करने की आवश्यकता थी।
कोडस्थिति का नाम
200सफलता
201निर्मित
202स्वीकृत
400खराब अनुरोध
401अनधिकृत
402भुगतान आवश्यक है
403निषिद्ध
404नहीं मिला
409संघर्ष
429बहुत सारे अनुरोध
500आंतरिक सर्वर त्रुटि
501नहीं लागू किया गया
502खराब गेटवे
503सेवा उपलब्ध नहीं है
504गेटवे टाइमआउट
वेबहुक अवलोकन
वेबहुक प्रक्रियाओं को स्वचालित करने और सिस्टम को एकीकृत करने के लिए एक शक्तिशाली उपकरण हैं। वे आपको अपने खाते या डोमेन सेटिंग्स में घटनाओं या परिवर्तनों के बारे में रीयल-टाइम सूचनाएं प्राप्त करने की अनुमति देते हैं। वेबहुक को कॉन्फ़िगर करके, आप बाहरी सिस्टम में कार्रवाइयों को ट्रिगर कर सकते हैं, डेटाबेस अपडेट कर सकते हैं, या विशिष्ट घटनाओं के आधार पर सूचनाएं भेज सकते हैं।Dynadot API विभिन्न घटनाओं के लिए वेबहुक सूचनाओं का समर्थन करता है, जैसे डोमेन पंजीकरण, स्थानांतरण, नवीनीकरण और समाप्ति, ताकि आप उचित कार्रवाई कर सकें।वेबहुक का उपयोग करने के लिए, आपको एक URL एंडपॉइंट प्रदान करना होगा जहाँ सूचनाएँ भेजी जाएँगी। आप अपने खाता सेटिंग्स में अपना वेबहुक URL, कुंजी और गुप्त कोड कॉन्फ़िगर कर सकते हैं। जब कोई घटना होती है, तो Dynadot संबंधित डेटा के साथ निर्दिष्ट URL पर एक POST अनुरोध भेजेगा।
वेबहुक अनुरोध हेडरएक वेबहुक अनुरोध के हेडर में अनुरोध के बारे में मेटाडेटा होता है। यह मेटाडेटा सर्वर को अनुरोध को ठीक से संसाधित करने के लिए आवश्यक संदर्भ प्रदान करता है। आमतौर पर उपयोग किए जाने वाले हेडर में शामिल हैं:
Content-Typeयह अनुरोध के शरीर में भेजे जा रहे डेटा के प्रारूप को निर्दिष्ट करता है। सर्वर इस जानकारी का उपयोग अनुरोध को सही ढंग से पार्स करने के लिए करता है। वर्तमान में केवल एक स्वीकार्य मान है: application/json
Example :
Content-Type: application/json
अधिकारितासभी वेबहुक अनुरोधों में प्रमाणीकरण के लिए एक वेबहुक कुंजी शामिल होगी। आप अपनी वेबहुक कुंजी अपने खाता डैशबोर्ड से प्राप्त कर सकते हैं।You can manage your WEBHOOK_KEY in the API settings page
प्रमाणीकरण हेडर उदाहरण :
Authorization: Bearer WEBHOOK_KEY
X-SignatureX-Signature हेडर लेनदेन संबंधी अनुरोधों के लिए एक अनिवार्य सुरक्षा तंत्र है, जिसमें संवेदनशील जानकारी प्राप्त करने या डेटा अपडेट करने वाले अनुरोध शामिल हैं। यह HMAC-SHA256 का उपयोग करके क्लाइंट्स को अनुरोध पेलोड पर हस्ताक्षर करने की आवश्यकता से वेबहुक अनुरोधों की प्रामाणिकता, अखंडता और गैर-अस्वीकृति सुनिश्चित करता है।
हस्ताक्षर उत्पन्न करने के लिए, आपको निम्नलिखित मानों की आवश्यकता होगी1. WEBHOOK Key: आपकी अद्वितीय WEBHOOK कुंजी।2. पूरा पथ और क्वेरी: वेबहुक एंडपॉइंट का पूरा पथ और क्वेरी पैरामीटर्स के साथ।3. X-Request-Id: अनुरोध आईडी। यदि यह उपलब्ध नहीं है, तो आप खाली स्ट्रिंग दर्ज कर सकते हैं।4. अनुरोध का शरीर: अनुरोध का शरीर। यदि यह खाली या शून्य है, तो आप खाली स्ट्रिंग दर्ज कर सकते हैं।
साइन करने के लिए स्ट्रिंग उपरोक्त उल्लेखित मानों का एक संयोजन है, जिसे निम्नलिखित क्रम में जोड़ा गया है:
webhookKey + "\n" + fullPathAndQuery + "\n" + (xRequestId or empty String) + "\n" + (requestBody or empty String)
Example
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 बनाने के बाद, हस्ताक्षर की गणना करें HMAC-SHA256 का उपयोग करके अपने secret को कुंजी के रूप में, फिर परिणाम को Base64-encode करें।हस्ताक्षर निम्नलिखित चरणों का उपयोग करके उत्पन्न किया जाता है:HMAC-SHA256 एल्गोरिदम का उपयोग करें।2. stringToSign (UTF-8) को इनपुट संदेश के रूप में उपयोग करें।3. अपने secret (UTF-8) को कुंजी के रूप में उपयोग करें।4. HMAC आउटपुट को Base64 (मानक Base64) में एनकोड करें
हस्ताक्षर को अनुरोध हेडर में X-Signature के मान के रूप में लागू करें।
Example :
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)
वेबहुक अनुरोध प्रारूप
Content Formatएक वेबहुक अनुरोध के बॉडी में उस घटना के बारे में जानकारी होती है जिसने सूचना को ट्रिगर किया है। बॉडी डेटा का प्रारूप Content-Type हेडर द्वारा निर्धारित किया जाता है, जो आमतौर पर application/json होता है।अनुरोध के शरीर में निम्नलिखित पैरामीटर शामिल हैं:उदाहरण:
JSON/XML
{
  "event": "domain_registration",
  "event_id": 12345,
  "timestamp": 1700000000000,
  "data": {
    "DomainName": "example.com",
    "RegistrationDate": "2022-01-01",
    "ExpirationDate": "2023-01-01",
    "Registrant": {
      "Name": "JohnDoe",
      "Email": "john@dynadot.com",
      "Phone": "+1.1234567890"
    }
  }
}
पैरामीटर्सअनुरोध के बॉडी में निम्नलिखित पैरामीटर होते हैं:
ParameterDescription
eventThe type of event that triggered the notification.
event_idThe id of the event that triggered the notification.
timestampThe timestamp when the event occurred.
dataThe data associated with the event.
वेबहुक प्रतिक्रिया प्रारूप
Content Formatवेबहुक अनुरोध की प्रतिक्रिया JSON प्रारूप में भेजी जाएगी, अनुरोध में निर्दिष्ट Content-Type हेडर के आधार पर।प्रतिक्रिया बॉडी में अनुरोध की स्थिति के बारे में जानकारी होती है, जैसे कि क्या इसे सफलतापूर्वक संसाधित किया गया था या कोई त्रुटि आई थी।सामान्यतः प्रतिक्रिया में 1 भाग होता है: स्थितिउदाहरण:
JSON/XML
{
    "Status": "200"
}
रेट लिमिटिंगअनुरोधों को सुरक्षा के लिए https (सुरक्षित सॉकेट) के माध्यम से भेजा जाना चाहिए। एक समय में केवल 1 अनुरोध को ही संसाधित किया जा सकता है, इसलिए कृपया एक और अनुरोध भेजने से पहले अपने वर्तमान अनुरोध के समाप्त होने का इंतजार करें।
आपको अपने खाते के मूल्य स्तर के आधार पर विभिन्न थ्रेड काउंट प्राप्त होंगे:
Price levelThread CountRate Limit
Regular1 thread60/min (1/sec)
Bulk5 threads600/min (10/sec)
Super Bulk35 threads6000/min (100/sec)
नोट: place_auction_bid & get_auction_bid वर्तमान में उपरोक्त दर सीमा से छूट प्राप्त हैं।
Example :
<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."
  }
}
डोमेन मूल्यांकन कमांड के लिए, आपको आपके खाते की कीमत स्तर के आधार पर अलग-अलग अनुमत अनुरोध गणना प्राप्त होगी:
Price levelRate Limit
Regular50/day
Bulk100/day
Super Bulk300/day
Example :
<Response>
	<status>
		<code>429</code>
		<message>Too Many Requests</message>
	</status>
	<error>
		<description>Daily quota for the command has been reached. Please try again tomorrow.</description>
	</error>
</Response>
{
	"code": 429,
	"message": "Too Many Requests",
	"error": {
		"description": "Daily quota for the command has been reached. Please try again tomorrow."
	}
}
SandboxDynadot API सैंडबॉक्स वातावरण आपको अपने लाइव खाते या वास्तविक धन को प्रभावित किए बिना अपने API एकीकरणों को सुरक्षित रूप से परीक्षण करने की अनुमति देता है।
सैंडबॉक्स तक कैसे पहुंचें
1. अपने Dynadot खाते में लॉग इन करें और API सेटिंग्स पेज पर नेविगेट करें:2. https://www.dynadot.com/account/domain/setting/api.html3. अपनी API सैंडबॉक्स कुंजी और API सैंडबॉक्स सीक्रेट कुंजी जनरेट करें।4. जनरेट होने के बाद, कृपया सिस्टम को आपके सैंडबॉक्स कुंजियों को सक्रिय करने और आपका सैंडबॉक्स खाता बनाने के लिए कुछ समय दें।5. परीक्षण उद्देश्यों के लिए, आपके सैंडबॉक्स खाते में सभी समर्थित मुद्राओं में 10,000 का बैलेंस पूर्व-निधि किया जाएगा।
सैंडबॉक्स एपीआई का उपयोग करनासैंडबॉक्स वातावरण में API कमांड कार्यात्मक रूप से प्रोडक्शन वातावरण के समान हैं।The only difference is the base URL:
प्रोडक्शन API URL:https://api.dynadot.comसैंडबॉक्स API URL:https://api-sandbox.dynadot.com
महत्वपूर्ण नोट्स
सैंडबॉक्स वातावरण में कुछ API कमांड उपलब्ध नहीं हो सकते हैं। कृपया विशिष्ट कमांड दस्तावेज़ीकरण देखें "Support API Sandbox" लेबल की जाँच के लिए।सैंडबॉक्स मुख्य रूप से परीक्षण के लिए डिज़ाइन किया गया है। कुछ कमांड प्रोडक्शन से भिन्न हो सकते हैं, और सैंडबॉक्स प्रोडक्शन वातावरण में पाए जाने वाले सभी संभावित जटिल परिदृश्यों का पूरी तरह से अनुकरण नहीं कर सकता
परिवर्तन लॉग अवलोकन
एक परिवर्तन लॉग प्रत्येक संस्करण में किए गए परिवर्तनों, सुधारों, बग फिक्स और नए फीचर्स का विस्तृत रिकॉर्ड है। यह उपयोगकर्ताओं और डेवलपर्स के लिए पारदर्शिता प्रदान करता है, प्रत्येक अपडेट के प्रभाव को दस्तावेजित करके। यह दो मुख्य भागों से मिलकर बना है:
API संस्करणयह भाग API के संस्करण प्रणाली को उजागर करता है, जो डेवलपर्स को सुविधाओं के विकास को ट्रैक करने और संगतता सुनिश्चित करने में मदद करता है। प्रत्येक API संस्करण को एक अद्वितीय संस्करण संख्या (जैसे, v1.0.1, v2.2.3) द्वारा पहचाना जाता है और यह एक महत्वपूर्ण मील का पत्थर या रिलीज का प्रतिनिधित्व करता है। संस्करणन उपयोगकर्ताओं को न्यूनतम व्यवधान के साथ एकीकरण बनाए रखने की अनुमति देता है, जिससे वे तैयार होने पर अपडेट में शामिल हो सकते हैं।
परिवर्तन लॉग इतिहासचेंज लॉग इतिहास प्रत्येक संस्करण में किए गए अपडेट, बग फिक्स, डिप्रिकेशन और सुधारों के बारे में विस्तृत जानकारी प्रदान करता है। यह एंडपॉइंट्स, पैरामीटर्स, ऑथेंटिकेशन मैकेनिज्म, या रिस्पॉन्स फॉर्मेट में किए गए विशिष्ट परिवर्तनों को रेखांकित करता है। यह अनुभाग सुनिश्चित करता है कि डेवलपर्स को यह पूरी पारदर्शिता मिले कि क्या बदला है और वे अपनी कार्यान्वयन को तदनुसार समायोजित कर सकें। एक स्पष्ट और विस्तृत चेंज लॉग बनाए रखकर, हमारा उद्देश्य डेवलपर्स को प्रभावी और आत्मविश्वास के साथ इंटीग्रेशन प्रबंधित करने के लिए आवश्यक उपकरण और जानकारी प्रदान करना है।
API संस्करण
हमारा API वर्तमान में संस्करण में हैv2.0.0
संस्करण कोड का उपयोग API अपडेट को व्यवस्थित रूप से पहचानने और प्रबंधित करने के लिए किया जाता है। ये सेमांटिक वर्जनिंग (SemVer) प्रारूप का पालन करते हैं:
<Major><Minor><Patch>
संस्करण कोड के प्रत्येक घटक का एक विशिष्ट उद्देश्य होता है और यह डेवलपर्स को परिवर्तनों के दायरे और प्रकार को प्रभावी ढंग से संप्रेषित करने में मदद करता है।
मुख्य संस्करणपरिभाषा: महत्वपूर्ण परिवर्तनों का प्रतिनिधित्व करता है जो पिछले संस्करणों के साथ संगतता को तोड़ सकते हैं।Format:<Major>.x.x
उदाहरण:v1.0.0->v2.0.0एक पूर्ण API पुनः डिज़ाइन या असंगत स्कीमा परिवर्तन।
माइनर वर्जनपरिभाषा: पिछड़े-संगत विशेषताओं के जोड़ को दर्शाता है।Format:x.<Minor>.x
उदाहरण:v1.0.0->v1.1.0नए एंडपॉइंट या विधियों को जोड़ना जबकि पिछली संगतता बनाए रखना।
पैच संस्करणपरिभाषा: पिछले संस्करणों के साथ संगत बग फिक्स या छोटे सुधारों को संदर्भित करता है।Format:x.x.<Patch>
उदाहरण:v1.0.0->v1.1.0एक API एंडपॉइंट में एक छोटे बग को ठीक करना।
API परिवर्तन लॉग
एक चेंज लॉग एक विस्तृत रिकॉर्ड है जिसमें सॉफ़्टवेयर या API के प्रत्येक संस्करण में किए गए परिवर्तनों, सुधारों, बग फिक्स और नए फीचर्स का विवरण होता है। यह प्रत्येक अपडेट के प्रभाव को दस्तावेज़ित करके उपयोगकर्ताओं और डेवलपर्स के लिए पारदर्शिता प्रदान करता है।
एक सामान्य परिवर्तन लॉग में निम्नलिखित शामिल होता है:विवरण: जो कुछ भी बदला गया है उसका संक्षिप्त विवरण।प्रभावित घटक: परिवर्तन से प्रभावित विशिष्ट मॉड्यूल, एंडपॉइंट, या सुविधाएँ।
उदाहरण: इस नए API कमांड के लिए समर्थन जोड़ा गया<Domain Register>
परिवर्तन लॉग इतिहासDynadot API में हर बदलाव पर नज़र रखें।
October 9, 2025
v2.0.0New Features & Key Changes • Sandbox Environment Now Live ◦ The Sandbox environment is officially launched and available for safe testing and integration validation. • Mandatory X-Signature Header for Sensitive Operations ◦ To enhance security, the X-Signature header is now enforced for all sensitive API commands. • (Optional) Machine-Readable API Documentation ◦ We now support structured, machine-readable API documentation for easier integration with automated tools. • Search Access Restricted ◦ Access to certain search-related endpoints has been restricted for performance and data control reasons. • IP whitelisting optimized ◦ Reseller account no longer required to enter at least 1 IP to use API(RESTful API only) API Documentation Improvements • Updated version selector on the documentation landing page for easier navigation • Unified casing conventions across parameter names • Expanded documentation and usage guidance for the bulk_search endpoint • Added feature to hide/show side navigation
Introduced mandatory paging parameters to improve response efficiency and consistency. ◦ page (integer, required) – Specifies the current page index, starting from 1. ◦ page_size (integer, required) – Defines the number of items returned per page.get_listings
ऑनलाइन चैट करें