प्रमाणीकरण

की कहाँ डालें

की को form-encoded रिक्वेस्ट बॉडी में key फ़ील्ड के रूप में पास करें। हेडर-आधारित auth सपोर्टेड नहीं है — v2 स्पेक मौजूदा reseller SDK के साथ कम्पैटिबिलिटी के लिए बॉडी पैरामीटर का इस्तेमाल करता है।

Content-Type: application/x-www-form-urlencoded

key=YOUR_API_KEY&action=services

कुंजियां बनाना और बदलना

कुंजियां /dashboard/api से बनाई और निरस्त की जाती हैं। raw कुंजी ठीक एक बार दिखाई जाती है। सर्वर एकतरफ़ा verifier और छोटा गैर-गोपनीय identifier रखता है, इसलिए raw वैल्यू बाद में वापस नहीं पाई जा सकती।

• प्रति अकाउंट अधिकतम 5 सक्रिय की। पुरानी की अलग-अलग रिवोक की जा सकती हैं।
• बिना डाउनटाइम बदलें। एक replacement कुंजी बनाएं, अपना integration अपडेट करें, फिर पुरानी कुंजी निरस्त करें। नई requests में निरस्त कुंजियां अस्वीकार होती हैं।
• सक्रिय dashboard session आवश्यक है। निर्माण के लिए authenticated, गैर-impersonated dashboard session चाहिए। यह अलग email-code या password prompt नहीं जोड़ता।

एक API की क्या कर सकती है

v3 API कुंजी केवल दस्तावेज़ में दिए गए कार्यों तक सीमित है और लॉग इन किए गए डैशबोर्ड सत्र या दूसरे खाते के डेटा तक पहुँच नहीं दे सकती।

• बैलेंस निकालना या ट्रांसफ़र करना।
• अकाउंट का ईमेल, पासवर्ड, या 2FA सेटिंग्स बदलना।
• API के ज़रिए अन्य API कुंजियां बनाना या निरस्त करना।
• admin या मॉडरेशन एंडपॉइंट तक पहुँचना।

सुरक्षा सुझाव

• केवल सर्वर-साइड। API की को कभी भी किसी browser बंडल, मोबाइल ऐप, या ऐसे किसी क्लाइंट में एम्बेड न करें जिसे कोई दूसरा पक्ष डीकम्पाइल कर सके।
• एनवायरनमेंट वेरिएबल इस्तेमाल करें। की को git में कमिट न करें। .env फ़ाइलें .gitignore में होनी चाहिए।
• शक होने पर निरस्त करें। अगर कोई कुंजी log, screenshot या shared chat में उजागर हो जाए, तो replacement बनाएं और उजागर कुंजी निरस्त करें।
• Polling घटाने के लिए webhooks इस्तेमाल करें जहाँ उपयोगी हो। Delivery retries के साथ best-effort है, इसलिए handlers को idempotent रखें और महत्वपूर्ण state को action=status से reconcile करें।