इतर सॉफ्टवेअरला तुमचा डेटा वाचू देणे

एपीआय स्टुडिओ: एका वेळी एक स्क्रीन प्रकाशित करणे, की जारी करणे, ती एका पत्त्यावर पिन करणे, आणि एआय एजंटसाठी एमसीपी सर्व्हर म्हणून तेच प्रकाशन करणे.

कधी ना कधी TRANXACT च्या बाहेरील एखाद्या गोष्टीला तुमच्या डेटाची गरज भासतेच: जसे की एखादे रिपोर्टिंग टूल, भागीदाराची सिस्टीम, किंमत सूचीची गरज असलेली एखादी वेबसाइट किंवा तुमच्या व्यवसायाबद्दल प्रश्न विचारलेला एखादा AI एजंट. प्लॅटफॉर्म अंतर्गत असलेल्या API स्टुडिओमध्ये, तुम्ही ठरवता की यामागे काय काय करण्याची परवानगी आहे — एका वेळी एक स्क्रीन, एका वेळी एक कॉलम.

जोपर्यंत कोणीतरी ते प्रकाशित करत नाही, तोपर्यंत बाहेरून कशापर्यंतही पोहोचता येत नाही. अशी कोणतीही सेटिंग नाही जी सर्वकाही उघडेल आणि अशी कोणतीही कळ नाही जी सर्वत्र पोहोचेल. अगदी नवीन डिप्लॉयमेंटमध्ये कोणताही API सरफेस नसतो, आणि चालू होण्याची वाट पाहण्याऐवजी हीच योग्य सुरुवातीची स्थिती आहे.

चार निर्णय, क्रमाने

काय	ते काय ठरवते	सहसा कोण बनवते
एक प्रदर्शन	ती एक स्क्रीन या कंपनीतून पूर्णपणे बाहेर जाऊ शकते — तिचे कोणते स्तंभ, कोणत्या ओळी, आणि त्यावर काही परत लिहिले जाऊ शकते की नाही.	डेटाचा मालक कोणीही असो
एक ग्राहक	ते एक सॉफ्टवेअर अस्तित्वात आहे, त्याचे नाव काय आहे, त्याबद्दल कोणाला संपर्क साधावा आणि ते तुमच्या कोणत्या वापरकर्त्याच्या वतीने काम करते.	जो कोणी एकीकरण चालवतो
अनुदान	या क्रियापदांच्या साहाय्याने, हा ग्राहक ती ओळख मिळवू शकेल.	जो कोणी एकीकरण चालवतो
एक मंजूर पत्ता	जिथून की सादर केली जाऊ शकते — ब्राउझर ओरिजिन, होस्ट, एका सर्व्हरचा पत्ता किंवा नेटवर्क.	जो कोणी एकीकरण चालवतो

प्लॅटफॉर्म यासाठी तीन भूमिका पुरवतो आणि त्यांना मुद्दामहून वेगळे ठेवतो. एक API पब्लिशर काय बाहेर जाऊ शकते हे ठरवतो आणि की जारी करू शकत नाही. एक API रजिस्ट्रार की जारी करतो आणि कोणताही धोका निर्माण करू शकत नाही. एक API रिव्ह्यूअर सर्व काही वाचतो आणि काहीही बदलत नाही. एकाच व्यक्तीद्वारे केले जाणारे, पेरोल टेबल प्रकाशित करणे आणि ते वाचणारी की स्वतःला जारी करणे हा एक संपूर्ण, साक्षीदारांशिवायचा निर्यात मार्ग आहे, ज्यातील प्रत्येक टप्पा एका सामान्य प्रशासकीय बदलासारखा दिसतो.

स्क्रीन प्रकाशित करणे

प्लॅटफॉर्म → एपीआय स्टुडिओ उघडा आणि एक स्क्रीन निवडा. यादीमध्ये कन्सोलमधील प्रत्येक स्क्रीन आहे, जी थेट उत्पादनातूनच वाचली जाते — त्यामुळे या रिलीझमध्ये समाविष्ट असलेली स्क्रीन त्यात आहे.
जे स्तंभ वगळले जाऊ शकतात, त्यांना टिक करा. जे टिक केलेले नाही, ते कधीही पाठवले जात नाही: सूचीमध्ये नाही, स्वतंत्र रेकॉर्डमध्ये नाही, किंवा लेखकाने परत पाठवलेल्या मजकुरातही नाही. मुद्दामहून, सुरुवातीलाच कशालाही टिक केले जात नाही.
क्रियापदे ठरवा. 'वाचणे' (Read) हे पूर्वनिर्धारितपणे चालू असते; 'तयार करणे' (create), 'बदलणे' (change) आणि 'हटवणे' (delete) हे प्रत्येक स्वतंत्र निर्णय आहेत, कारण त्यांच्या प्रणालीला तुमचा आयटम मास्टर वाचू देणे आणि त्यांच्या प्रणालीला तो हटवू देणे ही एकच वाक्यरचना नाही.
वैकल्पिकरित्या पंक्ती मर्यादित करा — फक्त पोस्ट केलेली बिले, फक्त या वर्षाची. हा तोच फिल्टर आहे जो प्रत्येक लिस्ट स्क्रीनवर दिसतो, प्रत्येक कॉलवर सर्व्हरवर लागू केला जातो आणि कॉलरने पाठवलेल्या कोणत्याही गोष्टीने तो वाढवता येत नाही.
हे जतन करा. हा एक कच्चा मसुदा आहे, आणि कच्च्या मसुद्याला काही अर्थ नसतो. जेव्हा तुम्हाला खरोखरच तसे करायचे असेल, तेव्हाच ते प्रत्यक्ष वापरात आणा.
कोणालाही की देण्यापूर्वी प्रिव्ह्यू दाबा. यामुळे पार्टनरला नेमके काय मिळेल आणि किती कॉलम रोखून ठेवण्यात आले आहेत, हे दिसते.

सॉफ्टवेअरची नोंदणी करणे

क्लायंट म्हणजे सॉफ्टवेअरची एक नोंद असते: त्याचे नाव काय आहे, ते काय आहे, त्याबद्दल कोणाशी संपर्क साधावा, आणि — सर्वात महत्त्वाचे म्हणजे — ते तुमच्या कोणत्या वापरकर्त्याच्या भूमिकेत काम करते. की द्वारे केलेला प्रत्येक कॉल त्याच व्यक्तीच्या वतीने केला जातो. जे काही ते करू शकत नाहीत, ते की सुद्धा करू शकत नाही.

स्क्रीनवरील ते सर्वात महत्त्वाचे क्षेत्र आहे, आणि म्हणूनच एखादे एक्सपोजर (exposure) प्रवेशाची व्याप्ती केवळ मर्यादित करू शकते, कधीही वाढवू शकत नाही. एखादे की (key) त्या उद्देशासाठी बनवलेल्या वापरकर्त्याकडे निर्देशित करा, जो ते काम करणारी सर्वात मर्यादित भूमिका बजावतो — केवळ सोयीसाठी खऱ्या प्रशासकाकडे नाही.

की (key) स्वतः एकदाच, ती जारी केल्यावर दाखवली जाते आणि त्यानंतर पुन्हा कधीही नाही. नवीन की जारी केल्यावर जुनी की काम करणे तात्काळ थांबवते. क्लायंटला न हटवता की मागे घेतली जाऊ शकते, त्यामुळे कोणाकडे पोहोच होती आणि ती केव्हा काढून घेण्यात आली, हे रजिस्टरमध्ये अजूनही नोंदवलेले असते.

जिथून चावी वापरली जाऊ शकते

ज्या कीला कोणतेही अनुमत पत्ते नाहीत, ती कशापर्यंतही पोहोचत नाही. कोणताही पत्ता नमूद केलेला नाही याचा अर्थ 'अद्याप पोहोचण्यायोग्य नाही' आणि 'कुठूनही कधीही पोहोचण्यायोग्य नाही' असा घेतला जातो, कारण जगातील कोणत्याही लॅपटॉपवरून काम करणारी लीक झालेली की हाच संपूर्ण धोका आहे. प्रवेशाचे चार प्रकार: ब्राउझर ओरिजिन, रेफरिंग होस्ट, एकच पत्ता, किंवा CIDR स्वरूपातील नेटवर्क.

एखाद्या क्लायंटला कुठूनही वापरण्यायोग्य म्हणून चिन्हांकित केले जाऊ शकते, आणि कधीकधी ते योग्यही असते — उदाहरणार्थ, असा भागीदार ज्याचा बाहेर पडण्याचा पत्ता (egress address) खरोखरच बदलतो. हा डीफॉल्ट पर्याय नसून, त्यासोबत चेतावणी असलेला एक हेतुपुरस्सर केलेला बदल आहे.

जो कोणी एकीकरण करत आहे त्याला काय पाठवावे?

स्टुडिओ चार पत्ते छापतो. बेस /api/v1 आहे, की Authorization: Bearer हेडरमध्ये जाते, /api/v1/resources मध्ये ही की कशापर्यंत पोहोचू शकते याची यादी असते आणि /api/v1/openapi.json हे OpenAPI 3.1 डॉक्युमेंटसारखेच आहे.

त्या दोन्ही गोष्टी, त्यांची मागणी करणाऱ्या की (key) मधून तयार केल्या जातात. भागीदाराला कधीही असे डॉक्युमेंट दिले जात नाही, ज्यात ते कॉल करू शकत नाहीत अशा चाळीस एंडपॉइंट्सची यादी असेल: त्यांच्या डॉक्युमेंटमध्ये ते नेमके काय कॉल करू शकतात याचेच वर्णन असते, बाकी कशाचेही नाही, आणि त्यात नाकारल्या जाणाऱ्या पाथचे वर्णन असू शकत नाही, कारण ते त्याच पंक्तींमधून (rows) तयार केलेले असते ज्यांची रिक्वेस्ट हँडलर तपासणी करतो.

एआय एजंटसाठी तोच डेटा

/api/v1/mcp हा पत्ता एक मॉडेल कॉन्टेक्स्ट प्रोटोकॉल सर्व्हर आहे. त्याला कनेक्ट होणाऱ्या एजंटला, की (key) करू शकणाऱ्या प्रत्येक गोष्टीसाठी एक साधन दिले जाते आणि बाकी काहीही नाही — कोणीही प्रकाशित न केलेल्या डेटासाठी कोणतेही साधन नाही, कोणीही मंजूर न केलेल्या क्रियापदासाठी कोणतेही साधन नाही. हे तेच प्रकाशन आहे, जे डेव्हलपरऐवजी मॉडेलसाठी वर्णन केलेले आहे, त्यामुळे या दोन्हींमध्ये कधीही ताळमेळ बिघडत नाही.

क्लायंटवर MCP सूचना लिहा. ही एकमेव जागा आहे जिथे मॉडेलला सांगितले जाते की ही साधने सँडबॉक्सऐवजी थेट लेजरपर्यंत पोहोचतात, आणि ही एकमेव जागा आहे जिथे तुम्ही म्हणू शकता की येथील 'ऑर्डर्स' म्हणजे खरेदी ऑर्डर्स आहेत, विक्री ऑर्डर्स नव्हे.

प्रत्येक कॉलवर काय घडतं?

प्रकाशित केलेला कॉल हा डेटाबेसमध्ये प्रवेश करण्याचा शॉर्टकट नाही. तो प्रमाणीकृत केला जातो, एक्सपोजर आणि ग्रँटच्या विरुद्ध तपासला जातो, आणि मग प्लॅटफॉर्मच्या स्वतःच्या API द्वारे तुमच्या 'रन-ॲज' युझर म्हणून कार्यान्वित केला जातो — हाच मार्ग कन्सोल वापरतो. कंपनी स्कोपिंग, बिझनेस-युनिट स्कोपिंग, ठिकाणावरील निर्बंध, बंद कालावधी, पोस्टिंगचे नियम, कस्टम फील्ड्स, कस्टम लॉजिक, संपादनक्षमता आणि ऑडिट ट्रेल हे सर्व लागू होतात, कारण चालणारा तो एकच कोड असतो.

प्रत्येक कॉल, तो मंजूर झाला की नाकारला गेला, याचे कारणासह रेकॉर्ड केले जाते. तो लॉग 'प्लॅटफॉर्म → एपीआय स्टुडिओ → एपीआय कॉल लॉग' अंतर्गत असतो आणि ज्या पत्त्यावर कोणीही परवानगी दिली नाही, तिथून सादर केलेली की ही त्यातील सर्वात महत्त्वाची ओळ असते.

जेव्हा ते काम करत नाही

जोडीदाराला काय दिसते	याचा अर्थ काय आहे
ती API की ओळखली जात नाही.	चुकीची चावी, किंवा त्यानंतर नवीन चावी देण्यात आली आहे.
या API की साठी कोणतेही अनुमत पत्ते नाहीत.	त्याचा वापर कुठून केला जाऊ शकतो हे अद्याप कोणीही सांगितलेले नाही.
येथून ही API की वापरण्यास परवानगी नाही.	ते प्रत्यक्षात पोहोचलेल्या मूळ ठिकाणाचे आणि पत्त्याचे नाव सांगते — सहसा भागीदाराने सर्व्हर बदललेले असतात.
येथे X म्हणून काहीही प्रकाशित केले जात नाही.	नाव चुकीचे आहे, किंवा या की साठी एक्सपोजर मंजूर केलेले नाही, किंवा तो अजूनही एक मसुदा आहे.
ही की X तयार करू शकत नाही	प्रदर्शन किंवा अनुदान त्या क्रियापदास परवानगी देत नाही.
तुम्हाला X पाहण्याची परवानगी नाही	अनुदान ठीक आहे, पण 'रन-ॲज' वापरकर्ता नाही. भागीदाराला ते शोधावे लागण्यापूर्वीच स्टुडिओ त्यांची यादी देतो.

क्लायंटच्या यादीत केवळ स्थितीऐवजी सज्जतेचा स्तंभ दिसतो, कारण एखादा क्लायंट सक्रिय असू शकतो, त्याच्याकडे की असू शकते, पण तरीही त्याला काहीच मिळत नाही — म्हणजेच, चालवण्यासाठी कोणताही वापरकर्ता नसतो, कोणताही पत्ता वापरण्याची परवानगी नसते, किंवा काहीही मंजूर केलेले नसते. प्रत्येक कॉल नाकारला जात असताना क्लायंट सक्रिय आहे असे वाचणे, हीच दुपारची वेळ घालवण्याची पद्धत आहे.