Your n8n workflow runs smoothly for a week. Then suddenly, the Google Sheets or Gmail node responds with an authorization error, even though nothing has changed. The cause is often not n8n and not the workflow itself. The issue lies in a setting in Google Cloud that only becomes apparent after seven days.
Key Figures to Note
| Item | Figure | Source |
|---|---|---|
| Age of test account permission | 7 days from approval | Google and n8n documentation |
| Test user limit | 100 accounts | Google Cloud Help Center |
| Limit for unverified application users | 100 new users, project lifetime | Google Cloud Help Center |
The rules are as follows. A Google Cloud project with External user type and Testing publication status only receives a refresh token that is valid for seven days. The n8n documentation states the same: approval and token expire after seven days. For External applications, n8n also notes that the status is automatically Testing, and only accounts you register as test users can complete the authorization process.
Therefore, the connection you establish today will disconnect next week if the project's status remains Testing. Reconnecting credentials in n8n fixes this, but only for the next seven days.
Check This Before Blaming the Workflow
Open the Google Cloud Console, then navigate to the Google Auth Platform or OAuth consent screen. Look at these three fields:
- Audience or user type. External means anyone with a Google account. Internal is only for members of your Google Workspace organization.
- Publication status. Testing means the seven-day limit applies. In production means the application is open to all Google accounts.
- Test user list. The account used by n8n must be listed here while the status is still Testing.
If your Google account is within a Workspace organization, the Internal type restricts access to members of that organization only. Both n8n and Google documentation mention this option.
APIs That Must Be Enabled Per Project
Token restrictions are not the only source of errors. Each Google Cloud project needs to enable its own APIs in APIs & Services, under the Library section. A new project means you need to enable everything again. The n8n documentation notes one connection that is often overlooked: Google Docs, Sheets, and Slides nodes require the Google Drive API in addition to their own API. So, Sheets alone is not enough. Gmail only requires the Gmail API.
One more thing on the n8n side: the redirect URL copied from n8n credentials must be entered exactly in the Authorized redirect URIs section of the Google OAuth client. For local testing, Google accepts the localhost address.
Why Not Just Publish It Right Away
Changing the status to In production sounds like a shortcut, but there is a cost associated with it. Google categorizes access scopes into three groups: non-sensitive, sensitive, and restricted. In the Gmail API, gmail.send is classified as sensitive and requires additional OAuth application verification. Scopes like gmail.readonly, gmail.compose, and gmail.modify are classified as restricted, with heavier verification. Unverified applications will display a warning screen to users and are subject to a limit of 100 new users.
For personal automation or a small team, most people do not need a public application. A more sensible option: use the Internal type if you have Workspace, or accept the seven-day cycle and schedule reconnections. For applications serving many users, plan for verification from the start, not after the first connection drops.
If you find it easier to follow the Google Cloud screen sequence through a visual guide, there is a clip explaining the API activation steps on this video page.
Sources
- n8n Docs, Google: OAuth2 single service
- Google for Developers, Using OAuth 2.0 to Access Google APIs
- Google Cloud Help, Manage App Audience
- Google for Developers, Choose Gmail API scopes