API कुंजी प्रबंधन

/api-keys पर API Keys पृष्ठ, /api/v1/ के अंतर्गत REST API की कुंजियाँ संभालता है। कुंजी बनाने और इस API का उपयोग करने के लिए Enterprise या Manufacturer योजना तथा active या trialing सदस्यता स्थिति आवश्यक है। Free और Professional में REST पहुँच शामिल नहीं है।

अपनी कुंजियाँ संभालने के लिए साइन इन करें। योजना घटाने या सदस्यता रद्द करने के बाद भी मौजूदा कुंजियाँ सूचीबद्ध, निरस्त और हटाई जा सकती हैं; यह सुरक्षा पहुँच नई कुंजी बनाने या REST उपयोग का अधिकार वापस नहीं देती। Active दिखाई देने वाली कुंजी से यह सिद्ध नहीं होता कि मालिक की सदस्यता अभी पात्र है।

इस पृष्ठ पर अनुमति या समाप्ति-तिथि चुनने, नाम बदलने या दर-सीमा संपादित करने के नियंत्रण नहीं हैं। वर्तमान फ़ॉर्म calc:read और projects:read भेजता है तथा समाप्ति तय नहीं करता। अनुमति के नाम से एंडपॉइंट का अनुमान न लगाएँ: मौजूदा REST राउटर में गणना, रेफ्रिजरेंट और health रूट हैं, प्रोजेक्ट पढ़ने के रूट नहीं। पृष्ठ wildcard अनुमति का विकल्प नहीं देता।

प्रति खाते अधिकतम दस संग्रहीत कुंजी रिकॉर्ड हो सकते हैं, जिनमें निरस्त रिकॉर्ड भी शामिल हैं; यह दस सक्रिय कुंजियों की सीमा नहीं है। निरस्त करने से रिकॉर्ड बचता है और जगह खाली नहीं होती; पृष्ठ से निरस्त रिकॉर्ड हटाने पर होती है। दस रिकॉर्ड, लोडिंग, सूची त्रुटि या अपात्र योजना की स्थिति में New Key निष्क्रिय रहता है।

1. साइन इन करके API Keys खोलें। सूची लोड होने दें; लोडिंग त्रुटि हो तो कुंजी बनाने से पहले उसे ठीक करें।
2. New Key या खाली सूची में Create Key चुनें। Key Name में एप्लिकेशन या परिवेश पहचानने वाला नाम दें; उसमें गुप्त जानकारी या ग्राहक का डेटा न रखें।
3. Create एक बार दबाएँ और परिणाम की प्रतीक्षा करें। नाम के शुरू और अंत के रिक्त स्थान हटते हैं और नाम खाली नहीं हो सकता; सर्वर अधिकतम 255 अक्षर स्वीकार करता है। Cancel संवाद बंद करता है और कुंजी नहीं बनाता।
4. सफलता पर Save your API key now पैनल से पूरी कुंजी कॉपी करें और पैनल बंद करने, पृष्ठ छोड़ने या पुनः लोड करने से पहले सुरक्षित रखें।

REST कुंजी exk_ से शुरू होती है और उसके बाद 64 हेक्साडेसिमल अक्षर होते हैं। सर्वर SHA-256 हैश और पहचान के लिए 12-अक्षर का उपसर्ग रखता है, पूरी कुंजी की पुनर्प्राप्ति योग्य प्रति नहीं। पूरी कुंजी केवल निर्माण की प्रतिक्रिया में मिलती है; सूची से उसे बाद में नहीं दिखाया जा सकता।

कॉपी बटन के बाद पुष्टि करें कि पूरी कुंजी स्वीकृत सुरक्षित संग्रह में पहुँची है। ब्राउज़र क्लिपबोर्ड रोक दे तो अभी दिख रहे पैनल से सीधे कॉपी करें। कॉपी का संदेश अकेले यह साबित नहीं करता कि रहस्य सही सहेजा गया। पैनल बंद करने पर उसका मान साफ होता है; पुनः लोड या पृष्ठ छोड़ने पर यह अवसर खो जाता है।

• कुंजी सर्वर के सीक्रेट मैनेजर या सुरक्षित वातावरण कॉन्फ़िगरेशन में रखें; ब्राउज़र कोड, सार्वजनिक रिपॉज़िटरी, स्क्रीनशॉट, URL, प्रॉम्प्ट या साझा गणना फ़ाइलों में नहीं।
• रिकॉर्ड सीमा के भीतर, अलग एकीकरणों के लिए अलग नाम वाली कुंजियाँ रखें ताकि घटना होने पर असंबंधित क्रेडेंशियल बदलने की आवश्यकता न पड़े।
• कुंजी खोने पर उसे दिखाने या वापस पाने की कार्रवाई नहीं है। पुराना रिकॉर्ड पहचानकर निरस्त करें, फिर योजना पात्र हो तो नई कुंजी बनाकर कॉन्फ़िगर करें।

प्रबंधन प्रतिक्रिया में केवल स्पष्ट रूप से चुना गया मेटाडेटा होता है; हैश, पूरी कुंजी और मालिक का पहचानकर्ता नहीं। तालिका मेटाडेटा में उपलब्ध अनुरोध गिनती, अनुमतियाँ, समाप्ति या प्रति-कुंजी दर-सीमा नहीं दिखाती। यहाँ पूर्ण अनुरोध लॉग या संपादन योग्य विवरण दृश्य नहीं है।

अंतिम उपयोग की प्रविष्टि असमकालिक है और प्रमाणीकरण व दर-जाँच के बाद, एंडपॉइंट अनुमति जाँच और गणना पूरी होने से पहले होती है। इसमें देरी हो सकती है और यह सफल गणना का प्रमाण नहीं है।

एकीकरण में HTTPS पर पूरी REST कुंजी Authorization हेडर में Bearer क्रेडेंशियल के रूप में भेजें। उपसर्ग या MCP टोकन काम नहीं करेगा। नीचे केवल हेडर का नमूना है, चलाने के लिए अनुरोध नहीं। वास्तविक इनपुट अनुबंध और इकाइयों के लिए एंडपॉइंट संदर्भ देखें; कुंजी पृष्ठ का छोटा गणना उदाहरण पूर्ण विनिर्देश नहीं है।

REST की डिफ़ॉल्ट सीमा प्रति कुंजी 100 अनुरोध प्रति मिनट है। दर-सीमक तक पहुँचने वाली प्रतिक्रियाओं में X-RateLimit-Limit, X-RateLimit-Remaining और X-RateLimit-Reset आते हैं; Reset सेकंड में Unix टाइमस्टैम्प है। वर्तमान दर-सीमक सर्वर प्रक्रिया की मेमोरी में है, प्रतिकृतियों में साझा कोटे की गारंटी नहीं। दिखा हुआ डिफ़ॉल्ट थ्रूपुट की गारंटी नहीं देता।

• 401: गायब या गलत Bearer हेडर, गलत क्रेडेंशियल प्रकार, अधूरी या अज्ञात कुंजी जाँचें। त्रुटि रिपोर्ट में कभी कुंजी न डालें।
• 403: संदेश पढ़कर निरस्तीकरण, समाप्ति, अपात्र सदस्यता या एंडपॉइंट अनुमति की कमी पहचानें। दूसरी कुंजी बनाना सदस्यता प्रतिबंध ठीक नहीं करता।
• 429: तेज़ पुनःप्रयास रोकें और विंडो रीसेट होने दें। इनपुट व सॉल्वर त्रुटियाँ कुंजी प्रबंधन से अलग हैं; लौटाई गई त्रुटि को रखें, वैध परिणाम न मानें।

Authorization: Bearer <EXCOIL_REST_API_KEY>

• REST API परिचय
• गणना एंडपॉइंट संदर्भ

पृष्ठ केवल निरस्त पंक्तियों में Delete दिखाता है। योजना घटने के बाद भी प्रबंधन कार्रवाइयों में मालिक की जाँच होती है। REST निरस्तीकरण को स्वतंत्र MCP कनेक्शन निरस्त करने से न मिलाएँ।

1. नाम और उपसर्ग से सही रिकॉर्ड पहचानें। उपयोग में चल रहे एकीकरण के लिए पहले बदलाव की योजना बनाएँ, जब तक संभावित लीक के कारण तुरंत निरस्त करना आवश्यक न हो।
2. सक्रिय पंक्ति में Revoke चुनें। पुष्टि पढ़कर नाम जाँचें; Cancel कोई बदलाव नहीं करता। नए अनुरोध रोकने के लिए तैयार होने पर ही Revoke key की पुष्टि करें।
3. प्रक्रिया और सूची के ताज़ा होने की प्रतीक्षा करें। पंक्ति Revoked होनी चाहिए, सक्रिय गिनती घटनी चाहिए और Revoke की जगह Delete आना चाहिए। निरस्त कुंजी फिर सक्रिय नहीं हो सकती।
4. बचा रिकॉर्ड हटाकर जगह खाली करने के लिए निरस्त पंक्ति में Delete चुनें, नाम जाँचें और Delete key की पुष्टि करें। यह स्थायी रिकॉर्ड हटाना वापस नहीं किया जा सकता।

सूची लोड होते समय प्रतीक्षा संदेश आता है। विफल होने पर त्रुटि और Try again दिखाई देते हैं; लोडिंग विफलता को खाली खाता न समझें। सफल खाली सूची No API keys yet बताती है। निर्माण और प्रबंधन त्रुटियाँ सर्वर संदेश दिखाती हैं; निरस्त/हटाने की त्रुटियाँ पुष्टि संवाद में भी रहती हैं।

निरस्त या हटाने की प्रक्रिया के दौरान पुष्टि नियंत्रण निष्क्रिय होते हैं ताकि दोहरा सबमिशन न हो। अनुरोध विफल हो या परिणाम अनिश्चित हो तो बिना रहस्य वाला संदेश रखें, सूची फिर लोड करें और पुनःप्रयास से पहले संबंधित पंक्ति जाँचें। पृष्ठ दोबारा खोलना या लोड करना स्थिति ताज़ा करता है, लेकिन नई बनी पूरी कुंजी वापस नहीं लाता।

• निर्माण का परिणाम अनिश्चित हो तो दूसरी कुंजी बनाने से पहले नाम वाला रिकॉर्ड खोजें। रिकॉर्ड मौजूद हो लेकिन रहस्य न सहेजा हो तो उसे निरस्त करके बदलें; मेटाडेटा से पुनर्प्राप्ति नहीं होती।
• New Key उपलब्ध न हो तो सदस्यता पात्रता, सूची त्रुटियाँ और कुल रिकॉर्ड जाँचें। केवल निरस्त करने से कुल संख्या नहीं घटती।
• सफलता के बाद अपेक्षित स्थिति देखें: निरस्त करने पर Revoked, हटाने पर पंक्ति अनुपस्थित। पुनः लोड के बाद भी असंगति हो तो सफलता न मानें और सहायता लेते समय रहस्य उजागर न करें।

MCP का प्रबंधन अलग /mcp पृष्ठ पर होता है और /api/mcp के लिए समर्पित exm_ Bearer टोकन उपयोग होते हैं। REST exk_ कुंजियाँ MCP क्रेडेंशियल नहीं हैं और MCP टोकन REST कुंजियों की जगह नहीं लेते। MCP बनाने और उपयोग करने के लिए Manufacturer तथा active या trialing स्थिति चाहिए; केवल Enterprise पर्याप्त नहीं है।

MCP मैनुअल Bearer कॉन्फ़िगरेशन उपयोग करता है, OAuth नहीं। इसके टोकन के अपने स्कोप, 7/30/90 दिन की वैधता और अलग निरस्तीकरण प्रक्रिया हैं; प्रोजेक्ट पढ़ना अलग वैकल्पिक अनुमति है। REST फ़ॉर्म में ये नियंत्रण नहीं हैं। योजना घटाने के बाद भी पुराने MCP कनेक्शन सूचीबद्ध और निरस्त किए जा सकते हैं।

संगत क्लाइंट और प्रकाशित MCP पृष्ठ पर दिखा एंडपॉइंट उपयोग करें; उपलब्धता हर AI क्लाइंट में समर्थन की गारंटी नहीं। REST कुंजी या MCP कनेक्शन बनाना निर्माण फ़ाइलें, बिलिंग कार्रवाई या प्रशासनिक पहुँच नहीं देता। निर्माण के विस्तृत फीचर वास्तविक उत्पाद कार्यप्रवाह में Manufacturer तक सीमित हैं।

• दस्तावेज़ सूची