The Google credential that dies in the client's first unsupervised week

The clock starts at Allow, not at handover

Work through the calendar, because it is the whole problem and it takes ten seconds.

You build a client's Google Sheets automation on Monday. You click Allow on the consent screen that morning, because that is when you need it working. You demo on Wednesday. You hand over on Friday, everything green, invoice sent.

It stops on Monday. Not because anything changed — because Google's clock started the moment you granted consent, and Google's clock runs for seven days:

Authorizations by a test user will expire seven days from the time of consent. If your OAuth client requests an offline access type and receives a refresh token, that token will also expire.

• Manage app audience, Google Cloud Console Help

From the time of consent. Not from delivery, not from first run, not from last use. So the failure does not land in the week you are still around for. It lands on the first working day of the client's first week alone with it, when the last person to touch the credential was you and the only thing they know how to do is call you.

Which apps this actually applies to

The seven-day rule has three conditions, and articles that get this wrong scare people who are not affected. From Google's developer documentation:

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, unless the only OAuth scopes requested are a subset of name, email address, and user profile […]

• Using OAuth 2.0 to access Google APIs, Google Identity documentation

External user type and Testing status and a scope beyond basic profile. All three. The exemption sounds generous until you check what falls inside it: name, email, profile. Sheets does not. Drive does not. Gmail, Calendar, Docs — none of them. Every scope an automation actually needs is outside the exemption, so the scope condition is never the one that saves you: in practice the rule is "if your consent screen says External and Testing, you have a week".

On day eight the refresh call is refused rather than the connection being silently revoked. The error is an ordinary invalid_grant, whose description one reporter posted in full: "The provided authorization grant […] or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client."

That sentence lists five possibilities. Yours is the second one. Nothing in it says so.

What n8n tells the owner instead

When the refresh is refused, n8n recognises invalid_grant specifically and produces a purpose-built message. It reads:

The credential "…" needs to be reconnected.

Access could not be refreshed because the connected account has revoked access, the refresh token expired, or the account password or permissions changed. Open the credential and reconnect it to continue.

Three named causes. The account revoked access — it did not. The password or permissions changed — they did not. The refresh token expired, which is true but reads as a fact about the token rather than a consequence of a setting, and it is the setting that will do it again next Monday.

The instruction is the part that stings: open the credential and reconnect it. Do that, and it works, and it dies again seven days later. The message describes the ritual rather than the cause.

n8n's own documentation does know the cause. Under a heading about Google Cloud apps becoming unauthorized, it states that for apps with publishing status Testing and user type External, consent and tokens expire after seven days — and then gives this resolution: "To resolve this, reconnect the app in the n8n credentials modal."

Make names the cause, then walks you into the wall

Make is better here in one respect and worse in another.

Better: its help centre ties the error string to the reason in the same breath. It shows the failure as a 400 — "Failed to verify connection […] Status Code Error: 400" — and explains underneath that "unpublished apps can only have a 7-day authorization period. After the OAuth security token expires, the connection is no longer authorized, and any module relying on it will fail." It even notes that this "affects non-Google Workspace accounts", which is a hint at the next section.

Worse: for its restricted Google services, Make requires you to build your own OAuth client — "To connect some restricted Google services, like Google Drive or Google Sheets, to Make, you need to create your own project in Google Cloud Platform and a custom OAuth client" — and its step-by-step then says, in order:

Under Audience, select External, and click Next.

Click Publish app to update the project status to In production. […]

• Connect to Google services using a custom OAuth client, Make Help Center

Follow those two instructions in sequence and you will find that the Publish app button does not respond. Make's guide never mentions the fields that make it work, because from Make's side there is nothing to mention — the requirement is Google's, and Google does not put it on the button either.

On n8n the same requirement arrives differently depending on where you run it. n8n Cloud ships managed OAuth credentials for the Google services, so there is no console work at all. Self-hosted has no such option and routes you to a custom OAuth client. So the trap is invisible to anyone who stays on n8n Cloud's managed credentials, unavoidable on Make and on self-hosted n8n — and it comes back on Cloud too, the moment somebody builds their own client to reach a scope the managed one does not cover.

The Publish button that will not say what it wants

Here is the trap that produced the best evidence in this whole story.

On Google's own developer forum, somebody opened a thread in late August because the Publish button was greyed out and the banner said only this:

Your app's OAuth configuration is incomplete. You must enter the missing information to proceed. Please visit the Branding page to finish configuring your app.

They had checked. Their post is unusually careful about it:

Just to be clear: branding verification isn't needed for this use case. There are no missing required fields on the Branding page. If I delete the client and re-add it, nothing changes. […] This happened (reproduced) 3 times in a row on 3 projects created from scratch.

• a developer, Google Developer forums, 25 August 2026

Four people replied "same here" over the next two days. The answer came from another user, and where it was hiding is the point of the section:

On the Audience page, if you hover over the grayed-out Publish button, a tooltip pops up and gives you a hint, like a secret scroll hiding behind a walkthrough wall.

Valid app name, support email, homepage url, and privacy policy url are required for switching the app to external production mode.

• another developer, same thread, 27 August 2026

Nine people, on Google's own forum, on a thread that auto-closed with no reply from Google. The requirement is real and it is enforced. Google's Branding page does say the links are "required for all external production apps" — what it never says is that the Publish button goes dead until they exist, or which fields it is waiting on. That list lives in a tooltip you have to hover a disabled button to see.

The exact shape of the gate, which matters because the folklore version is wrong:

• Of the App domain block it is homepage URL and privacy policy URL — the app name and support email the tooltip also names are the starred fields you filled on day one.
• Terms of service can stay empty.
• The homepage and privacy policy may be the same URL.
• Filling them in makes Authorized domains newly required — a second gate that opens only after you satisfy the first.
• And the Branding page saves happily with all of it blank, so nothing appears wrong until you press a button on a different tab.

The n8n forum shows the same trap from the other side. Somebody asked about it in late August and two well-regarded community members told him he did not need those fields at all. Six days later the forum's moderator corrected them — a community moderator, not n8n staff. His description is the clearest anyone has written: "The Branding page saves with the App domain section empty, so nothing looks missing until you move Publishing status to In production, and that is where Google asks for the fields."

"Just make it Internal, it's only me"

This is the shortcut everybody reaches for, and for most small operators it is not available at all.

Internal: Use this designation if your app is for use only by users in your organization. This option is only available for apps created under a Google Workspace Organization.

• Submitting your app for verification, Google Cloud Console Help

An organization resource exists for Google Workspace and Cloud Identity customers, and is created when such an account is associated with a domain you own. A personal Gmail address is neither. Cloud Identity has a free tier, so this is not strictly a question of paying for Workspace — but it is a question of owning and verifying a domain, which is a different project from the one you were doing.

And when the client does have Workspace, the same option fails in the opposite direction. If their project is set to Internal and you sign in with your own Gmail to build the automation, Google refuses you: an org_internal error is returned when authorization is requested from outside the project's organization. One community contributor on the Make forum put the rule precisely: the Internal exemption holds only "if every single person who will use the app will belong to their organization", and an agency developer authenticating with a personal account violates it.

So: no organization, no Internal. An organization you are not a member of, no Internal either.

What publishing actually costs

Publishing is the right answer, and it is worth knowing the bill before you promise a date.

Publishing an app with unverified sensitive or restricted scopes works — users see an "unverified app" warning screen, and there is a cap. That cap deserves reading twice: Google's audience page states that it "applies over the entire lifetime of the project, and it cannot be reset or changed", with a hundred new users in total. For an internal business automation with one authorising account, a hundred is not a constraint. For an agency reusing one client across many customers, it is a countdown that never resets.

If you do go for verification, Google's published timings are:

Restricted is the one to watch. Full Drive access falls there, and it drags in a third-party security assessment. That is why one person in the n8n threads was stuck between exactly two bad options: no Workspace so no Internal, and a restricted scope so no quick verification. His last word on it was a question — whether the narrower Spreadsheets scope would do instead of full Drive — and the thread closed three months later without an answer.

One honest caveat before you promise that publishing ends the problem. Google's own text supports it, and one user reported in January that their token still expired after publishing and was never answered. One unexplained datapoint does not overturn the documentation, but it is a reason to verify after the change rather than assume.

The ten-second check before you invoice

The thing that makes this manageable is that the failure is a documented consequence of a configuration, not an incident you have to wait for. You cannot query a refresh token's expiry date — Google exposes the access token's remaining life, not the refresh token's, and neither platform's documentation describes a countdown for a Testing-status Google connection. But you never need to, because the configuration tells you.

1. Open the Audience page of the Google Cloud project and read two words: the publishing status and the user type. External plus Testing, with any real scope, means seven days from each consent. That is the whole check.
2. Do it before the invoice, not after the phone call.
3. If it says Testing, publish before handover. Fill the homepage and privacy policy URLs — the same URL twice is acceptable — add the authorized domain, save, then return to the Audience page where the button is now live.
4. If the Publish button is grey, hover it. The tooltip names the fields the banner refuses to.
5. Do not promise a date if your scopes are restricted. Full Drive access means an assessment measured in weeks. Check whether a narrower scope does the job — the Spreadsheets scope instead of all of Drive, for instance — because that choice decides between three business days and several weeks.
6. Reuse one published client across clients rather than making each of them build a project. One console setup, done properly once, instead of the same trap per customer.
7. Re-run one real execution the day after publishing. One datapoint suggests publishing does not always end the expiry, and a single successful run a week later settles it for your setup.

When this is a job to hand over

Nothing here is difficult. That is exactly why it keeps happening: every individual step is a two-minute job in a console, and the failure they add up to arrives a fortnight later, at somebody who does not know any of them exist.

The distinction worth drawing is not difficulty but who carries the consequence. If you built the automation for yourself, this article is a checklist and you are done in an afternoon. If you built it for somebody else, you have shipped a device with a timer in it, and the timer goes off after you have left. That is a professional problem rather than a technical one — the client does not experience it as "the consent screen was in Testing", they experience it as "the thing they built stopped working almost immediately".

Which makes the useful version of this job an audit rather than a repair. One question decides its size, and it is not how many workflows there are: it is which scopes each console project asks for. That is what separates an afternoon in the console from a verification queue measured in weeks, and you can read it off the Audience page yourself. A good share of the n8n and Make work we take starts with a connection that has already died once and been reconnected by hand, which is the tell: somebody is performing a weekly ritual instead of changing a setting.

None of this is peculiar to Google's console. The trap that is enforced but never written down is the Publish button's field list, which exists only in a tooltip. The seven-day clock is the opposite case: Google documents it twice, Make explains it in the very step where you choose Testing, and n8n names it in its credential docs — and it still catches people, because none of that reaches the person clicking Allow during the build. A setting that is documented somewhere and invisible at the moment of choice behaves, in practice, like one nobody wrote down, and a configuration that saves cleanly is not the same as one that is finished.

Sources

• Using OAuth 2.0 to access Google APIs - Google Identity documentation, read 8 September 2026. The refresh-token expiration section, giving the three conditions under which a token expires in seven days and the narrow exemption for basic profile scopes.
• Manage app audience - Google Cloud Console Help, read 8 September 2026. Authorizations by a test user expiring seven days from the time of consent, the exemption and its limits, the hundred-test-user cap on Testing projects, the definition of In production status, the org_internal error for users outside the project's organization, and the user cap that applies over the lifetime of the project and cannot be reset.
• Manage OAuth app branding - Google Cloud Console Help, read 8 September 2026. The App Domain links and the note that they are required for all external production apps, the authorized domains rule, and the instruction to add authorized domains before the URLs that depend on them. The older answer id 10311615 redirects here, which is why pre-2025 walkthroughs describe menus that no longer exist.
• Submitting your app for verification and Verification requirements - Google Cloud Console Help, read 8 September 2026. Internal being available only to apps created under a Google Workspace organization, and the requirements on a homepage for brand verification.
• Creating and managing organization resources - Google Cloud documentation, read 8 September 2026. That an organization resource exists for Workspace and Cloud Identity customers and is created when the account is associated with a domain.
• Brand verification, sensitive scope verification and restricted scope verification - Google Identity documentation, read 8 September 2026. The stated review times of a few minutes, two to three business days, three to five business days and potentially several weeks respectively, and the annual third-party security assessment behind the last of these.
• Cannot publish due to error message "Your app's OAuth configuration is incomplete" - Google Developer forums, opened 25 August 2026, read 8 September 2026. Nine people with the same greyed-out Publish button, the banner text that names no fields, the tooltip that does, the exact sequence that cleared it, and confirmation from a second user the same day. The thread auto-closed with no reply from Google.
• Google OAuth authentication in n8n: App Domain on the Branding page - n8n community, August to September 2026, read 8 September 2026. Two community members advising that the fields are unnecessary, and the forum's community moderator — not an n8n employee — correcting them with the explanation that the Branding page saves empty and the requirement only appears at publish time.
• Can one use Google Sheets longer than 7 days in Test mode without manual reconnecting - n8n community, March 2026, read 8 September 2026. The verbatim invalid_grant error description, and one person caught between having no Workspace account and needing a restricted scope that requires a security assessment.
• How to stop n8n credentials from expiring every week - n8n community, January 2026, read 8 September 2026. The single unanswered report that a token continued to expire after the app was published, treated in this article as an unexplained datapoint rather than as a counter-rule.
• How should client credentials be set up? - n8n community, July 2026, read 8 September 2026. The agency setup discussion, including the observation that an expired credential can leave the platform reporting a successful run while producing no output.
• n8n source, the OAuth request helper - read 8 September 2026 from the raw file on master. The invalid_grant detection and the reconnect error it builds, quoted here as the headline and description a user sees.
• Google OAuth2 single service credentials and Google credentials - n8n documentation, read 8 September 2026 from the live pages. The seven-day expiry for Testing and External apps with the resolution given as reconnecting in the credentials modal, and the managed OAuth option available on n8n Cloud but not to self-hosted installations.
• Connect to Google services using a custom OAuth client - Make Help Center, read 8 September 2026. The requirement to build your own client for restricted Google services, the instruction sequence that selects External and then clicks Publish app, the 400 error text, and the explanation that unpublished apps have a seven-day authorization period affecting non-Workspace accounts.
• How do you actually deploy Make.com automations for clients? - Make community, June to July 2026, read 8 September 2026. The agency deployment problem, and a contributor's explanation that the Internal exemption requires every user of the app to belong to the organization, which a developer signing in with a personal account does not.