Hi Yasar Thank you for the detailed response. Our requirement is pretty simple - the count of app users is 1 and extract keywords on a daily basis using Azure ADF(or a simple script), from Google Ads and drop it to a database. We don't want the refresh token to expire hence have modified the publishing status to Production. We would like to leverage OAuth Playground to generate the refresh token which would be a one time activity.
Recently when we fetch the refresh token using OAuth Playground, the authorization was denied with the below error message `This app is blocked This app tried to access sensitive info in your Google Account. To keep your account safe, Google blocked this access.` which we suspect may be because the OAuth verification has not been submitted. Is our assumption correct ? If we were to go with a script(extracting the refresh token from OAuth Playground), how would we be able to fill in the below details in the consent screen? > Application home page > Application privacy notice Or should we build a web application only to get the OAuth verification approved ? Thanks & Regards Sithara On Friday, 9 December 2022 at 19:11:12 UTC+5:30 adsapi wrote: > Hi Sithara, > > Thanks for getting back to us. > > If you set the publish status to In Production > <https://support.google.com/cloud/answer/10311615#publishing-status> in > order to generate refresh tokens that persist longer than 7 days. So that > does indeed sound like the right setting for your use case. Note that we > have examples of how you can generated refresh token with our Google Ads > API client libraries here: > > > https://developers.google.com/google-ads/api/docs/samples/generate-user-credentials > > > > If you leave the project unverified, you will see an unverified warning > when you authenticate and your project will be subject to an OAuth user > quota <https://support.google.com/cloud/answer/7454865#oauth-quota>. But > if this is an internal script that will not be authenticating many > individual external users, that is normally sufficient for most developers. > However, if your app is going to be used in any of the following scenarios, > you do not need to submit it for review: > > 1. Personal Use: The app is not shared with anyone else or will be > used by fewer than 100 users (all of whom are known personally to you). > Note that your app will be subject to the unverified app screen and the > 100-user cap will be in effect. > 2. Development/Testing/Staging: If your app’s publishing status is set > to “Testing” and not “In production”, then you do not need to submit your > app for verification. Note that your app will be subject to the unverified > app screen > <https://support.google.com/cloud/answer/7454865#unverified-app-screen> > and the 100-user cap will be in effect. Learn more about Publishing > status <https://support.google.com/cloud/answer/10311615#zippy=>. > 3. Service-owned Data Only: The app only accesses its own data (using > a Service Account), and not user data (linked to a Google Account). > 4. To understand what service accounts are, see Service accounts > <https://cloud.google.com/compute/docs/access/service-accounts>. > 5. For instructions on using a service account, see Using OAuth 2.0 > for Server to Server Applications > <https://developers.google.com/identity/protocols/oauth2/service-account> > . > 6. Internal Use: The app is used only by people in your Google > Workspace or Cloud Identity organization. Note that your app will not be > subject to the unverified app screen or the 100-user cap if it's marked as > Internal. > 7. Learn more about public and internal applications > <https://support.google.com/cloud/answer/6158849#public-and-internal>. > 8. Learn how to mark your app as internal in the FAQ How can I mark my > app as internal-only? > <https://support.google.com/cloud/answer/9110914#mark-internal> > 9. Domain-wide Installation: The app is used only by Google Workspace > enterprise users. Access will depend on permission being granted by the > domain administrator. Google Workspace domain administrators are the only > ones that can add the app to an allowlist for use within their domains. > 10. To learn how to make your app a Domain-Wide Install, see My > application has users with enterprise accounts from another Google > Workspace Domain. > <https://support.google.com/cloud/answer/9110914#enterprise> > 11. SMTP/IMAP/WP: The app is used to send emails through WordPress, or > similar single-account SMTP plugins. > > > Let me know if you have any follow up questions, so that our team can > assist you further. > > Regards, > [image: Google Logo] > Yasar > Google Ads API Team > > > ref:_00D1U1174p._5004Q2h0KWQ:ref > -- -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Also find us on our blog: https://googleadsdeveloper.blogspot.com/ =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ You received this message because you are subscribed to the Google Groups "AdWords API and Google Ads API Forum" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/adwords-api?hl=en --- You received this message because you are subscribed to the Google Groups "Google Ads API and AdWords API Forum" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/adwords-api/626efc12-a0bc-4d7b-a998-d34f6a5ac7f3n%40googlegroups.com.
