API Hop

दस्तावेज़

API Hop दस्तावेज़

सुरक्षा और कॉन्फ़िगरेशन

API कुंजी बनाना, अनुमति नियंत्रण, कुंजी बदलना और सुरक्षा अभ्यास।

API कुंजी की सुरक्षा के मुख्य सिद्धांत हैं: उजागर न करें, न्यूनतम अनुमति दें, नियमित बदलें और उपयोग का पता लगाने योग्य रिकॉर्ड रखें।

API कुंजियाँ कैसे सँभालूँ और सुरक्षित रखूँ?

सुझाए गए अभ्यास:

  • API कुंजियाँ सार्वजनिक रिपॉज़िटरी, फ़्रंटएंड पृष्ठ, मोबाइल पैकेज या स्क्रीनशॉट में न डालें।
  • सर्वर पर पर्यावरण चर या सीक्रेट मैनेजर से API कुंजियाँ पढ़ें।
  • विकास, परीक्षण और प्रोडक्शन के लिए अलग API कुंजियाँ बनाएँ।
  • पता लगाने और अलगाव को बेहतर करने के लिए अलग सेवा या ऐप की अलग कुंजी बनाएँ।
  • ज़रूरत के अनुसार मॉडल अनुमतियाँ तय करें और उचित हो तो समाप्ति तारीख दें।
  • API कुंजियाँ नियमित बदलें; कर्मचारी बदलाव, सेवा बंद होने या लीक के संदेह पर तुरंत बदलें।

API कुंजी लीक हुई हो सकती है तो:

  1. पुरानी कुंजी तुरंत बंद करें, हटाएँ या बदलें।
  2. नई कुंजी बनाएँ और सभी निर्भर सेवाएँ अपडेट करें।
  3. हाल का उपयोग, शेष राशि बदलाव और असामान्य खर्च देखें।
  4. मॉडल अनुमतियाँ सीमित करें और कम अवधि की समाप्ति पर विचार करें।
  5. लीक का मार्ग देखें, जैसे रिपॉज़िटरी, लॉग, CI कॉन्फ़िगरेशन या तीसरे पक्ष के क्लाइंट।

API कुंजी लीक से अनधिकृत कॉल और आर्थिक हानि हो सकती है। टेस्ट कुंजियाँ भी प्रोडक्शन गोपनीय जानकारी की तरह सुरक्षित रखें।

बनाने के बाद क्या पूरी API कुंजी फिर देख सकता हूँ?

नहीं। पूरी API कुंजी केवल सफल निर्माण प्रक्रिया में दिखाई जाती है। बाद में कंसोल केवल छिपाया हुआ पूर्वावलोकन दिखाता है।

निर्माण संवाद बंद करने से पहले कुंजी सर्वर-स्तरीय पर्यावरण चर या सीक्रेट मैनेजर में रखें। खोई कुंजी उपयोगकर्ता या व्यवस्थापक API से वापस नहीं मिल सकती। नई कुंजी बनाएँ, कॉल करने वाला ऐप अपडेट करें और फिर पुरानी कुंजी हटाएँ। Docs AI एकीकरण टेम्पलेट में <API_KEY> प्लेसहोल्डर है और वह पुरानी कुंजियाँ लोड नहीं करता।

API कुंजी कैसे भेजूँ?

API कुंजियाँ केवल अनुरोध हेडर में भेजें। हम सुझाते हैं:

http
Authorization: Bearer YOUR_API_KEY

यह भी इस्तेमाल कर सकते हैं:

http
X-API-Key: YOUR_API_KEY

API Hop API क्रेडेंशियल कभी URL क्वेरी में न डालें। क्रेडेंशियल जैसे नाम (apiKey, api_key, apikey, x-api-key और key) सामान्यतः HTTP 400 देते हैं। सीमित Similarweb व्यावसायिक-पैरामीटर अपवाद केवल GET अनुरोधों पर लागू हैं: /v1/similarweb/websites/backlinks एक बड़े अक्षर वाला Key होस्टनाम स्वीकार करता है; /v1/similarweb/websites/outgoing-traffic, /websites/incoming-referrals और /websites/similar-sites/suggestions एक छोटे अक्षर वाला key होस्टनाम स्वीकार करते हैं (सभी /v1/similarweb के अंतर्गत)। ये फ़ील्ड लक्ष्य वेबसाइट बताते हैं, API क्रेडेंशियल नहीं। होस्टनाम वैध होना चाहिए। दोहराव, गलत अक्षर-केस, क्रेडेंशियल जैसे मान और अतिरिक्त क्रेडेंशियल क्वेरी फ़ील्ड अब भी रोके जाते हैं। Similarweb रूट सहित हमेशा अनुरोध हेडर से प्रमाणीकरण करें। Similarweb अनुरोध उदाहरण देखें।

यह नियम OAuth token, apiKeyId, username या pagination_token जैसे दूसरे व्यावसायिक पैरामीटर प्रभावित नहीं करता।