API कुंजियाँ - Entity Enricher दस्तावेज़ीकरण

API कुंजियाँ

Entity Enricher तक प्रोग्रामेटिक एक्सेस के लिए API की बनाएँ। सर्विस-टू-सर्विस इंटीग्रेशन, CI/CD पाइपलाइन और स्वचालित वर्कफ़्लो के लिए organization एक्सेस की का उपयोग करें।

कुंजी प्रकार

Entity Enricher दो प्रकार की API keys का समर्थन करता है, प्रत्येक अलग-अलग उपयोग मामलों के लिए उपयुक्त है:

अनुशंसित

संगठन एक्सेस कीज़

अपनी खुद की भूमिका वाली स्टैंडअलोन कीज़, जो किसी यूज़र अकाउंट से बंधी नहीं होतीं। सर्विस-टू-सर्विस इंटीग्रेशन के लिए सबसे बेहतर विकल्प।

  • उनकी अपनी भूमिका होती है (owner, editor, या operator)
  • उपयोगकर्ता खाते के बदलावों से प्रभावित नहीं
  • organization तक सीमित
  • बनाने के लिए owner भूमिका आवश्यक है

लेगेसी यूज़र की-ज़

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

  • बनाने वाले उपयोगकर्ता की भूमिका इनहेरिट करें
  • यदि उपयोगकर्ता निष्क्रिय कर दिया जाता है, तो कुंजी काम करना बंद कर देती है
  • कोई भी प्रमाणित उपयोगकर्ता एक बना सकता है

कुंजी फ़ॉर्मेट और सुरक्षा

फ़ॉर्मैट:ent_a1b2c3d4e5f6g7h8

कुंजियाँ ent_ प्रीफ़िक्स का उपयोग करती हैं जिसके बाद रैंडम बाइट्स आते हैं। पूरी कुंजी निर्माण के समय केवल एक बार दिखाई जाती है — इसे बाद में प्राप्त नहीं किया जा सकता।

एक्सेस कीज़ (Entity Enricher's API को कॉल करने के लिए) डेटाबेस में SHA256 हैश के रूप में संग्रहित की जाती हैं, इसलिए डेटाबेस एक्सेस होने पर भी मूल की को पुनर्प्राप्त नहीं किया जा सकता। पहचान के लिए केवल पहले 12 अक्षर (प्रीफ़िक्स) सादे टेक्स्ट में संग्रहित किए जाते हैं।

प्रोवाइडर की (Anthropic, OpenAI जैसी LLM API की) को Fernet सिमेट्रिक एन्क्रिप्शन (AES-128-CBC + HMAC) का उपयोग करके रेस्ट पर एन्क्रिप्ट किया जाता है। LLM प्रोवाइडर्स के साथ प्रमाणीकरण के लिए इन्हें रनटाइम पर डिक्रिप्ट किया जा सकना आवश्यक है। केवल अंतिम 4 वर्ण सादे टेक्स्ट में संग्रहीत किए जाते हैं।

API कुंजियाँ बनाई जा रही हैं

एप्लिकेशन में API Keys पेज से, या REST API के माध्यम से प्रोग्रामेटिक रूप से की बनाएँ:

कुंजी कॉन्फ़िगरेशन

फ़ील्डविवरण
नामपहचान के लिए एक वर्णनात्मक नाम (जैसे, "CI/CD Pipeline", "n8n Integration")
भूमिकापरमिशन लेवल: owner, editor, या operator। तय करता है कि key क्या एक्सेस कर सकती है।
स्कोपread, write, या दोनों। यह नियंत्रित करता है कि की डेटा को संशोधित कर सकती है या केवल पढ़ सकती है।
समाप्तिवैकल्पिक समाप्ति तिथि। बिना समाप्ति वाली कीज़ रद्द किए जाने तक बनी रहती हैं।

API Keys का उपयोग

हर request के साथ अपनी API key X-API-Key header में भेजें:

curl -H "X-API-Key: ent_your_key_here" \
     https://your-instance.example.com/api/enrichment/options

प्रमाणीकरण विधियाँ

मेथडहेडरयूज़ केस
API कुंजीX-API-Key: ent_...Service-to-service, CI/CD, automation
Bearer टोकनAuthorization: Bearer <jwt>वेब क्लाइंट, इंटरैक्टिव सत्र
OAuth 2.1Authorization: Bearer <access_token>कनेक्टर और AI क्लाइंट — हर ऐप के लिए रद्द की जा सकने वाली अनुमति, कोई साझा की नहीं

भूमिका के अनुसार Endpoint एक्सेस

API कुंजी की भूमिका तय करती है कि वह किन एंडपॉइंट्स तक पहुँच सकती है:

Endpoint श्रेणीन्यूनतम भूमिका
संवर्धन (एकल, बैच)ऑपरेटर
रिकॉर्ड्स (सूची, विवरण, हटाएँ)ऑपरेटर
स्कीमा (पढ़ें)ऑपरेटर
स्कीमा (बनाएं, संपादित करें, हटाएं)एडिटर
फ्यूज़नऑपरेटर
प्रोवाइडर जानकारीऑपरेटर
लागत एनालिटिक्सऑपरेटर
API कुंजी प्रबंधनस्वामी
उपयोगकर्ता प्रबंधनस्वामी

Keys प्रबंधित करना

API Keys पेज उपयोग आँकड़ों के साथ सभी ऑर्गनाइज़ेशन कुंजियों का पूरा दृश्य प्रदान करता है:

उपयोग देखेंप्रत्येक की के लिए अंतिम उपयोग टाइमस्टैम्प और कुल उपयोग संख्या देखें
भूमिका अपडेट करेंकिसी संगठन एक्सेस की की भूमिका बदलें (केवल owner)
रद्द करेंकिसी की को स्थायी रूप से अक्षम करें। रद्द की गई कीज़ को फिर से सक्रिय नहीं किया जा सकता।
समाप्ति7 दिनों के भीतर समाप्त होने वाली कुंजियों को फ़्लैग किया जाता है। समाप्त हो चुकी कुंजियाँ स्वचालित रूप से अस्वीकार कर दी जाती हैं।

प्रोवाइडर कीज़ बनाम एक्सेस कीज़

API Keys पेज में अलग-अलग उद्देश्यों वाले पाँच टैब हैं:

प्रोवाइडर कीज़

स्वतंत्र बिलिंग के लिए आपके organization की LLM provider API keys (Anthropic, OpenAI, आदि)। स्वचालित LRU रोटेशन के साथ प्रति provider कई keys का समर्थन करता है। BYOK सिस्टम के लिए Models & Pricing देखें।

प्रोवाइडर कीज़ को Fernet सिमेट्रिक एन्क्रिप्शन (HMAC प्रमाणीकरण के साथ AES-128-CBC) का उपयोग करके रेस्ट पर एन्क्रिप्ट किया जाता है। इन्हें केवल रनटाइम पर LLM API कॉल करते समय डिक्रिप्ट किया जाता है। प्रदर्शन उद्देश्यों के लिए केवल अंतिम 4 अक्षर सादे टेक्स्ट में संग्रहीत किए जाते हैं।

ग्लोबल कीज़

एडमिनिस्ट्रेटर द्वारा प्रबंधित सिस्टम-व्यापी LLM प्रोवाइडर keys। जब संगठन की कोई key उपलब्ध न हो तो fallback के रूप में इस्तेमाल होती हैं। प्रति प्रोवाइडर कई keys समर्थित हैं, LRU रोटेशन के साथ: सबसे पहले वह सक्षम key चुनी जाती है जिसका उपयोग सबसे पुराना है, और कोई key रोटेशन से तभी हटती है जब एडमिनिस्ट्रेटर उसे स्वयं निष्क्रिय करे।

संगठन एक्सेस कीज़

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

कनेक्टेड ऐप्स

वे एप्लिकेशन जिन्हें आपने OAuth 2.1 के ज़रिए अधिकृत किया है — claude.ai कनेक्टर डायरेक्टरी, Claude Desktop, Make और n8n कनेक्शन। हर पंक्ति साझा सीक्रेट नहीं, बल्कि एक ऐसी अनुमति है जिसे रद्द किया जा सकता है: यहाँ रद्द करने पर उस ऐप के टोकन अमान्य हो जाते हैं और आपके बाकी इंटीग्रेशन अछूते रहते हैं। ओनर सेल्फ़-होस्टेड n8n इंस्टेंस के लिए एक OAuth क्लाइंट भी रजिस्टर कर सकते हैं।

टनल

सेल्फ़-सर्विस Ollama टनल के लिए क्रेडेंशियल, जो कोई पोर्ट खोले बिना लोकल Ollama को प्लेटफ़ॉर्म तक पहुँचाता है। Ollama टनल गाइड देखें।

अगले चरण

API संदर्भ

REST एंडपॉइंट्स के साथ अपनी API keys उपयोग करें।

मॉडल और मूल्य निर्धारण

प्रति-ऑर्ग बिलिंग के लिए प्रोवाइडर कीज़ कॉन्फ़िगर करें।

संगठन और भूमिकाएँ

उन roles को समझें जो प्रमुख अनुमतियों को नियंत्रित करती हैं।