Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

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

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

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

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

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

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

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

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

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

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

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

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

टेबल में, एपीआई का नाम, उसका संवेदनशील स्कोप, और स्कोप में शामिल जानकारी दिखाई गई है. — **इमेज .** OAuth सहमति स्क्रीन के कॉन्फ़िगरेशन स्कोप पेज पर, संवेदनशील स्कोप का उदाहरण.

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

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

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

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

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

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

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

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

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

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

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

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

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

पक्का करें कि आपका ऐप्लिकेशन, Google API की सेवा की शर्तों और Google API सेवाओं की उपयोगकर्ता के डेटा से जुड़ी नीति का पालन करता हो.
Cloud Console में, अपने प्रोजेक्ट से जुड़े खातों के मालिक और एडिटर की भूमिकाओं के साथ-साथ, OAuth सहमति स्क्रीन के उपयोगकर्ता सहायता के लिए ईमेल पते और डेवलपर की संपर्क जानकारी को अपडेट रखें. इससे यह पक्का होता है कि आपकी टीम के सही सदस्यों को, नई ज़रूरी शर्तों के बारे में सूचना मिले.
Cloud Console के OAuth ब्रैंडिंग पेज पर जाएं.
प्रोजेक्ट चुनने वाला टूल बटन पर क्लिक करें.
दिखने वाले इसमें से चुनें डायलॉग में, अपना प्रोजेक्ट चुनें. अगर आपको अपना प्रोजेक्ट नहीं मिल रहा है, लेकिन आपको अपना प्रोजेक्ट आईडी पता है, तो अपने ब्राउज़र में इस फ़ॉर्मैट में यूआरएल बनाया जा सकता है:
```
https://console.developers.google.com/auth/branding?project=[PROJECT_ID]
```
[PROJECT_ID] की जगह, वह प्रोजेक्ट आईडी डालें जिसका इस्तेमाल करना है.
ब्रैंडिंग पेज पर, अपने ऐप्लिकेशन की ब्रैंडिंग की जानकारी दें. इसमें, ऐप्लिकेशन का नाम, लोगो, डेवलपर की संपर्क जानकारी, और काम के लिंक शामिल करें. आपके किए गए सभी बदलाव, ब्रैंडिंग का ड्राफ़्ट के तौर पर सेव किए जाते हैं.
समीक्षा की प्रोसेस शुरू करने के लिए, ब्रैंडिंग की पुष्टि करें बटन पर क्लिक करें. आम तौर पर, अपने-आप होने वाली समीक्षा कुछ मिनटों में पूरी हो जाती है.
ध्यान दें: पुष्टि की प्रोसेस के दौरान, ब्रैंडिंग में बदलाव करने की अनुमति नहीं है. ब्रैंडिंग में बदलाव करने के लिए, आपको पहले रद्द करें बटन पर क्लिक करके, पुष्टि की मौजूदा प्रोसेस को रद्द करना होगा.
समीक्षा पूरी होने के बाद, स्टेटस की समीक्षा करें. अगर समीक्षा में कोई समस्या नहीं मिलती है, तो स्टेटस पब्लिश करने के लिए तैयार है में बदल जाता है. अगर अपने-आप होने वाली पुष्टि की प्रोसेस में कोई समस्या मिलती है, तो आपको पता चली समस्याओं की जानकारी दिखती है. इसके बाद, आपके पास उन्हें ठीक करने या मैन्युअल समीक्षा का अनुरोध करने का विकल्प होता है.
नई ब्रैंडिंग को लाइव करने के लिए, ब्रैंडिंग पब्लिश करें बटन पर क्लिक करें.
ध्यान दें: पुष्टि के ऐसे नतीजे जो ज़रूरी शर्तों के मुताबिक हों, सात दिनों तक मान्य होते हैं. अगर आपने इस समयावधि में पब्लिश नहीं किया, तो स्टेटस फिर से पुष्टि करनी होगी में बदल जाएगा. इसके बाद, आपको ब्रैंड की पुष्टि की प्रोसेस फिर से पूरी करनी होगी.
अगर आपके ऐप्लिकेशन के लिए, संवेदनशील या प्रतिबंधित स्कोप की पुष्टि भी ज़रूरी है, तो OAuth पुष्टि केंद्र पर जाएं. यहां आप अपने डेटा का ऐक्सेस स्टेटस ट्रैक कर सकते हैं और अनुरोध की गई कोई भी अतिरिक्त जानकारी दे सकते हैं. जैसे, डेमो वीडियो. ध्यान दें कि डेटा ऐक्सेस के लिए पुष्टि का अनुरोध करने से पहले, आपके पास ब्रैंडिंग का पब्लिश किया गया स्टेटस होना चाहिए.
अपने ऐप्लिकेशन के अनुरोध किए गए सभी स्कोप की जानकारी देने के लिए, स्कोप जोड़ें या हटाएं बटन का इस्तेमाल करें. संवेदनशील नहीं हैं सेक्शन में, Google साइन-इन के लिए ज़रूरी स्कोप का शुरुआती सेट पहले से भरा होता है. जोड़े गए स्कोप को, संवेदनशील नहीं हैं के तौर पर कैटगरी में शामिल किया जाता है, sensitive, or restricted .
अपने ऐप्लिकेशन में, संबंधित सुविधाओं के लिए काम के किसी भी दस्तावेज़ के ज़्यादा से ज़्यादा तीन लिंक दें.
इसके बाद के चरणों में, अपने ऐप्लिकेशन के बारे में अनुरोध की गई कोई भी अतिरिक्त जानकारी दें. 1. Prepare a detailed justification for each requested sensitive scope, as well as an explanation for why a narrower scope isn't sufficient. For example: "My app will use https://www.googleapis.com/auth/calendar to show a user's Google calendar data on the scheduling screen of my app. This lets users manage their schedules through my app and sync the changes with their Google calendar." 2. Prepare a video that fully demonstrates how a user initiates and grants access to the requested scopes and shows, in detail, the usage of the granted sensitive and restricted scopes in the app. Upload the video to YouTube Studio and set its Visibility as Unlisted. You need to provide a link to the demonstration video in the YouTube link field. 1. Show the OAuth grant process that users will experience, in English. This includes the consent flow and, if you use Google Sign-In, the sign-in flow. 2. Show that the OAuth consent screen correctly displays the App Name. 3. Show that the browser address bar of the OAuth consent screen correctly includes your app's OAuth client ID. 4. To show how the data will be used, demonstrate the functionality that's enabled by each sensitive scope that you request.

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

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

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

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

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

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

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

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

चेतावनी वाला मैसेज, जिसमें बताया गया है कि Google ने ऐसे ऐप्लिकेशन की पुष्टि नहीं की है जिसकी जांच की जा रही है. — **इमेज 2.** टेस्ट करने वाले व्यक्ति के लिए चेतावनी वाली स्क्रीन

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

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

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

केवल आंतरि‍क उपयोग के लि‍ए

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

सार्वजनिक और इंटरनल ऐप्लिकेशन के बारे में ज़्यादा जानें.
अक्सर पूछे जाने वाले सवालों में, अपने ऐप्लिकेशन को सिर्फ़ इंटरनल के तौर पर मार्क करने का तरीका जानें. इसके लिए, क्या मैं अपने ऐप्लिकेशन को सिर्फ़ इंटरनल के तौर पर मार्क कर सकता/सकती हूं? लेख पढ़ें.

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

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

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