Entity Enricher तक प्रोग्रामेटिक एक्सेस के लिए API की बनाएँ। सर्विस-टू-सर्विस इंटीग्रेशन, CI/CD पाइपलाइन और स्वचालित वर्कफ़्लो के लिए organization एक्सेस की का उपयोग करें।
Entity Enricher दो प्रकार की API keys का समर्थन करता है, प्रत्येक अलग-अलग उपयोग मामलों के लिए उपयुक्त है:
अपनी खुद की भूमिका वाली स्टैंडअलोन कीज़, जो किसी यूज़र अकाउंट से बंधी नहीं होतीं। सर्विस-टू-सर्विस इंटीग्रेशन के लिए सबसे बेहतर विकल्प।
किसी विशिष्ट उपयोगकर्ता खाते से जुड़ी कुंजियाँ। वे निर्माता की भूमिका को इनहेरिट करती हैं और उपयोगकर्ता खाते में बदलावों से प्रभावित होती हैं।
ent_a1b2c3d4e5f6g7h8कुंजियाँ ent_ प्रीफ़िक्स का उपयोग करती हैं जिसके बाद रैंडम बाइट्स आते हैं। पूरी कुंजी निर्माण के समय केवल एक बार दिखाई जाती है — इसे बाद में प्राप्त नहीं किया जा सकता।
एक्सेस कीज़ (Entity Enricher's API को कॉल करने के लिए) डेटाबेस में SHA256 हैश के रूप में संग्रहित की जाती हैं, इसलिए डेटाबेस एक्सेस होने पर भी मूल की को पुनर्प्राप्त नहीं किया जा सकता। पहचान के लिए केवल पहले 12 अक्षर (प्रीफ़िक्स) सादे टेक्स्ट में संग्रहित किए जाते हैं।
प्रोवाइडर की (Anthropic, OpenAI जैसी LLM API की) को Fernet सिमेट्रिक एन्क्रिप्शन (AES-128-CBC + HMAC) का उपयोग करके रेस्ट पर एन्क्रिप्ट किया जाता है। LLM प्रोवाइडर्स के साथ प्रमाणीकरण के लिए इन्हें रनटाइम पर डिक्रिप्ट किया जा सकना आवश्यक है। केवल अंतिम 4 वर्ण सादे टेक्स्ट में संग्रहीत किए जाते हैं।
एप्लिकेशन में API Keys पेज से, या REST API के माध्यम से प्रोग्रामेटिक रूप से की बनाएँ:
| फ़ील्ड | विवरण |
|---|---|
| नाम | पहचान के लिए एक वर्णनात्मक नाम (जैसे, "CI/CD Pipeline", "n8n Integration") |
| भूमिका | परमिशन लेवल: owner, editor, या operator। तय करता है कि key क्या एक्सेस कर सकती है। |
| स्कोप | read, write, या दोनों। यह नियंत्रित करता है कि की डेटा को संशोधित कर सकती है या केवल पढ़ सकती है। |
| समाप्ति | वैकल्पिक समाप्ति तिथि। बिना समाप्ति वाली कीज़ रद्द किए जाने तक बनी रहती हैं। |
हर 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> | वेब क्लाइंट, इंटरैक्टिव सत्र |
API कुंजी की भूमिका तय करती है कि वह किन एंडपॉइंट्स तक पहुँच सकती है:
| Endpoint श्रेणी | न्यूनतम भूमिका |
|---|---|
| संवर्धन (एकल, बैच) | ऑपरेटर |
| रिकॉर्ड्स (सूची, विवरण, हटाएँ) | ऑपरेटर |
| स्कीमा (पढ़ें) | ऑपरेटर |
| स्कीमा (बनाएं, संपादित करें, हटाएं) | एडिटर |
| फ्यूज़न | ऑपरेटर |
| प्रोवाइडर जानकारी | ऑपरेटर |
| लागत एनालिटिक्स | ऑपरेटर |
| API कुंजी प्रबंधन | स्वामी |
| उपयोगकर्ता प्रबंधन | स्वामी |
API Keys पेज उपयोग आँकड़ों के साथ सभी ऑर्गनाइज़ेशन कुंजियों का पूरा दृश्य प्रदान करता है:
API Keys पेज पर अलग-अलग उद्देश्यों को पूरा करने वाले कई टैब हैं:
स्वतंत्र बिलिंग के लिए आपके organization की LLM provider API keys (Anthropic, OpenAI, आदि)। स्वचालित LRU रोटेशन के साथ प्रति provider कई keys का समर्थन करता है। BYOK सिस्टम के लिए Models & Pricing देखें।
प्रोवाइडर कीज़ को Fernet सिमेट्रिक एन्क्रिप्शन (HMAC प्रमाणीकरण के साथ AES-128-CBC) का उपयोग करके रेस्ट पर एन्क्रिप्ट किया जाता है। इन्हें केवल रनटाइम पर LLM API कॉल करते समय डिक्रिप्ट किया जाता है। प्रदर्शन उद्देश्यों के लिए केवल अंतिम 4 अक्षर सादे टेक्स्ट में संग्रहीत किए जाते हैं।
एडमिनिस्ट्रेटर द्वारा प्रबंधित सिस्टम-व्यापी LLM प्रोवाइडर कुंजियाँ। जब कोई ऑर्गनाइज़ेशन कुंजी उपलब्ध न हो तो फ़ॉलबैक के रूप में उपयोग की जाती हैं। LRU रोटेशन के साथ प्रति प्रोवाइडर कई कुंजियों का समर्थन करता है और स्थायी विफलताओं पर स्वतः निष्क्रिय करता है।
Entity Enricher के अपने API तक पहुँचने के लिए कुंजियाँ। बाहरी सिस्टम द्वारा एनरिचमेंट, स्कीमा, रिकॉर्ड, और अन्य एंडपॉइंट को प्रोग्रामेटिक रूप से कॉल करने के लिए उपयोग की जाती हैं। एंडपॉइंट दस्तावेज़ीकरण के लिए API संदर्भ देखें।