संवेदनशील दायरे की पुष्टि

अगर आपका ऐप्लिकेशन, Google के उपयोगकर्ताओं का डेटा ऐक्सेस करने के लिए, Google API इस्तेमाल करने की अनुमति मांगता है, तो आपको पुष्टि की प्रक्रिया पूरी करनी पड़ सकती है. ऐसा आपको अपने ऐप्लिकेशन को पहली बार सार्वजनिक तौर पर उपलब्ध कराने से पहले करना होगा.

यह ज़रूरी शर्त आपके ऐप्लिकेशन पर लागू होती है या नहीं, यह मुख्य रूप से दो बातों पर निर्भर करता है:

1. उपयोगकर्ता के डेटा का टाइप, जिसे ऐक्सेस किया जा रहा है. जैसे, सार्वजनिक प्रोफ़ाइल की जानकारी, कैलेंडर एंट्री, Drive में मौजूद फ़ाइलें, सेहत और फ़िटनेस से जुड़ा कुछ डेटा वगैरह.
2. आपको किस तरह का ऐक्सेस चाहिए—रीड-ओनली, रीड ऐंड राइट वगैरह.

जब किसी Google खाते से उसके डेटा को ऐक्सेस करने की अनुमति पाने के लिए OAuth 2.0 का इस्तेमाल किया जाता है, तो स्कोप नाम की स्ट्रिंग का इस्तेमाल करके यह बताया जाता है कि आपको किस तरह का डेटा ऐक्सेस करना है. अगर आपका ऐप्लिकेशन संवेदनशील या प्रतिबंधित कैटगरी में शामिल स्कोप का अनुरोध करता है, तो आपको पुष्टि की प्रक्रिया पूरी करनी होगी. हालांकि, अगर आपके ऐप्लिकेशन का इस्तेमाल अपवाद के तौर पर किया जाता है, तो आपको पुष्टि की प्रक्रिया पूरी करने की ज़रूरत नहीं है.

संवेदनशील जानकारी वाले दायरों के उदाहरणों में, Google Calendar में सेव किए गए इवेंट की जानकारी पाना, Google Contacts में नया संपर्क सेव करना या YouTube वीडियो मिटाना शामिल है. उपलब्ध स्कोप और उनकी कैटगरी के बारे में ज़्यादा जानने के लिए, अपने ऐप्लिकेशन से कॉल किए गए एपीआई एंडपॉइंट के रेफ़रंस दस्तावेज़ देखें. साथ ही, एपीआई के लिए पब्लिश की गई अनुमति से जुड़ी कोई भी गाइड देखें.

आपको ऐसे स्कोप का अनुरोध करना होगा जिनके लिए उपयोगकर्ता के डेटा के कम से कम ऐक्सेस की ज़रूरत हो. ऐसा इसलिए, ताकि उस सुविधा को उपलब्ध कराया जा सके. उदाहरण के लिए, सिर्फ़ डेटा पढ़ने वाले ऐप्लिकेशन को कॉन्टेंट पढ़ने, लिखने, और मिटाने के ऐक्सेस का अनुरोध नहीं करना चाहिए. ऐसा तब करना चाहिए, जब एपीआई और उससे जुड़े एंडपॉइंट के लिए, कम स्कोप उपलब्ध हो. Google API से मिलने वाले डेटा का इस्तेमाल, सिर्फ़ एपीआई की नीतियों के मुताबिक किया जाना चाहिए. साथ ही, इसका इस्तेमाल उसी तरह किया जाना चाहिए जैसा आपने अपने ऐप्लिकेशन की कार्रवाइयों और निजता नीति में उपयोगकर्ताओं को बताया है.

अपने ऐप्लिकेशन या किसी नई सुविधा को लॉन्च करने के प्लान में, पुष्टि की प्रक्रिया पूरी करने के लिए ज़रूरी समय को शामिल करना न भूलें. ऐसा तब करना ज़रूरी है, जब आपको नए स्कोप की ज़रूरत हो. संवेदनशील स्कोप की पुष्टि की प्रक्रिया को पूरा होने में 10 दिन लग सकते हैं. ध्यान दें कि संवेदनशील स्कोप की पुष्टि करने के अनुरोध के सबसेट के तौर पर, आपके ऐप्लिकेशन के लिए ब्रैंड की पुष्टि की जा सकती है.

---

संवेदनशील स्कोप के बारे में जानकारी

संवेदनशील स्कोप के लिए, Google से समीक्षा कराना ज़रूरी है. इसके बाद ही, कोई Google खाता ऐक्सेस दे सकता है. Google Workspace संगठन के एडमिन, संवेदनशील स्कोप के ऐक्सेस पर पाबंदी लगा सकते हैं. इससे उन OAuth क्लाइंट आईडी को ऐक्सेस नहीं मिलता जिन्हें संगठन ने साफ़ तौर पर भरोसेमंद के तौर पर मार्क नहीं किया है.

स्कोप के इस्तेमाल के बारे में जानकारी

• उन स्कोप की समीक्षा करें जिनका इस्तेमाल आपका ऐप्लिकेशन करता है या आपको करना है. अपने मौजूदा स्कोप के इस्तेमाल का पता लगाने के लिए, अपने ऐप्लिकेशन के सोर्स कोड की जांच करें. इससे आपको पता चलेगा कि अनुमति के अनुरोधों के साथ कौनसे स्कोप भेजे गए हैं.
• यह तय करें कि अनुरोध किया गया हर स्कोप, आपके ऐप्लिकेशन की सुविधा के लिए ज़रूरी हो. साथ ही, सुविधा देने के लिए कम से कम ज़रूरी अनुमतियों का इस्तेमाल किया जाए. आम तौर पर, Google API के एंडपॉइंट के लिए, प्रॉडक्ट के Google Developer पेज पर रेफ़रंस दस्तावेज़ होता है. इसमें एंडपॉइंट या उसकी खास प्रॉपर्टी को कॉल करने के लिए ज़रूरी दायरा शामिल होता है. आपका ऐप्लिकेशन जिन एपीआई एंडपॉइंट को कॉल करता है उनके लिए ऐक्सेस के ज़रूरी स्कोप के बारे में ज़्यादा जानकारी पाने के लिए, उन एंडपॉइंट के रेफ़रंस दस्तावेज़ पढ़ें.
• Google API से मिलने वाले डेटा का इस्तेमाल, सिर्फ़ एपीआई की नीतियों के मुताबिक किया जाना चाहिए. साथ ही, इसका इस्तेमाल उसी तरह किया जाना चाहिए जैसा आपने अपने ऐप्लिकेशन की कार्रवाइयों और निजता नीति में उपयोगकर्ताओं को बताया है.
• हर स्कोप के बारे में ज़्यादा जानने के लिए, एपीआई से जुड़ा दस्तावेज़ देखें. इसमें, स्कोप के संवेदनशील या प्रतिबंधित होने की जानकारी भी शामिल है.
• Cloud Console के डेटा ऐक्सेस पेज पर, अपने ऐप्लिकेशन के इस्तेमाल किए गए सभी स्कोप के बारे में बताएं. आपके तय किए गए स्कोप को संवेदनशील या पाबंदी वाली कैटगरी में बांटा जाता है, ताकि यह हाइलाइट किया जा सके कि आपको और पुष्टि करने की ज़रूरत है या नहीं.
• अपने इंटिग्रेशन में इस्तेमाल किए गए डेटा से मैच करने वाला सबसे सही स्कोप ढूंढें. साथ ही, उसके इस्तेमाल को समझें और फिर से पुष्टि करें कि टेस्ट एनवायरमेंट में सब कुछ अब भी काम कर रहा है. इसके बाद, पुष्टि के लिए सबमिट करने की तैयारी करें.

---

पुष्टि की प्रक्रिया के लिए तैयारी करने का तरीका

Google API की मदद से डेटा ऐक्सेस करने का अनुरोध करने वाले सभी ऐप्लिकेशन को, ब्रैंड की पुष्टि करने के लिए ये चरण पूरे करने होंगे:

1. पुष्टि करें कि आपका ऐप्लिकेशन, पुष्टि करने की ज़रूरी शर्तों के अपवाद सेक्शन में दिए गए किसी भी मामले में शामिल न हो.
2. पक्का करें कि आपका ऐप्लिकेशन, उससे जुड़े एपीआई या प्रॉडक्ट की ब्रैंडिंग से जुड़ी ज़रूरी शर्तों का पालन करता हो. उदाहरण के लिए, Google साइन-इन के स्कोप के लिए, ब्रैंडिंग के दिशा-निर्देश देखें.
3. Google Search Console में जाकर, अपने प्रोजेक्ट के अनुमति वाले डोमेन के मालिकाना हक की पुष्टि करें. ऐसे Google खाते का इस्तेमाल करें जो आपके API Console प्रोजेक्ट से मालिक या एडिटर के तौर पर जुड़ा हो.
4. पक्का करें कि OAuth के लिए सहमति देने वाली स्क्रीन पर मौजूद ब्रैंडिंग की सारी जानकारी, ऐप्लिकेशन की पहचान को सटीक तरीके से दिखाती हो. जैसे, ऐप्लिकेशन का नाम, सहायता पाने के लिए ईमेल पता, होम पेज का यूआरआई, निजता नीति का यूआरआई वगैरह.

ऐप्लिकेशन के होम पेज से जुड़ी ज़रूरी शर्तें

पक्का करें कि आपका होम पेज इन ज़रूरी शर्तों को पूरा करता हो:

• आपकी साइट का होम पेज सार्वजनिक तौर पर ऐक्सेस किया जा सकता हो. ऐसा न हो कि इसे सिर्फ़ वे लोग ऐक्सेस कर पाएं जिन्होंने आपकी साइट पर लॉग इन किया है.
• यह साफ़ तौर पर पता चलना चाहिए कि आपका होम पेज, समीक्षा के लिए सबमिट किए गए ऐप्लिकेशन के लिए कितना काम का है.
• Google Play Store पर आपके ऐप्लिकेशन की लिस्टिंग या उसके Facebook पेज के लिंक, ऐप्लिकेशन के मान्य होम पेज नहीं माने जाते.

ऐप्लिकेशन की निजता नीति के लिंक से जुड़ी ज़रूरी शर्तें

पक्का करें कि आपके ऐप्लिकेशन की निजता नीति इन ज़रूरी शर्तों के मुताबिक हो:

• निजता नीति, उपयोगकर्ताओं को दिखनी चाहिए. साथ ही, इसे आपके ऐप्लिकेशन के होम पेज वाले डोमेन पर ही होस्ट किया जाना चाहिए. इसके अलावा, इसे Google API Console की OAuth सहमति वाली स्क्रीन से लिंक किया जाना चाहिए. ध्यान दें कि होम पेज पर, ऐप्लिकेशन के फ़ंक्शन की जानकारी के साथ-साथ निजता नीति और सेवा की शर्तों के लिंक भी शामिल होने चाहिए. हालांकि, सेवा की शर्तों के लिंक शामिल करना ज़रूरी नहीं है.
• निजता नीति में यह बताना ज़रूरी है कि आपका ऐप्लिकेशन, Google उपयोगकर्ता के डेटा को कैसे ऐक्सेस, इस्तेमाल, सेव या शेयर करता है. आपको Google उपयोगकर्ता के डेटा का इस्तेमाल, सिर्फ़ उन कामों के लिए करना चाहिए जिनके बारे में आपने अपनी पब्लिश की गई निजता नीति में जानकारी दी है.

ब्रैंड की पुष्टि के लिए अपना ऐप्लिकेशन सबमिट करने का तरीका

Google Cloud Console प्रोजेक्ट, आपके सभी Cloud Console संसाधनों को व्यवस्थित करता है. किसी प्रोजेक्ट में, उससे जुड़े Google खातों का एक सेट होता है. इन खातों के पास प्रोजेक्ट से जुड़े काम करने की अनुमति होती है. साथ ही, इसमें चालू किए गए एपीआई का एक सेट और उन एपीआई के लिए बिलिंग, पुष्टि, और निगरानी की सेटिंग होती हैं. उदाहरण के लिए, किसी प्रोजेक्ट में एक या उससे ज़्यादा OAuth क्लाइंट हो सकते हैं. साथ ही, उन क्लाइंट के इस्तेमाल के लिए एपीआई कॉन्फ़िगर किए जा सकते हैं. इसके अलावा, OAuth के लिए सहमति देने वाली स्क्रीन को कॉन्फ़िगर किया जा सकता है. यह स्क्रीन, उपयोगकर्ताओं को आपके ऐप्लिकेशन को ऐक्सेस करने की अनुमति देने से पहले दिखती है.

अगर आपका कोई OAuth क्लाइंट प्रोडक्शन के लिए तैयार नहीं है, तो हमारा सुझाव है कि आप उसे उस प्रोजेक्ट से मिटा दें जिसकी पुष्टि का अनुरोध किया जा रहा है. क्लाइंट पेज में जाकर, ऐसा किया जा सकता है.

पुष्टि के लिए सबमिट करने के लिए, यह तरीका अपनाएं:

1. पक्का करें कि आपका ऐप्लिकेशन, Google API की सेवा की शर्तों और Google API सेवाओं की उपयोगकर्ता के डेटा से जुड़ी नीति का पालन करता हो.
2. अपने Cloud Console में, प्रोजेक्ट से जुड़े खातों के मालिक और एडिटर की भूमिकाओं को अप-टू-डेट रखें. साथ ही, OAuth की सहमति वाली स्क्रीन पर, उपयोगकर्ता की सहायता के लिए उपलब्ध ईमेल पता और डेवलपर की संपर्क जानकारी को भी अप-टू-डेट रखें. इससे यह पक्का होता है कि आपकी टीम के सही सदस्यों को किसी भी नई ज़रूरी शर्त की सूचना मिले.
3. Cloud Console OAuth ब्रैंडिंग पेज पर जाएं.
4. प्रोजेक्ट सिलेक्टर बटन पर क्लिक करें.

5. इसके बाद, आपको इनमें से चुनें डायलॉग बॉक्स दिखेगा. इसमें अपना प्रोजेक्ट चुनें. अगर आपको अपना प्रोजेक्ट नहीं मिल रहा है, लेकिन आपको अपना प्रोजेक्ट आईडी पता है, तो अपने ब्राउज़र में इस फ़ॉर्मैट में यूआरएल बनाया जा सकता है:

   https://console.developers.google.com/auth/branding?project=[PROJECT_ID]
   

   [PROJECT_ID] को उस प्रोजेक्ट आईडी से बदलें जिसका आपको इस्तेमाल करना है.

6. ब्रैंडिंग पेज पर, अपने ऐप्लिकेशन की ब्रैंडिंग की जानकारी दें. इसमें ऐप्लिकेशन का नाम, लोगो, डेवलपर की संपर्क जानकारी, और काम के लिंक शामिल हैं. आपके किए गए सभी बदलाव, ड्राफ़्ट ब्रैंडिंग के तौर पर सेव हो जाते हैं.

7. समीक्षा की प्रोसेस शुरू करने के लिए, ब्रैंडिंग की पुष्टि करें बटन पर क्लिक करें. आम तौर पर, अपने-आप होने वाली समीक्षा कुछ मिनटों में पूरी हो जाती है.

8. आकलन पूरा होने के बाद, स्टेटस देखें. अगर बदलावों को अनुमति मिल जाती है, तो स्टेटस बदलकर पब्लिश करने के लिए तैयार हो जाता है. अगर अपने-आप होने वाली पुष्टि की सुविधा काम नहीं करती है, तो आपको पता चली समस्याओं की जानकारी दिखेगी. इसके बाद, उन्हें ठीक किया जा सकता है या मैन्युअल समीक्षा का अनुरोध किया जा सकता है.

9. नई ब्रैंडिंग को लाइव करने के लिए, ब्रैंडिंग पब्लिश करें बटन पर क्लिक करें.

10. अगर आपके ऐप्लिकेशन को संवेदनशील या प्रतिबंधित दायरों के लिए भी पुष्टि की ज़रूरत है, तो OAuth पुष्टि केंद्र पर जाएं. यहां आपको डेटा ऐक्सेस करने की स्थिति को ट्रैक करने और मांगी गई अतिरिक्त जानकारी देने का विकल्प मिलेगा. जैसे, ऐप्लिकेशन को इस्तेमाल करने का तरीका बताने वाला वीडियो. ध्यान दें कि डेटा ऐक्सेस करने की पुष्टि का अनुरोध करने से पहले, आपके पास ब्रैंडिंग का पब्लिश किया गया स्टेटस होना चाहिए.

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

12. अपने ऐप्लिकेशन में मौजूद सुविधाओं से जुड़े किसी भी दस्तावेज़ के ज़्यादा से ज़्यादा तीन लिंक दें.

13. इसके बाद के चरणों में, अपने ऐप्लिकेशन के बारे में मांगी गई कोई भी अतिरिक्त जानकारी दें.

    1. अनुरोध किए गए हर संवेदनशील स्कोप के लिए, पूरी जानकारी दें. साथ ही, यह भी बताएं कि कम संवेदनशील स्कोप का इस्तेमाल क्यों नहीं किया जा सकता. उदाहरण के लिए: "मेरा ऐप्लिकेशन, https://www.googleapis.com/auth/calendar का इस्तेमाल करके, मेरे ऐप्लिकेशन की शेड्यूल करने वाली स्क्रीन पर उपयोगकर्ता का Google Calendar डेटा दिखाएगा. इससे उपयोगकर्ता, मेरे ऐप्लिकेशन के ज़रिए अपने शेड्यूल मैनेज कर सकते हैं और बदलावों को अपने Google Calendar के साथ सिंक कर सकते हैं."
    2. एक ऐसा वीडियो तैयार करें जिसमें पूरी जानकारी दी गई हो कि कोई उपयोगकर्ता, अनुरोध किए गए स्कोप को कैसे ऐक्सेस करता है और उनकी अनुमति कैसे देता है. साथ ही, ऐप्लिकेशन में अनुमति दिए गए संवेदनशील और प्रतिबंधित स्कोप के इस्तेमाल के बारे में पूरी जानकारी दी गई हो. वीडियो को YouTube Studio पर अपलोड करें और उसकी विज़िबिलिटी को सबके लिए मौजूद नहीं के तौर पर सेट करें. आपको YouTube लिंक फ़ील्ड में, डेमो वीडियो का लिंक देना होगा.
       1. OAuth के इस्तेमाल की अनुमति देने की प्रोसेस को अंग्रेज़ी में दिखाएं. इसमें सहमति देने का फ़्लो और Google साइन-इन का इस्तेमाल करने पर, साइन-इन का फ़्लो शामिल है.
       2. यह दिखाएं कि OAuth के लिए सहमति देने वाली स्क्रीन पर, ऐप्लिकेशन का नाम सही तरीके से दिख रहा है.
       3. यह दिखाएं कि OAuth की सहमति वाली स्क्रीन के ब्राउज़र पता बार में, आपके ऐप्लिकेशन का OAuth क्लाइंट आईडी सही तरीके से शामिल है.
       4. डेटा का इस्तेमाल कैसे किया जाएगा, यह दिखाने के लिए उस फ़ंक्शन को चलाकर दिखाएं जो आपके अनुरोध किए गए हर संवेदनशील स्कोप से चालू होता है.

ब्रैंडिंग पब्लिश करने या डेटा ऐक्सेस करने का अनुरोध सबमिट करने के बाद, Google की भरोसा और सुरक्षा टीम, ईमेल के ज़रिए आपसे संपर्क कर सकती है. इस ईमेल में, आपसे कोई अतिरिक्त जानकारी मांगी जा सकती है या आपको कुछ और चरणों को पूरा करने के लिए कहा जा सकता है. ज़्यादा जानकारी के अनुरोधों के लिए, डेवलपर की संपर्क जानकारी सेक्शन में अपने ईमेल पते और OAuth के लिए सहमति देने वाली स्क्रीन पर सहायता ईमेल देखें. अपने प्रोजेक्ट की समीक्षा की मौजूदा स्थिति की पुष्टि करने के लिए, प्रोजेक्ट के ब्रैंडिंग या पुष्टि केंद्र वाले पेज भी देखे जा सकते हैं. इसमें यह भी शामिल है कि आपके जवाब का इंतज़ार करते समय, समीक्षा की प्रोसेस को रोका गया है या नहीं.

पुष्टि की ज़रूरी शर्तों के अपवाद

अगर आपके ऐप्लिकेशन का इस्तेमाल, यहां दिए गए सेक्शन में बताई गई किसी भी स्थिति में किया जाएगा, तो आपको उसे समीक्षा के लिए सबमिट करने की ज़रूरत नहीं है.

निजी इस्तेमाल के लिए

इसका एक उदाहरण यह है कि अगर आपके ऐप्लिकेशन का इस्तेमाल सिर्फ़ आप करते हैं या आपके ऐप्लिकेशन का इस्तेमाल सिर्फ़ कुछ लोग करते हैं और वे सभी लोग आपको व्यक्तिगत तौर पर जानते हैं. ऐसा हो सकता है कि आपको और आपके कुछ उपयोगकर्ताओं को 'ऐप्लिकेशन की पुष्टि नहीं हुई' स्क्रीन को पार करके, अपने निजी खातों को ऐप्लिकेशन का ऐक्सेस देने में कोई परेशानी न हो.

डेवलपमेंट, टेस्टिंग या स्टेजिंग टियर में इस्तेमाल किए गए प्रोजेक्ट

Google OAuth 2.0 की नीतियों का पालन करने के लिए, हमारा सुझाव है कि आप टेस्टिंग और प्रोडक्शन एनवायरमेंट के लिए अलग-अलग प्रोजेक्ट बनाएं. हमारा सुझाव है कि आप अपने ऐप्लिकेशन की पुष्टि कराने का अनुरोध सिर्फ़ तब सबमिट करें, जब आपको अपना ऐप्लिकेशन Google खाते का इस्तेमाल करने वाले सभी उपयोगकर्ताओं के लिए उपलब्ध कराना हो. इसलिए, अगर आपका ऐप्लिकेशन डेवलपमेंट, टेस्टिंग या स्टेजिंग फ़ेज़ में है, तो पुष्टि करने की ज़रूरत नहीं है.

अगर आपका ऐप्लिकेशन डेवलपमेंट या टेस्टिंग के फ़ेज़ में है, तो पब्लिश करने की स्थिति को टेस्टिंग की डिफ़ॉल्ट सेटिंग में छोड़ा जा सकता है. इस सेटिंग का मतलब है कि आपका ऐप्लिकेशन अब भी डेवलपमेंट फ़ेज़ में है. यह सिर्फ़ उन उपयोगकर्ताओं के लिए उपलब्ध है जिन्हें आपने टेस्ट यूज़र की सूची में जोड़ा है. आपको उन Google खातों की सूची मैनेज करनी होगी जो आपके ऐप्लिकेशन को डेवलप करने या उसकी जांच करने में शामिल हैं.

सिर्फ़ सेवा के मालिकाना हक वाला डेटा

अगर आपका ऐप्लिकेशन सिर्फ़ अपना डेटा ऐक्सेस करने के लिए सेवा खाते का इस्तेमाल करता है और वह उपयोगकर्ता के Google खाते से जुड़े किसी भी डेटा को ऐक्सेस नहीं करता है, तो आपको पुष्टि के लिए अनुरोध सबमिट करने की ज़रूरत नहीं है.

सेवा खातों के बारे में जानने के लिए, Google Cloud के दस्तावेज़ में सेवा खाते देखें. सेवा खाते का इस्तेमाल करने के तरीके के बारे में जानने के लिए, सर्वर से सर्वर ऐप्लिकेशन के लिए OAuth 2.0 का इस्तेमाल करना लेख पढ़ें.

सिर्फ़ अंदरूनी इस्तेमाल के लिए

इसका मतलब है कि ऐप्लिकेशन का इस्तेमाल सिर्फ़ आपके Google Workspace या Cloud Identity संगठन के लोग करते हैं. प्रोजेक्ट पर संगठन का मालिकाना हक होना चाहिए. साथ ही, OAuth के लिए सहमति देने वाली स्क्रीन को संगठन के अंदर के उपयोगकर्ता टाइप के लिए कॉन्फ़िगर करना ज़रूरी है. इस मामले में, आपके ऐप्लिकेशन को संगठन के एडमिन से अनुमति लेनी पड़ सकती है. ज़्यादा जानकारी के लिए, Google Workspace के लिए ध्यान देने वाली अन्य बातें लेख पढ़ें.

• सार्वजनिक और संगठन के अंदर इस्तेमाल होने वाले ऐप्लिकेशन के बारे में ज़्यादा जानें.
• अपने ऐप्लिकेशन को संगठन के अंदरूनी इस्तेमाल के लिए मार्क करने का तरीका जानने के लिए, अक्सर पूछे जाने वाले सवाल मैं अपने ऐप्लिकेशन को संगठन के अंदरूनी इस्तेमाल के लिए कैसे मार्क करूं? पर जाएं

पूरे डोमेन के लिए इंस्टॉल करना

अगर आपको अपने ऐप्लिकेशन को सिर्फ़ Google Workspace या Cloud Identity संगठन के उपयोगकर्ताओं के लिए उपलब्ध कराना है और हमेशा पूरे डोमेन के लिए इंस्टॉल करने की सुविधा का इस्तेमाल करना है, तो आपके ऐप्लिकेशन को ब्रैंड की पुष्टि करने की ज़रूरत नहीं होगी. हालांकि, अगर आपका ऐप्लिकेशन प्रतिबंधित या संवेदनशील स्कोप का इस्तेमाल करता है, तो ऐप्लिकेशन की पुष्टि करना ज़रूरी है. ऐसा इसलिए है, क्योंकि डोमेन-वाइड इंस्टॉलेशन की मदद से, डोमेन एडमिन तीसरे पक्ष और संगठन के ऐप्लिकेशन को आपके उपयोगकर्ताओं का डेटा ऐक्सेस करने की अनुमति दे सकता है. सिर्फ़ संगठन के एडमिन ही, ऐप्लिकेशन को अनुमति वाली सूची में जोड़ सकते हैं, ताकि उनके डोमेन में इसका इस्तेमाल किया जा सके.

अपने ऐप्लिकेशन को पूरे डोमेन में इंस्टॉल करने का तरीका जानने के लिए, अक्सर पूछे जाने वाले सवालों की सूची में जाएं. इसके लिए, मेरे ऐप्लिकेशन में किसी दूसरे Google Workspace डोमेन के काम से जुड़े खातों वाले उपयोगकर्ता हैं पर जाएं.