Organizations के लिए बीटा सीमाएँ

Organizations Beta संस्थागत ग्राहकों को उनके Kraken खातों के लिए एक पूर्ण कार्यात्मक शासन परत प्रदान करता है।

बीटा में क्या शामिल है

बीटा के दौरान आप ये कर सकते हैं:

एक Organization बनाएँ और टीम के सदस्यों को आमंत्रित करें
ट्रेडिंग, फंडिंग और प्रशासन के लिए अनुमतियाँ असाइन करें
वर्कफ़्लो के अनुसार अनुमोदन नीतियाँ कॉन्फ़िगर करें
निकासी, पता परिवर्तन, पहुँच परिवर्तन और नीति परिवर्तन के लिए बहु-पक्षीय अनुमोदन की आवश्यकता
एकतरफा परिवर्तनों को रोकने के लिए नीतियों को लॉक करें
प्रोग्रामेटिक API पहुँच के लिए सर्विस यूज़र्स बनाएँ
Organization साइन-इन 2FA और सत्र टाइमआउट नीतियों को लागू करें

वर्तमान सीमाएँ

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

एकल-खाता मॉडल

आपका Organization Owner के प्राथमिक खाते पर संचालित होता है। बहु-खाता ट्रेडिंग — जहाँ Members स्वतंत्र शेष राशि वाले अलग-अलग उप-खातों पर काम करते हैं — अभी उपलब्ध नहीं है।

इसका मतलब है: ट्रेडिंग अनुमतियों वाले सभी Members एक ही खाते पर ट्रेड करते हैं और समान शेष राशि तथा पदों को साझा करते हैं।

सीमित अनुमति का दायरा

सदस्य केवल उन्हीं ऑपरेशंस को कर सकते हैं जहाँ प्लेटफ़ॉर्म ने एक निर्धारित Organization अनुमति दी है। उपलब्ध अनुमतियाँ हैं:

ट्रेड (Spot और Margin)
अर्न आवंटित / गैर-आवंटित करें
निकासी शुरू करें
पते प्रबंधित करें
पहुँच प्रबंधित करें
नीतियाँ प्रबंधित करें

केवल Owner के ऑपरेशंस

ऊपर सूचीबद्ध नहीं किए गए ऑपरेशंस Organization Owner के लिए विशेष रहते हैं। इसमें शामिल हैं:

फ़्यूचर्स ट्रेडिंग
OTC ट्रेडिंग
कन्वर्ट करें
कस्टडी सेटलमेंट्स
संबंधित Organization अनुमति के बिना कोई भी प्लेटफ़ॉर्म ऑपरेशन

Owner Organization निर्माण से पहले के समान प्रवाह का उपयोग करके इन्हें निष्पादित करता है। अन्य Members बीटा के दौरान इन ऑपरेशंस तक पहुँच नहीं बना सकते हैं।

कोई ग्राहक-उन्मुख ऑडिट लॉग नहीं

बीटा के दौरान सदस्य गतिविधि के लिए सुरक्षा घटनाएँ और ऑडिट लॉग उपलब्ध नहीं हैं। एक सेल्फ-सर्विस ऑडिट डैशबोर्ड की योजना है लेकिन अभी उपलब्ध नहीं है।

कस्टम भूमिकाओं को सहेजा नहीं जा सकता

भूमिकाएँ असाइन करते समय आप कस्टम अनुमति कॉन्फ़िगरेशन बना सकते हैं, लेकिन आप एक कस्टम भूमिका को पुन: प्रयोज्य टेम्पलेट के रूप में सहेज नहीं सकते हैं। हर बार जब आप एक कस्टम भूमिका असाइन करते हैं, तो आप इसे स्क्रैच से कॉन्फ़िगर करते हैं।

ईमेल पुष्टि Owner को भेजी गई

जब कोई Member पते में तत्काल परिवर्तन पूरा करने के लिए Execute का उपयोग करता है, तो सिस्टम को ईमेल पुष्टि की आवश्यकता होती है। बीटा के दौरान, यह पुष्टि हमेशा Organization Owner को भेजी जाती है, न कि उस Member को जिसने परिवर्तन शुरू किया था। पुष्टि को सीधे अनुरोध निर्माता को भेजना भविष्य के रिलीज़ के लिए योजनाबद्ध है।

कोई सार्वजनिक Organizations प्रबंधन API नहीं

बीटा के दौरान, सदस्य आमंत्रण, अनुमति प्रबंधन, नीति कॉन्फ़िगरेशन या नीति लॉकिंग के लिए कोई सार्वजनिक Organizations प्रबंधन API नहीं है। प्रोग्रामेटिक एक्सेस समर्थित प्रवाह पर API कुंजी अनुमतियों के माध्यम से कार्य करने वाले Service Users तक सीमित है।

ज्ञात अंतर:

सदस्य आमंत्रण और अनुमति प्रबंधन — केवल UI में उपलब्ध है
नीति कॉन्फ़िगरेशन और लॉकिंग — केवल UI में उपलब्ध है
निकासी अनुरोध — Service Users / API कुंजियों के माध्यम से उपलब्ध; जब कोई Organization नीति कॉन्फ़िगर की जाती है, तो अनुरोध अनुमोदन कतार में चला जाता है
Service Users के माध्यम से ट्रेडिंग और अर्न ऑपरेशंस — केवल API कुंजियों के माध्यम से उपलब्ध (Service Users UI को एक्सेस नहीं कर सकते)

समर्थित API कुंजी ऑपरेशंस पर नवीनतम जानकारी के लिए Kraken API दस्तावेज़ देखें।

यदि आपको आवश्यक कोई ऑपरेशन आपके पसंदीदा चैनल के माध्यम से अभी तक उपलब्ध नहीं है, तो दूसरे चैनल को देखें या मार्गदर्शन के लिए सहायता से संपर्क करें।

निकासी API प्रतिक्रिया आकार में परिवर्तन

जब कोई खाता किसी Organization में नामांकित होता है, तो `withdrawFunds` EAPI प्रतिक्रिया का आकार बदल जाता है। मानक आकार को पार्स करने वाले एकीकरण को नामांकन से पहले कोड अपडेट की आवश्यकता होती है।

केवल विस्तारित डोमेन में Organization उपयोगकर्ताओं पर लागू होता है। गैर-Organization खातों में कोई बदलाव नहीं होता है।

मानक प्रतिक्रिया:

<code>{
 "error": [],
 "result": {
  "refid": "FTRqeuR-9Is99qcv54n0Y0535oPXxb"
 }
}</code>

Organization प्रतिक्रिया:

<code>{
 "error": [],
 "result": {
  "refid": "FTcLNGa-4ZWmo4GCo8wrBNZz5v53v9",
  "approval_request_id": "656a021a-1d55-42c9-853a-aea57bf5abd1"
 }
}</code>

व्यवहार:

`refid` अभी भी अनुरोध निर्माण पर लौटाया जाता है और निकासी की पहचान करना जारी रखता है।
`approval_request_id` जोड़ा जाता है और अनुमोदन अनुरोध की पहचान करता है जो इस निकासी को नियंत्रित करता है।
निकासी तभी पूरी होती है जब अनुमोदन अनुरोध स्वीकृत हो जाता है। अस्वीकृत या समाप्त हो चुके अनुमोदन अनुरोध `refid` के विरुद्ध एक पूरी हुई निकासी उत्पन्न नहीं करते हैं।

नामांकन से पहले अनुशंसित कार्रवाई:

`withdrawFunds` प्रतिक्रियाओं को पार्स करने वाले कोड का ऑडिट करें।
अतिरिक्त `approval_request_id` फ़ील्ड को स्वीकार करने और पूर्णता को अनुमोदन-नियंत्रित मानने के लिए पार्सिंग को अपडेट करें।