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 वर्ण सादे टेक्स्ट में संग्रहीत किए जाते हैं।

"Access Key Created" पैनल: एक एम्बर चेतावनी कि की दोबारा नहीं दिखाई जाएगी, नई की जो ent_vwhj2r6b से शुरू होती है और उसके आगे छिपा दी गई है, एक Copy बटन, एक "Example curl command" डिस्क्लोज़र और एक Done बटन — इस स्क्रीनशॉट में कुंजी का मुख्य भाग जानबूझकर छिपाया गया है। डेटाबेस केवल `ent_` प्रीफ़िक्स और एक हैश रखता है, इसलिए जो कुंजी यहाँ कॉपी नहीं की गई उसे बदलना ही पड़ता है, वह कभी वापस नहीं मिलती।

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

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

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

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

नई एक्सेस कुंजी फ़ॉर्म: "Zapier bridge" वाला नाम फ़ील्ड, Operator पर सेट भूमिका ड्रॉपडाउन, "समाप्ति अवधि" ड्रॉपडाउन जो "कोई समाप्ति नहीं" पर सेट है, और रद्द करें व बनाएँ बटन — स्कोप ही एकमात्र फ़ील्ड है जिसे यह फ़ॉर्म छोड़ देता है: यहाँ बनाई गई की में read और write दोनों होते हैं, और सिर्फ़-रीड वाली की API के ज़रिए माँगी जाती है।

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.1	Authorization: Bearer <access_token>	कनेक्टर और AI क्लाइंट — हर ऐप के लिए रद्द की जा सकने वाली अनुमति, कोई साझा की नहीं

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

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

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

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

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

उपयोग देखेंप्रत्येक की के लिए अंतिम उपयोग टाइमस्टैम्प और कुल उपयोग संख्या देखें

भूमिका अपडेट करेंकिसी संगठन एक्सेस की की भूमिका बदलें (केवल owner)

रद्द करेंकिसी की को स्थायी रूप से अक्षम करें। रद्द की गई कीज़ को फिर से सक्रिय नहीं किया जा सकता।

समाप्ति7 दिनों के भीतर समाप्त होने वाली कुंजियों को फ़्लैग किया जाता है। समाप्त हो चुकी कुंजियाँ स्वचालित रूप से अस्वीकार कर दी जाती हैं।

App Access Keys टेबल जिसमें तीन की हैं — CI nightly export, Make.com scenarios और n8n Integration — हर एक में छोटा किया गया की प्रीफ़िक्स, एक इनलाइन Role ड्रॉपडाउन, रिक्वेस्ट काउंट और Last Used कॉलम में Never दिख रहा है, और एक पंक्ति का मेन्यू Revoke पर खुला है — कुंजी कॉलम एक प्रीफ़िक्स दिखाता है क्योंकि संग्रहीत केवल प्रीफ़िक्स ही होता है: टेबल में और ऑडिट ट्रेल में दो कुंजियों को अलग पहचानने के लिए पर्याप्त, पर उससे API कॉल करने की कोशिश करने वाले किसी के लिए बेकार।

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

API Keys पेज पर अलग-अलग काम करने वाले पाँच टैब हैं — उनमें से चार सबके लिए, और सिस्टम एडमिनिस्ट्रेटर के लिए Global Keys:

API Keys पेज अपने टैब बार के साथ — AI Provider Keys, Global Keys, App Access Keys, Connected Apps, Ollama Tunnels — जिसमें App Access Keys चुना हुआ है और तीन संगठन एक्सेस की तथा एक Create Access Key बटन दिख रहा है — पहले दो टैब में वे की होती हैं जिनसे Entity Enricher किसी LLM तक पहुँचता है; आखिरी तीन में वे क्रेडेंशियल होते हैं जिनसे दूसरे सिस्टम आपके संगठन तक पहुँचते हैं। पेज पर यह कहीं नहीं लिखा, पर यही दिशा तय करती है कि कोई की किस टैब की है।

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

स्वतंत्र बिलिंग के लिए आपके संगठन की LLM प्रोवाइडर API कुंजियाँ (Anthropic, OpenAI, आदि)। प्रति प्रोवाइडर कई कुंजियाँ समर्थित हैं, स्वचालित LRU रोटेशन के साथ; जिस कुंजी का टेस्ट विफल होता है वह रोटेशन से बाहर हो जाती है, जब तक उसे फिर से टेस्ट या बदला न जाए। BYOK सिस्टम के लिए मॉडल और प्राइसिंग देखें।

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

ग्लोबल कीज़

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

ऐप एक्सेस कीज़

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

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

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

Ollama Tunnels

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

Connected Apps टेबल जिसमें तीन OAuth ग्रांट सूचीबद्ध हैं: n8n (production), जिसे Editor User ने API सरफ़ेस पर Editor भूमिका के साथ अधिकृत किया; MCP API पर Codex और MCP पर claude.ai, दोनों को Premium Owner ने Owner भूमिका के साथ अधिकृत किया — हर पंक्ति में अंतिम उपयोग का समय, कनेक्ट होने की तारीख़ और एक पंक्ति मेनू है — Connected Apps टैब: हर अधिकृत ऐप और सदस्य के लिए एक पंक्ति, ताकि एक ही व्यक्ति claude.ai और कोई n8n इंस्टेंस अलग-अलग कनेक्ट कर सके। Last Used ही बताता है कि रद्द करने से पहले कौन-सा कनेक्टर अब भी चल रहा है।