डाइनाडॉट एपीआई
हमारे 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/v1/domains/{domain_name}/search
संस्करण
API का वर्तमान संस्करण हैv1.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-SignatureX-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 = "/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\"}"
HMAC-SHA256 सिग्नेचर उत्पन्न करेंसाइन करने के लिए स्ट्रिंग बनाने के बाद, आपको अपने गुप्त कुंजी का उपयोग करके HMAC-SHA256 एन्क्रिप्शन लागू करना होगा। यह प्रक्रिया सिग्नेचर बनाएगी।हस्ताक्षर निम्नलिखित चरणों का उपयोग करके उत्पन्न किया जाता है:HMAC-SHA256 एल्गोरिदम का उपयोग करें।Sure! Please provide the text you would like me to translate into Hindi.3. रहस्य का उपयोग कुंजी के रूप में करें।
हस्ताक्षर को अनुरोध हेडर में X-Signature के मान के रूप में लागू करें।
Example :
X-Signature: {HMAC-SHA256 Signature}
BodyAPI अनुरोध का शरीर सर्वर को डेटा भेजने के लिए उपयोग किया जाता है। यह आमतौर पर POST, PUT, या PATCH अनुरोधों में शामिल होता है (GET या DELETE अनुरोधों के लिए सामान्यतः नहीं)।
Sure! Please provide the text you would like me to translate into Hindi.शरीर डेटा का प्रारूप Content-Type हेडर द्वारा निर्धारित किया जाता है। कुछ सामान्य प्रारूपों में शामिल हैं:
JSON
{
    "domainName": "domain.com",
    "showPrice": "yes",
    "currency": "USD"
}
सामान्य उपयोग के मामलेPOST अनुरोध: POST विधि का उपयोग सर्वर पर एक नया संसाधन बनाने के लिए किया जाता है। अनुरोध का शरीर आमतौर पर संसाधन विवरणों को शामिल करता है।PUT अनुरोध: PUT विधि का उपयोग एक मौजूदा संसाधन को पूरी तरह से बदलकर अपडेट करने के लिए किया जाता है। अनुरोध का शरीर पूर्ण अपडेटेड संसाधन को शामिल करता है।GET अनुरोध: DELETE विधि का उपयोग सर्वर से एक मौजूदा संसाधन को हटाने के लिए किया जाता है। इसमें कोई अनुरोध शरीर नहीं होताDELETE अनुरोध: GET विधि का उपयोग सर्वर से एक मौजूदा संसाधन को प्राप्त करने के लिए किया जाता है। इसमें कोई अनुरोध शरीर नहीं होता
Response Formatसभी API प्रतिक्रियाएँ JSON या XML प्रारूप में लौटाई जाती हैं, जिसमें शरीर के डेटा का प्रारूप Accept हेडर द्वारा निर्धारित किया जाता है, जो अनुरोधित डेटा या एक त्रुटि संदेश प्रदान करता है, यदि लागू हो।
Sure! Please provide the text you would like me to translate into Hindi.The response in general contains 3 parts: कोड, संदेश, डेटा
कोड: अनुरोध की स्थितिसंदेश: स्थिति का अधिक विवरणडेटा: प्रतिक्रिया का मुख्य भाग
Sure! Here’s the translation of "JSON/XML" into Hindi: "JSON/XML"
{
    "Code": "200",
    "Message": "Success",
    "Data": {}
}
त्रुटि प्रबंधनHTTP स्थिति कोड मानकीकृत तीन अंकों की संख्याएँ हैं जो एक सर्वर द्वारा क्लाइंट के अनुरोध के परिणाम को दर्शाने के लिए लौटाई जाती हैं। ये यह जानकारी प्रदान करते हैं कि क्या अनुरोध को सफलतापूर्वक संसाधित किया गया, क्या आगे की कार्रवाई की आवश्यकता है, या क्या कोई त्रुटि हुई है। इन कोडों को पाँच श्रेणियों में विभाजित किया गया है, प्रत्येक एक विशिष्ट प्रकार की प्रतिक्रिया का प्रतिनिधित्व करती है।हमारे API के स्थिति कोड HTTP/1.1 प्रोटोकॉल का पालन करते हैं, जो एक व्यापक रूप से स्वीकृत मानक है जो लगातार और विश्वसनीय संचार सुनिश्चित करता है। HTTP/1.1 का उपयोग करके, हम स्थायी कनेक्शनों और उन्नत कैशिंग जैसी सुविधाओं का लाभ उठाते हैं ताकि क्लाइंट-सर्वर इंटरैक्शन को अनुकूलित किया जा सके।
2xx (सफल): यह दर्शाता है कि आदेश प्राप्त हुआ और स्वीकार किया गया।
200स्थिति कोड यह दर्शाता है कि अनुरोध सफल रहा है।
201स्थिति कोड यह दर्शाता है कि अनुरोध को पूरा कर लिया गया है और इसके परिणामस्वरूप एक या एक से अधिक नए संसाधनों का निर्माण हुआ है।
202स्थिति कोड यह दर्शाता है कि अनुरोध को संसाधित करने के लिए स्वीकार कर लिया गया है, लेकिन संसाधन प्रक्रिया पूरी नहीं हुई है।
249उपयोगकर्ता ने दिए गए समय में बहुत अधिक अनुरोध भेजे हैं।
4xx (क्लाइंट त्रुटि): यह संकेत करता है कि क्लाइंट ने अनुरोध में एक त्रुटि की है, जैसे कि अमान्य इनपुट प्रदान करना या उचित प्राधिकरण की कमी होना।
400स्थिति कोड यह दर्शाता है कि सर्वर अनुरोध को संसाधित नहीं कर सकता या नहीं करेगा क्योंकि इसे क्लाइंट त्रुटि के रूप में देखा जाता है।
401स्थिति कोड यह दर्शाता है कि अनुरोध लागू नहीं किया गया है क्योंकि इसमें लक्षित संसाधन के लिए मान्य प्रमाणीकरण क्रेडेंशियल्स की कमी है।
402स्थिति कोड यह दर्शाता है कि भुगतान समस्या के कारण अनुरोध लागू नहीं किया गया है।
403स्थिति कोड यह दर्शाता है कि सर्वर ने अनुरोध को समझ लिया है लेकिन इसे पूरा करने से इनकार कर रहा है।
404स्थिति कोड यह दर्शाता है कि मूल सर्वर ने लक्षित संसाधन के लिए वर्तमान प्रतिनिधित्व नहीं पाया या यह बताने के लिए तैयार नहीं है कि ऐसा कोई प्रतिनिधित्व मौजूद है।
409अनुरोध को संसाधन की वर्तमान स्थिति के साथ संघर्ष के कारण पूरा नहीं किया जा सका।
5xx (सर्वर त्रुटि): यह दर्शाता है कि सर्वर को एक त्रुटि का सामना करना पड़ा है या यह अनुरोध को पूरा करने में असमर्थ है।
500स्थिति कोड यह दर्शाता है कि सर्वर को एक अप्रत्याशित स्थिति का सामना करना पड़ा, जिसने उसे अनुरोध को पूरा करने से रोक दिया।
501स्थिति कोड यह दर्शाता है कि सर्वर उस कार्यक्षमता का समर्थन नहीं करता है जो अनुरोध को पूरा करने के लिए आवश्यक है।
502स्थिति कोड यह दर्शाता है कि सर्वर, जो एक गेटवे या प्रॉक्सी के रूप में कार्य कर रहा है, ने एक इनबाउंड सर्वर से एक अमान्य प्रतिक्रिया प्राप्त की, जिसे उसने अनुरोध को पूरा करने का प्रयास करते समय एक्सेस किया।
503स्थिति कोड यह दर्शाता है कि सर्वर वर्तमान में अस्थायी ओवरलोड या निर्धारित रखरखाव के कारण अनुरोध को संभालने में असमर्थ है, जो संभवतः कुछ देरी के बाद हल हो जाएगा।
504स्थिति कोड यह दर्शाता है कि सर्वर, जो एक गेटवे या प्रॉक्सी के रूप में कार्य कर रहा था, को उस अपस्ट्रीम सर्वर से समय पर प्रतिक्रिया नहीं मिली, जिसे उसे अनुरोध को पूरा करने के लिए एक्सेस करने की आवश्यकता थी।
कोडस्थिति का नाम
200सफलता
201निर्मित
202स्वीकृत
249बहुत सारे अनुरोध
400खराब अनुरोध
401अनधिकृत
402भुगतान आवश्यक है
403निषिद्ध
404नहीं मिला
409संघर्ष
500आंतरिक सर्वर त्रुटि
501नहीं लागू किया गया
502खराब गेटवे
503सेवा उपलब्ध नहीं है
504गेटवे टाइमआउट
रेट लिमिटिंगअनुरोधों को सुरक्षा के लिए https (सुरक्षित सॉकेट) के माध्यम से भेजा जाना चाहिए। एक समय में केवल 1 अनुरोध को ही संसाधित किया जा सकता है, इसलिए कृपया एक और अनुरोध भेजने से पहले अपने वर्तमान अनुरोध के समाप्त होने का इंतजार करें।
आपको अपने खाते के मूल्य स्तर के आधार पर विभिन्न थ्रेड काउंट प्राप्त होंगे:
Price levelThread CountRate Limit
Regular1 thread60/min (1/sec)
Bulk5 threads600/min (10/sec)
Super Bulk25 threads6000/min (100/sec)
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."
  }
}
परिवर्तन लॉग अवलोकन
एक परिवर्तन लॉग प्रत्येक संस्करण में किए गए परिवर्तनों, सुधारों, बग फिक्स और नए फीचर्स का विस्तृत रिकॉर्ड है। यह उपयोगकर्ताओं और डेवलपर्स के लिए पारदर्शिता प्रदान करता है, प्रत्येक अपडेट के प्रभाव को दस्तावेजित करके। यह दो मुख्य भागों से मिलकर बना है:
API संस्करणयह भाग API के संस्करण प्रणाली को उजागर करता है, जो डेवलपर्स को सुविधाओं के विकास को ट्रैक करने और संगतता सुनिश्चित करने में मदद करता है। प्रत्येक API संस्करण को एक अद्वितीय संस्करण संख्या (जैसे, v1.0.1, v2.2.3) द्वारा पहचाना जाता है और यह एक महत्वपूर्ण मील का पत्थर या रिलीज का प्रतिनिधित्व करता है। संस्करणन उपयोगकर्ताओं को न्यूनतम व्यवधान के साथ एकीकरण बनाए रखने की अनुमति देता है, जिससे वे तैयार होने पर अपडेट में शामिल हो सकते हैं।
परिवर्तन लॉग इतिहासचेंज लॉग इतिहास प्रत्येक संस्करण में किए गए अपडेट, बग फिक्स, डिप्रिकेशन और सुधारों के बारे में विस्तृत जानकारी प्रदान करता है। यह एंडपॉइंट्स, पैरामीटर्स, ऑथेंटिकेशन मैकेनिज्म, या रिस्पॉन्स फॉर्मेट में किए गए विशिष्ट परिवर्तनों को रेखांकित करता है। यह अनुभाग सुनिश्चित करता है कि डेवलपर्स को यह पूरी पारदर्शिता मिले कि क्या बदला है और वे अपनी कार्यान्वयन को तदनुसार समायोजित कर सकें। एक स्पष्ट और विस्तृत चेंज लॉग बनाए रखकर, हमारा उद्देश्य डेवलपर्स को प्रभावी और आत्मविश्वास के साथ इंटीग्रेशन प्रबंधित करने के लिए आवश्यक उपकरण और जानकारी प्रदान करना है।
API संस्करण
हमारा API वर्तमान में संस्करण में हैv1.0.0
संस्करण कोड का उपयोग API अपडेट को व्यवस्थित रूप से पहचानने और प्रबंधित करने के लिए किया जाता है। ये सेमांटिक वर्जनिंग (SemVer) प्रारूप का पालन करते हैं:
Sure! Please provide the text you would like me to translate into Hindi.Sure! Please provide the text you would like me to translate into Hindi.Sure! Please provide the text you would like me to translate into Hindi.
संस्करण कोड के प्रत्येक घटक का एक विशिष्ट उद्देश्य होता है और यह डेवलपर्स को परिवर्तनों के दायरे और प्रकार को प्रभावी ढंग से संप्रेषित करने में मदद करता है।
मुख्य संस्करणपरिभाषा: महत्वपूर्ण परिवर्तनों का प्रतिनिधित्व करता है जो पिछले संस्करणों के साथ संगतता को तोड़ सकते हैं।Sure! Please provide the text you would like me to translate into Hindi.<Major>.x.x
उदाहरण:v1.0.0->v2.0.0एक पूर्ण API पुनः डिज़ाइन या असंगत स्कीमा परिवर्तन।
माइनर वर्जनपरिभाषा: पिछड़े-संगत विशेषताओं के जोड़ को दर्शाता है।Sure! Please provide the text you would like me to translate into Hindi.x.<Minor>.x
उदाहरण:v1.0.0->v1.1.0नए एंडपॉइंट या विधियों को जोड़ना जबकि पिछली संगतता बनाए रखना।
पैच संस्करणपरिभाषा: पिछले संस्करणों के साथ संगत बग फिक्स या छोटे सुधारों को संदर्भित करता है।Sure! Please provide the text you would like me to translate into Hindi.x.x.<Patch>
उदाहरण:v1.0.0->v1.1.0एक API एंडपॉइंट में एक छोटे बग को ठीक करना।
API परिवर्तन लॉग
एक चेंज लॉग एक विस्तृत रिकॉर्ड है जिसमें सॉफ़्टवेयर या API के प्रत्येक संस्करण में किए गए परिवर्तनों, सुधारों, बग फिक्स और नए फीचर्स का विवरण होता है। यह प्रत्येक अपडेट के प्रभाव को दस्तावेज़ित करके उपयोगकर्ताओं और डेवलपर्स के लिए पारदर्शिता प्रदान करता है।
एक सामान्य परिवर्तन लॉग में निम्नलिखित शामिल होता है:विवरण: जो कुछ भी बदला गया है उसका संक्षिप्त विवरण।प्रभावित घटक: परिवर्तन से प्रभावित विशिष्ट मॉड्यूल, एंडपॉइंट, या सुविधाएँ।
उदाहरण: इस नए API कमांड के लिए समर्थन जोड़ा गया<Domain Register>
परिवर्तन लॉग इतिहासDynadot API में हर बदलाव पर नज़र रखें।
March 15, 2025
v1.0.0The Dynadot API 1.0.0 introduces a RESTful interface designed for seamless integration with your systems.

It features predictable resource-oriented URLs, supports standard HTTP methods and authentication, and returns responses in both JSON and XML formats.

Each request processes a single object or action, as bulk updates are not supported.

This version focuses on core domain management, order processing, and related services.
Users can register, transfer, and renew domains, manage DNS settings, view or update account orders, as well as access functionalities for aftermarket, site builder, email hosting, and more.

To facilitate collaboration and support, we provide a dedicated Discord channel where users can discuss API usage, share feedback, and receive updates.
ऑनलाइन चैट करें