Google Ads Test Account Does Not Function As Expected

[Chad Wood]

Hello,

I am attempting to utilize the Google Ads Pending Developer Token on a Test Account.
I followed this guide which states the following important details:

• " If prompted, sign in with a Google Account that isn't linked to your production Google Ads manager account. There is also a link to create a new Google Account if you need to do so."
• "While signed in to your test manager account, create a test client account."
• "Create a few test campaigns"
• "Take note of the client customer ID"
• "Use the developer token of your production manager account when making requests against the test manager account. Even if it's not approved yet, the token will still work on test accounts, including the ones just created."

I did this exactly. I've:

1. Created a new Google account for the purpose of creating a Google Ads test account - not in any way associated with out production account
   
2. Created the Google Ads Manager Test Account
3. Created a Google Ads test client account
4. Created several test campaigns
5. Used the Productions Pending Developer Token to try and query the test account

I am using the client library for Python, and I am utilizing a Google Service Account for my authentication:

Yet, when I try to run get_campaigns.py, I'm confronted with an authentication error. Here is that error:

```
Request with ID "xxxx[censored]xxxx" failed with status "UNAUTHENTICATED" and includes the following errors:    Error with message "User in the cookie is not a valid Ads user.".

```

So this makes me wonder, do I need to add the test client account to my production manager account?

Attempted to "link" the accounts using "Link an existing account" within Google Ads provides another error. Here is that error:

```
You can't link this account because the manager and client account types are not compatible.
```

So what's going on here? Am I mistaken to think the test client account and production manager account need to be linked? I also tried linking the test manager account with the production manger account, and I got the same error.

Can someone please explain what I'm going wrong? Also, to Google, there is no documentation I can find on the "manager and client account types are not compatible" error. Can we please get a page up describing what causes this?

Thanks for any help.

[Chad Wood]

My error has progressed.

Please tell me someone recognizes this. Does it have to do with me using Jupyter Notebook?

```

usage: ipykernel_launcher.py [-h] -c CUSTOMER_ID ipykernel_launcher.py: error: the following arguments are required: -c/--customer_id

An exception has occurred, use %tb to see the full traceback. SystemExit: 2

```

It is being caused by this line in the get_campaigns.py file:
args = parser.parse_args()

[Google Ads API Forum Advisor]

Hi Chad,

Thank you for reaching us out. I am Sherwin from Google Ads API support team. I hope that you are doing well today.

Since you mentioned that your implementation is Service account flow, please check this document if you implemented it properly specially if you met the prerequisites. If the error persists, please provide a complete request and response logs with request ID and request header generated on your end? You can provide it via Reply privately to the author option. If this option is not available, then send it instead on this email address googleadsa...@google.com. If you haven't enabled the logging yet, logging can be enabled by navigating to the Client libraries > Your client library (ex. Java) > Logging documentation, which you can access from this link.

Kind regards,

Sherwin Vincent Google Ads API Team

ref:_00D1U1174p._5004Q2ewsYl:ref

[Chad Wood]

@adsapi,
While researching this issue, I plugged the error code into google and did an Exact Match search. Only three results. I played around with my search and eventually found more results, but there was a trend of responses asking for replies as private messages. This trend resulted in myself not being able to find solutions, hence the need for me to post my own question.

Couldn't we keep the conversation accessible to the public, and help people who may find themselves stuck at the same place as me?

I'll get the information you asked for.

[Google Ads API Forum Advisor]

Hi Chad,

Thank you for your reply.

Interactions are sometimes made private due to the sensitive information being shared. Regarding your issue with the service account authentication, and for this "User in the cookie is not a valid Ads user." issue, this appears to be related to the NOT_ADS_USER error.

That said, could you confirm whether the user / email address you used during the service account credentials generation process is indeed one that has access to a Google Ads account?

In addition, I understand that you have opted to use the service account flow. However, we also recommend that you consider using the other authentication flows, since as also per the service account guide :

• Key Point: We strongly recommend using OAuth2 desktop app or web app flow instead of service accounts unless you need a domain-specific feature (for example, impersonation). OAuth2 desktop app and web app flows do require an initial user interaction for granting access to the account, but are much simpler to set up.
• For the OAuth2 desktop app flow, you can persist a refresh token (which never expires) to obtain a new access token whenever necessary. When using one of our client libraries, you can authorize your app by filling out a configuration file.

Best regards,

Peter Laurence Google Ads API Team

ref:_00D1U1174p._5004Q2ewsYl:ref

[Chad Wood]

Sadly, the system we're building will need to operate without human interaction. Otherwise, I'd love to take the easier option. I understand that any option for connecting to Google Ads via API (beside service accounts) would require a user to interact with the application, even if just to enter a password -- that is correct, yes?

As for the service account;

The service account was created while signed in under email address: x...@gmail.com. x...@gmail.com is also a user on the Google Ads account. However, email a...@gmail.com was utilized to create the test account. Also, the service account email is something like: marketing-se...@abcdefg.iam.gserviceaccount.com

What if I just added the service account email as a user in the test Google Ads account, will that work?

Better yet, should I be impersonating the email x...@gmail.com with the service account marketing-se...@abcdefg.iam.gserviceaccount.com?

Currently, I have 'impersonated_email' set to marketing-se...@abcdefg.iam.gserviceaccount.com
but I can change it to x...@gmail.com.

[Google Ads API Forum Advisor]

Hi Chad,

Thank you for the reply. I am also a member of the Google Ads API team and let me provide support to your concern.

To answer the below question first, yes, I can confirm that your understanding is correct. But the human interactions that are referring to the other authentication flow are allowing the OAuth2 credentials to access your Google Ads account in the browser and setting manually the refresh token to your client library, not entering password.

"Sadly, the system we're building will need to operate without human interaction. Otherwise, I'd love to take the easier option. I understand that any option for connecting to Google Ads via API (beside service accounts) would require a user to interact with the application, even if just to enter a password -- that is correct, yes?"

Also, since this is the account that x...@gmail.com that you login while configuring the service account, then to answer your question, this should be added to the test Google account that you want to access via Google Ads API. 

Let me know if you have further questions.

Regards,

Ernie John Google Ads API Team

ref:_00D1U1174p._5004Q2ewsYl:ref

[Chad Wood]

Thanks Ernie,

Just to recap, we essentially have four relevant emails:
* The main email: Used to create production ads account,
* My personal email: Was invited into all the Google Stuff by the main account.
* The Random Email I made for the purpose of creating the Test Ads account
* The Service Account email: Was

Lets just call these main, personal, random, and service account emails, respectively.
I used my personal email to create the service account a long time ago. You can see the set up by reviewing the attached photo "emails_on_service_account.png", if that's at all helpful.
You can also review the access / permissions of the Test Ads account via the attached picture "ads_test_permissions.png".

I added the personal email to the test account, as the picture shows. When running my code, I again get this error:
Request with ID "ktxOy7DGsucv2d7rnfzo3w" failed with status "UNAUTHENTICATED" and includes the following errors:    Error with message "User in the cookie is not a valid Ads user.".

Is there enough information here to help me further, or do I need to look into the logs as well?
I'm beginning to feel like there's a simple solution somewhere with permissioning, but not sure what it is.

[Google Ads API Forum Advisor]

Hi Chad,

Thank you for your response and for the additional details.

Before I raise this to the rest of our support team, could you also clarify first the below items :

• As per the prerequisites section, were you also able to setup a Google Workspace domain?
• In the first Key point section of the guide, it then says that "A service account can only impersonate users (email addresses) in the same Google Workspace"
  • Was your personal email then added as a user of the said Google Workspace?
• Lastly, could you confirm if you have also completed the steps 2 and 3 of this section (see domain wide delegation access guide)?

In the event that all these other items have been completed, let us know so our team can then raise this along with the requestId details you earlier provided.

Best regards,

Peter Laurence Google Ads API Team

ref:_00D1U1174p._5004Q2ewsYl:ref

[Chad Wood]

Alright, it's becoming more clear now.

Correct me if I am wrong, but here's what I think is going on:

    * I created the service account for API use to Google Analytics 4, and I just added the service account to the authorized users as view-only.

    * Google Ads REQUIRES that invitees accept the invitation via email. This is impossible for a service account, therefore my service account can not directly access Google Ads

    * To bypass this, I must impersonate my personal email with the service account. Impersonation requires the service account to have Domain Wide Delegation

Okay, fair enough. I checked and we don't have the admin.google.com account so that I can set up Domain Wide Delegation.
Unless I am mistaken somehow. But I don't see any indication that we have such an account.

I take it that I will need to create this admin.google.com account with an internal email, say goo...@mycompany.com.

But then I assume I must manually add the main email* and my personal email* to this new admin.google.com account, as workforce members or something?
...and after that, I should be able to see the Service Account I created in there? Then I can just give it Domain Wide Delegation?

Is this all accurate?

[Chad Wood]

adding to my prior message:

Can I perform this task (Domain Wide Delegation) with the Essentials Starter Edition of Workspace?

I just signed up for that version. But now I'm at a roadblock. The main email*, associated with our Ads account, Firebase, GA4, etc... is an @gmail domain email. However, the workspace says I can only add users via internal emails.

How do I now associate the existing accounts (all @gmail) with this workspace so that I can utilize the Service Account to access Google Ads?

[Chad Wood]

Well, I just got it working via OAUTH2. Like I said though, it won't make sense for us to use this method long-term. The program will run automatically every day, and while it may not take much effort to perform this one little manual task every day -- Lots of little manual tasks add up into intense workloads, eventually.

I'll use OAUTH2 for debugging, testing, building, etc for the time being. Can someone help me figure out the issue above though? I still don't understand how to use this new workspace if I can't add our Ads account because it was made with an @gmail email.

[Google Ads API Forum Advisor]

Hi Chad,

Thank you for getting back to us. I work with Peter and allow me to assist you here. I hope you are doing well today.

Please see my response to your query below.

1.) Alright, it's becoming more clear now.

Correct me if I am wrong, but here's what I think is going on:

   * I created the service account for API use to Google Analytics 4, and I just added the service account to the authorized users as view-only.

   * Google Ads REQUIRES that invitees accept the invitation via email. This is impossible for a service account, therefore my service account can not directly access Google Ads

   * To bypass this, I must impersonate my personal email with the service account. Impersonation requires the service account to have Domain Wide Delegation

 

Okay, fair enough. I checked and we don't have the admin.google.com account so that I can set up Domain Wide Delegation.

Unless I am mistaken somehow. But I don't see any indication that we have such an account.

I take it that I will need to create this admin.google.com account with an internal email, say goo...@mycompany.com.

But then I assume I must manually add the main email* and my personal email* to this new admin.google.com account, as workforce members or something?

...and after that, I should be able to see the Service Account I created in there? Then I can just give it Domain Wide Delegation?

Is this all accurate?
 

• For this, Yes, I confirm that your understanding is correct. However, you need to follow these Prerequisites.

2.)adding to my prior message:

Can I perform this task (Domain Wide Delegation) with the Essentials Starter Edition of Workspace?

I just signed up for that version. But now I'm at a roadblock. The main email*, associated with our Ads account, Firebase, GA4, etc... is an @gmail domain email. However, the workspace says I can only add users via internal emails.

How do I now associate the existing accounts (all @gmail) with this workspace so that I can utilize the Service Account to access Google Ads?
 

•  I confirm that this is true that you can't use @gmail domain email to use service account authentication. Having a workspace account is the requirement.

3.) Well, I just got it working via OAUTH2. Like I said though, it won't make sense for us to use this method long-term. The program will run automatically every day, and while it may not take much effort to perform this one little manual task every day -- Lots of little manual tasks add up into intense workloads, eventually.
 

I'll use OAUTH2 for debugging, testing, building, etc for the time being. Can someone help me figure out the issue above though? I still don't understand how to use this new workspace if I can't add our Ads account because it was made with an @gmail email.
 

• This is recommended to use authentication. We strongly recommend using OAuth2 desktop app or web app flow instead of service accounts unless you need a domain-specific feature (for example, impersonation). OAuth2 desktop app and web app flows do require an initial user interaction for granting access to the account, but are much simpler to set up. For the OAuth2 desktop app flow, you can persist a refresh token (which never expires) to obtain a new access token whenever necessary. When using one of our client libraries, you can authorize your app by filling out a configuration file.

Regards,

Darwin Google Ads API Team

ref:_00D1U1174p._5004Q2ewsYl:ref

[Chad Wood]

Thanks Adsapi,

I guess I am confused then. My company already established a Google Ads account using an @gmail email account. They weren't required to comply with workspace requirements when they created the Ads account. Same goes for GTM, GA4, and Firebase. Our presence on these platforms is already established -- using @gmail, mind you.

So what are my options for linking all of this into a workspace? Do we need to restart from scratch? That would be quite troublesome.

[Chad Wood]

Based on our conversion, it appears that I do have the domain specific requirement of impersonation.

Are we out of luck?

[Chad Wood]

Alright, I found this information on Stack:

You should write your code to anticipate the possibility that a granted token might no longer work. A token might stop working for one of these reasons: The user has revoked access. The token has not been used for six months. The user account has exceeded a certain number of token requests. There is currently a 25-token limit per Google user account. If a user account has 25 valid tokens, the next authentication request succeeds, but quietly invalidates the oldest outstanding token without any user-visible warning. (from developers.google.com/accounts/docs/OAuth2) 

I didn't realize that once I authenticate for the first time, it'll practically keep me authenticated for as long as I need (within the above confinements).
So, I was wrong... I guess I do not need impersonation. OAuth2 should work just fine.

I just have one remaining questions:

1. This question, from two comments up: "So what are my options for linking all of this into a workspace? Do we need to restart from scratch? That would be quite troublesome." I'd still like to know the solution to this, as we may like to use the workspace for other reasons in the future. Are we stuck with the only option of restarting?

[Google Ads API Forum Advisor]

Hi Chad,

Thank you for your reply.

Yes, the other authentication flows should be sufficient for your app and as long as the conditions mentioned in this guide are avoided. However, should it ever expire, you can simply follow this configuration guide to recreate the refresh token.

Moving forward to your remaining clarification, you may refer to my response below :

So what are my options for linking all of this into a workspace? Do we need to restart from scratch? That would be quite troublesome." I'd still like to know the solution to this, as we may like to use the workspace for other reasons in the future. Are we stuck with the only option of restarting?

If the @gmail account you are referring to is an email address or user that is associated or has access to your MCC/manager account, you can setup your OAuth2 flow by first creating the client ID and client secret, while logged in as that @gmail account. You can then follow this configuration guide in order to supply the credentials and refresh token into a file that your application can read when performing the authentication of your API requests.

Having these credentials made by a user or email address associated to your MCC/manager account should then allow you to perform API requests to any of the sub accounts under your MCC/manager account's hierarchy.

On the other hand, if the credentials are made by a user or email address that only has access to a single sub-account, those credentials can then only be used to perform actions on that sub account.

Best regards,

Peter Laurence Google Ads API Team

ref:_00D1U1174p._5004Q2ewsYl:ref

[Chad Wood]

Thanks Peter, but I'm not sure I'm following.

I would like to address how the companies Google Ads, Firebase, Google Analytics, and Google Tag Manager account were all made with an email like myco...@gmail.com
They were able to establish all of these environments and build atop of them without being required comply with the workspace requirement that emails are internal. They're all using myco...@gmail.com with no 'governing body,' so to speak.

So now we have all of these different tools under the email address myco...@gmail.com.

If I want to link all of these under a governing body, like a workspace, and utilize the benefits of a workspace -- how can we do that without rebuilding everything over this email issue?
I can't add myco...@gmail.com to the newly created workspace because its not an @mycompany.com email.

-- Are you perhaps suggesting that I make some kind of manager account, say goo...@mycompany.com and link myco...@gmail.com to it? That's exactly what I tried doing with the workspace, but it would not allow this.

[Google Ads API Forum Advisor]

Hi Chad,

Hope you are doing fine. This is Carmela from the Google Ads API team as well. Thank you for getting back to us.

With regards to your concerns, you may see the below items:

• "They were able to establish all of these environments and build atop of them without being required comply with the workspace requirement that emails are internal. They're all using myco...@gmail.com with no 'governing body,' so to speak." - As for this, there is a chance that you do,'t need to use the Google workspace and that is the Oauth flows instead of service accounts unless you need a domain-specific feature (for example, impersonation), then Google workspace is needed. OAuth2 desktop app and web app flows do require an initial user interaction for granting access to the account, but are much simpler to set up.
• "So now we have all of these different tools under the email address myco...@gmail.com. If I want to link all of these under a governing body, like a workspace, and utilize the benefits of a workspace -- how can we do that without rebuilding everything over this email issue? I can't add myco...@gmail.com to the newly created workspace because its not an @mycompany.com email." - Could you confirm if what you mean by this is you want Firebase, Google Analytics, and Google Tag Manager account to use a workspace as well? If yes, then kindly note that our team can't comment on this as we can only provide the insights in the Google Ads API perspective. That said, I would suggest reaching out to their support team instead as they are the ones who can confirm if these accounts can also utilize a workspace.
• "-- Are you perhaps suggesting that I make some kind of manager account, say goo...@mycompany.com and link myco...@gmail.com to it? That's exactly what I tried doing with the workspace, but it would not allow this." - Since this is more related to the workspace, then I would suggest reaching out to the Google Workspace Support team via this link as they are better equipped to provide guidance to you. There is an icon on the lower-left part of the UI where you will redirected saying "Hi there 👋 What brings you to Google Workspace today?".

Regards,

Carmela Google Ads API Team

ref:_00D1U1174p._5004Q2ewsYl:ref

[Chad Wood]

Well, there is another limitation I am now running into and I don't think this was considered in our conversation.

It's been awhile, so here's the recap/update:

• My company used a gmail to create our accounts for google applications, like Google Ads. We've also verified ownership of our domains with this gmail. Lets call it myco...@gmail.com
• My company has made itself dependent on the accounts created via myco...@gmail.com; now utilized for Google Ads, GA4, Firebase, and several other services
• Because my company decided to set everything up on myco...@gmail.com, we are not eligible for using a Google Workspace. This is because Google Workspace requires a private email domain to sign-up.
• I need to access Google Ads programmatically for automatic daily data retrieval and custom reporting.
• Google Ads doesn't allow service accounts to be added to it, thereby requiring impersonation [of a human user] to utilize service accounts in Google Ads
• Because we can't utilize Google Workspace, we are thus required to utilize OAUTH2 instead of service accounts to authorize my API calls to Google Ads
  

Now, to set up OAUTH, we need to navigate here and set up the consent screen for the "initial" authorization. After that, we can retrieve a refresh token and be on our way toward automation. Though, here's the caveat; creating an "internal" app also requires Google Workspace.

So, this means we must create the app as "external" even though it is technically for internal use only. It's custom reporting.

From what I understand, and according to the docs;

"A Google Cloud Platform project with an OAuth consent screen configured for an external user type and a publishing status of "Testing" is issued a refresh token expiring in 7 days"

I am currently dealing with this problem. The refresh token automatically expires after 7 days. I can not "publish"/"verify" the app to get would this, as that would make the app publicly available. This would be a security concern.

This makes me feel as though we are back at square one. Is my only option to migrate all existing applications to a new google account, all over the email used to create the account?
This would likely be very messy, and I'd hope there's a solution to avoid needing this.

I was able to create a Google Workspace with an internal email, but it requires that I verify the domain to "unlock" the features I need. If I understand correctly though, verifying the domain would be a takeover, right? Thereby likely breaking applications on the myco...@gmail.com account. This is no good as well.

What can I do here?

[Google Ads API Forum Advisor]

Hi Chad,

Thank you for getting back to us. I hope you are doing well today.

Moving forward to your concern about the refresh token automatically expires after 7 days and cannot "publish"/"verify". Allow me to raise this issue to my team for further checking. Rest assured that we will provide updates when become available.
 

Regards,

Darwin Google Ads API Team

ref:_00D1U1174p._5004Q2ewsYl:ref

[Chad Wood]

Thanks Darwin,

In the meantime, I had a colleague propose just publishing the app and making the link to access it super obscure. The idea is that, theoretically, nobody would ever find it and we could still have our business needs met. This obviously does not utilize your technology in the way that it was meant to be utilized, and therefore I worry about what kind of security implications could arise as a result.

I've informed them that we are waiting on a response from your team members. For now though, can you help me better understand why this proposal of"publishing" our internal app should or should not be done? I'm curious what you can tell me about this idea.

Thanks,

[Google Ads API Forum Advisor]

Hello,

This case has been escalated to me.

I'm looking into the best way to proceed here. My team generally doesn't have full expertise on the OAuth sign up flow specifically; we focus in the steps after that, once you're using the API.

But I am trying to find the right person to get in touch with who would understand your situation better so I can try to find the best way for you to proceed here. I will let you know once I have learned more and have some recommendation for what else you can try.

Regards,
Mike, Google Ads API Team

ref:_00D1U1174p._5004Q2ewsYl:ref

[Chad Wood]

Thanks Mike. I'll keep an eye on this thread until then.

[Chad Wood]

+ checking for update

[Google Ads API Forum Advisor]

Hello,

All I've been able to discover so far is that the requirement for you to get a new refresh token every week may be associated with you being in some sort of "testing" mode, rather than a "production" mode. As I'm not terribly familiar with that interface, I wouldn't know where to look to change that setting, but it might be something you could look into.

I will try to get more specific suggestions if I can find someone who knows more about OAuth internally. I apologize for the slow progress here, as it's outside my area of expertise.

[Chad Wood]

Thanks, and you are correct. What you describe is the issue exactly, please just read over my message stamped for Oct 17, 2022, 3:12:03 PM.

We know why this is happening. The need to get a new refresh token every 7 days IS because the app is in 'testing' and not in 'production'.
See, we can not make a production app because we are denied access to Google Workspace.
Reason for the denial to Workspace is because we have our account set up as an @gmail account, which is blocked from Google Workspace.
We can't just start over, as our @gmail account is already deeply intertwined with the Google Ads service, GA4, Firebase, etc.

My gripe on this is that the Google Platforms allowed my colleagues to even establish a presence on the services with an @gmail in the first place. They didn't know better, and now it seems like we're just out of luck here.

I'm wondering if it would be very difficult to automate the Refresh Token retrieval process--as an alternative fix. What would you think? Is this a good idea?

[Google Ads API Forum Advisor]

Hello,

Thank you for confirming. I'm reaching out to some more extended internal contacts to try to find a solution here, and will let you know if I learn anything, or if I need any further information from you.

[Chad Wood]

Thanks! I'll stay on the lookout.

[Google Ads API Forum Advisor]

Hello,

The team is going to need some more information to completely debug. Since this support avenue is not available for external clients, I will have to serve in the middleman in this exchange. Keep in mind that I don't actually have much expertise in the OAuth console, so I will generally be providing your responses as is to the team that is helping me.

Here is the information they've provided me so far and the information they'll need from you:

Due to admin restrictions, Workspace users can be blocked from granting access to a test app. However, a gmail.com project owner should not be blocked from changing their app's publishing status due to Workspace specifically. I will definitely need more details to nail down what the issue is. If you could please ask the customer to provide clarification on what "denied access" means in relation to Google Workspace, that would be helpful. Additionally, are they trying to change their app's publishing status from the OAuth consent screen page in the cloud console? Screenshots, a copy of the error message(s), and the client ID would be very useful for debugging.

Can you provide the requested information so I can pass it along and hopefully find some kind of resolution?

Regards,
Mike, Google Ads API Team

ref:_00D1U1174p._5004Q2ewsYl:ref

[Chad Wood]

Screenshot located at the bottom of this message.

A breakdown:
We can not create an "Internal" app because we are not Google Workspace users
-> We can not become Google Workspace users because we are using @gmail emails
---> We can not convert to using internal emails because we are already deeply intertwined with the current setup as a tech company

So by what I understand, our only option is to use "External" for our app.
But that does not change the fact that this app is internal--for reporting. Therefore, we can not "Publish" the app.
Since the "External" app is "Unpublished", our refresh tokens expire every 7 days automatically.

I will privately email client id

[Chad Wood]

I just provided the client ID via private email. It's worth mentioning that this is probably not a bug--no error code, as I believe things are functioning as they were designed to.
But the design does not seem to take my edge-case into consideration. What do users do in the event that they want to create an "internal app" but have already established a lot of dependencies using a setup built with @gmail emails? It would seem the only option might be to restart our presence on the Google platform using internal emails...though this would be incredibly difficult.

[Google Ads API Forum Advisor]

Hello,

Thank you for your detailed response. I'm sharing this information with our OAuth team and working with them to try to figure out the best steps to proceed. I will let you know when I have any new information to share, or if I need more information from you.

[Chad Wood]

Thanks, I will keep a watch out until then!

[Google Ads API Forum Advisor]

Hello,

I've heard back an answer, and unfortunately, it sounds like the system is working as intended, and your understanding is perfectly accurate. There is no bug here, and you are in an unfortunate situation that wasn't really accounted for in the system's design. I know this isn't what you wanted to hear, but at least we have a definitive answer now and you can proceed forward with one of your potential backup plans.

Please don't hesitate to reach back out if you have any API specific queries; I'm sure our team will be able to help out on that front much more satisfactorily.

[Google Ads API Forum Advisor]

Hello,

I happened to bring this up with one more coworker and I have what I hope may be some good news.

If you mark your app as external (even though it is technically internal), then the following restrictions would apply:

• You would be limited to 100 total refresh tokens.
• Your app would have a warning on the OAuth consent screen stating that the app is not verified.

I believe that, in your case, neither of these restrictions should actually pose a considerable problem, since you effectively only one one refresh token that's generated at development time, and your internal users won't actually need to see the OAuth consent screen at all.

If that's the case, it sounds like marking the app as external is actually a solution to your problem. You don't need to verify your app if you don't ever plan on having external users log into the app, and you're okay with that "not verified" warning.

Upon researching more, the idea of "internal" only applies to Google Workspace because there's no way on our side to verify whether a given user is internal or external without the Google Workspace framework.

Hopefully this workaround eases some of the load on your configuration.

[Chad Wood]

Hello,

Thanks for getting back. Yes that is was I figured sadly. Honestly though, I'm happy with any solution that makes it so that the refresh token doesn't need to be retrieved every week. Security implication are a concern though, which is why I was unsure about publishing the app.

Do you know if there is a way around this?

I've already looked into automating the refresh token retrieval process. I got quite close, but there is just one roadblock here that I can not get past. It's a very technical issue;
During the OAUTH process, the user (me) picks their account from the list of Google accounts in their browser, then acknowledges that the app is unverified, and then agrees to the app permissions.
That last step, "then agrees to the app permissions" is where the magic happens.
At this stage, my browser generates a list of unlabeled data points (likely obfuscated because the protocol designers were hoping to prevent people from doing exactly this).

It looks a lot like this:
    [0, "ChR!490t-wqqnpg5nb.fjw044qh", True, True, None, False, 0, 1, 1, 0]
This blog post makes mention of the array I am talking about, "f.req", but for a different process entirely. In the blog post, "f.req" is provided different variables than in my case, so it is not very helpful.

Once the browser generates that list, it sends it to your authentication server and then your authentication server responds with a URL. That URL is already pre-setup by your server, and it contains the refresh token within it. My browser redirects to the URL and I get the refresh token printed out in my PC console.

For my case, I was able to reverse engineer most of the data points, except two. That second entry that begins with "!ChR", I can not figure how to reverse engineer its production. If I can figure this out, then I could fully automate the process of getting refresh tokens by making my program just create the array and send it to your server (same as my browser does in the manual process). Alternatively, I could set up a "macro" like protocol to interact with the authentication screens same as a user would. I don't really like this idea too much, but perhaps it is the best option.

Unless you think there is a way around making the app available to anyone with a Google account. If there is a workaround for that after publishing, then maybe that could work too.

[Google Ads API Forum Advisor]

Hello,

As for that screenshot, you are still in control of your app. It is a piece of software you are developing, so you can build whatever feature you want in it. Namely, if you build some kind of custom login system into your app, and then only provide logins to authorized users, it's not like random Internet users would be able to just access your app automatically.

I would recommend going this route rather than trying to automate fetching a refresh token. I imagine that the automation progress would be quite prone to breaking if we were to update the website in any way, and I would wager that it's designed in a complicated way to try to prevent what you're doing very intentionally. I can't help you troubleshoot that process, so I think publishing the app and building your own app authentication system is the way to go.

[Chad Wood]

What is it entailing by "your app will become available to anyone with a Google account"?
Does Google start hosting the app somewhere? In the Google Pay Market maybe? I honestly have no idea. How would an external person find my app, even if accidentally, should I choose to publish?

[Google Ads API Forum Advisor]

Hello,

Essentially, if you have a Google Workspace setup, then Google can handle some parts of the authentication for you, and ensure that only users within your Workspace domain are able to create refresh tokens.

If you aren't using that, then Google does not do any checking of this sort on our side, meaning that the burden is on you to provide your own security measures to ensure that the correct subset of users is able to log in. Remember, that what we're doing here is a workaround for your edge-case situation, and the "normal" situation for someone choosing this option would be for someone who was choosing to publish their app widely. However, in your case, where you have no intention of doing that, what this message really boils down to is that Google is not going to restrict who can create refresh tokens to only people within your Google Workspace domain. But you can still restrict that, by not sharing your client ID and client secret, and by building up your own login system.

[Chad Wood]

I see. Correct me if I’m wrong here, but I think I’m starting to understand. Practically speaking in this case, there really isn’t a difference between my my app being published versus unpublished, except that the limitations (of 100users and 7days/refresh token) are lifted. Is this right? Because I think anyone can verify themselves as it currently stands, though new users would add tally against the 100user total. So publishing isn’t really making my app available to anyone with a Google Account; that is technically already be true… right?

My system is already set up to store everything encrypted with environment variables and whatnot, so I guess I do have a “log in” already—because a user would need to log into my work environment in order to access anything in a decrypted state. 

If this is correct, then I think I was just misunderstanding due to the verbiage used on that pop up. Nobody should be able to access my app because I don’t go around distributing copies of my work environment. Is my logic accurate with all of this?

Thanks.

[Chad Wood]

What about the review process. I assume that, despite my edge-case, I will still be required to submit for “external app approval”, yes?

[Chad Wood]

Hello, just checking back on this.

I am fine with submitting the app for approval under the notion that it is for external use -- even though it is not for external use.
At the end of the day, I only care to make ends meet and keep security tight.

However, I don't want the review process to develop into myself trying to meet standards that are difficult to ascertain when the app doesn't necessarily exist in a state that makes those standards necessarily in the first place.
Like for example, I wouldn't want to spend weeks going back and forth trying to fine-tune a privacy policy page and ToS for something that only I am going to use anyway... but if it must be done then so be it. I understand our unique position may warrant unique requirements.
In all fairness, I'm not even really sure how complex the approval process is, and maybe my concern here isn't even all that aligned with reality.

That is why I ask though. Is this approval something that will be still required still? What will that entail for me?
Or can we potentially work out a custom solution given these circumstances?

Thanks,
Chad

[Google Ads API Forum Advisor]

Hello,

I'm fairly certain that you actually don't need to get your app "approved" or "verified" in order to use it for your use case. You can't generate more than 100 refresh tokens (but you only need one), and your app will show a warning on the consent screen (but you're the only one using that screen), but otherwise it should function even without going through that process.

I do not believe that you will be able to get approved given the way your app works. Using an unverified external app is the workaround.

[Chad Wood]

Thanks :) I appreciate the help.
Regarding the refresh token expiring every 7 days then. Is there no workaround on this for me?

[Chad Wood]

For reference:
https://support.google.com/cloud/answer/10311615#zippy=%2Ctesting

" Authorizations by a test user will expire seven days from the time of consent. "

[Google Ads API Forum Advisor]

Hello,

The workaround I suggested already should circumvent this limit. I have suggested that you publish your app (i.e. don't leave it in testing) which will allow refresh tokens to persist beyond 7 days. Your app will be unverified, which has some limitations (100 total refresh tokens and a warning on the OAuth consent screen), which should be acceptable for your use case. As long as you're okay with these limitations, you never have to verify your app.

[Chad Wood]

Thanks. I was confusing "verify" and "publish" as the same thing. I see my misunderstanding now and I will give this a try. Thanks for all of your help!