Make.com Invalid Refresh Token: Fix Google OAuth Reauthorization (2026)
Published: July 14, 2026 · Updated: October 2026Why does Make.com say “Invalid refresh token, please reauthorize”?
The most common cause is a Google OAuth client that is still in Testing status. Google says authorizations for external apps in Testing expire after seven days, including the refresh token used for continued access. But the 7-day problem is only one possible cause: refresh tokens can also be revoked, remain unused for six months, be replaced after the account reaches its refresh-token limit, be blocked by a Google Workspace policy, or stop working when the OAuth client itself is deleted.
Using Make with Google?
For standard Google integrations, Make’s managed app connections are usually simpler than maintaining your own OAuth client.
- 1. Identify the Real Cause
- 2. Why the 7-Day Google OAuth Expiry Happens
- 3. Fix It by Moving to In Production
- 4. Production vs Verification
- 5. Google Workspace Internal Apps
- 6. Reauthorize the Make Connection
- 7. When It Is NOT the 7-Day Problem
- 8. The 100-Refresh-Token Limit
- 9. Production Checklist
- 10. Frequently Asked Questions
1. Identify the Real Cause Before You Rebuild Anything
The fastest fix depends on when the connection breaks. If it fails approximately seven days after every fresh Google authorization, the Google Cloud project’s publishing status is the first thing to inspect. If it fails immediately, or after months of normal operation, a different cause is more likely.
Testing-status OAuth client
This is the classic Google OAuth Testing problem. External projects in Testing issue authorizations that expire after seven days unless the request is limited to Google’s basic identity scopes.
Revoked or expired refresh token
Google says refresh tokens can stop working when the user revokes access, the token is unused for six months, certain account or policy conditions change, or another refresh-token limit is reached.
Connection or OAuth configuration problem
Check the Google project, OAuth client, scopes, redirect URI, account permissions and whether Make is using the client you actually intended to publish.
Policy, scope or project-level issue
A Workspace administrator may block access, a sensitive or restricted scope may be unapproved, or the OAuth client/project may have changed.
2. Why the Make.com Google Connection Breaks Every 7 Days
Google separates OAuth applications into Testing and In production. For an external project that remains in Testing, Google says test-user authorizations expire seven days after consent. If an offline access flow receives a refresh token, that refresh token expires as well.
That is why this problem often looks like a Make.com bug. The Make scenario can run normally for several days, then the next attempt to use a Google connection fails because the refresh token that was supposed to obtain a new access token is no longer valid.
Make documents the same problem specifically for custom Google OAuth clients: if the Google project stays in Testing, the connection requires weekly reauthorization; moving the project to In production removes the weekly reauthorization requirement.
Important: this 7-day rule is a Google OAuth policy, not a special Make.com timeout. The same OAuth client can create the same problem for other automation software or custom applications.
3. Fix the 7-Day Problem: Move the Google OAuth Project to In Production
If your connection is breaking on a predictable seven-day cycle, this is normally the first fix to make.
Open the Google project used by Make
Open the Google Cloud project associated with the OAuth client you entered into Make. Current Google documentation refers to the modern interface as Google Auth Platform; older instructions often call this the OAuth consent screen.
Open Audience
In Google Auth Platform, open the Audience section and inspect the publishing status. An external project in Testing is the key signal for the recurring 7-day authorization problem.
Publish the app
Change the project from Testing to In production by using the Publish app control. Google defines the project as In production after the application is published.
Reauthorize the Make connection
Return to Make, open the affected Google connection and use Reauthorize. Make’s current connection management documentation says that failed OAuth connections can be reauthorized, and if that does not solve the problem, creating a new connection is the next step.
Current Google UI wording: some older tutorials say “OAuth consent screen → Publish App.” Google’s current console uses Google Auth Platform → Audience → Publish app. The underlying publishing concept is the same.
4. Publishing Is Not the Same Thing as Verification
This distinction is where many otherwise good troubleshooting guides become misleading.
Publishing changes the application from Testing to In production and removes the recurring seven-day authorization expiry. Verification is a separate Google review that applies when your application meets Google’s verification criteria, particularly when it requests sensitive or restricted scopes.
| Status | What it changes | What it does not automatically change |
|---|---|---|
| Testing | Limited testing environment with up to 100 listed test users and seven-day authorizations. | Does not provide durable production-style authorization for external users. |
| In production | Removes the Testing-mode seven-day authorization expiry. | Does not automatically mean sensitive/restricted scopes are verified. |
| Verified for required scopes | Completes Google’s applicable review for those requested scopes and branding requirements. | Does not prevent every possible token revocation or admin policy issue. |
| Internal Workspace app | Restricts use to the organization and does not require public OAuth verification. | Does not make an app available to accounts outside the organization. |
Do not write this: “Publish to Production and the 100-user limit disappears automatically.”
Use this instead: moving to In production removes the seven-day Testing expiry. If the project still requests unapproved sensitive or restricted scopes, Google can apply its 100-new-user restriction until the relevant verification requirements are satisfied.
5. Do You Actually Need Google OAuth Verification?
Not every custom Google OAuth client needs the same review.
Google says verification is not mandatory for some categories, including personal-use apps with fewer than 100 users, development/testing/staging projects, and internal-only apps used within a Google Workspace or Cloud Identity organization. Applications that request sensitive or restricted scopes can fall under separate verification requirements.
For production applications requesting sensitive or restricted scopes, Google currently lists approximate verification timelines of 10 business days for sensitive-scope verification and 6 weeks for restricted-scope verification. Google notes that these are estimates rather than guarantees; restricted scopes can also require a security assessment.
Google also recommends using a separate project for development/testing and a production project for the application you intend to release. This avoids mixing experimental scopes and configurations with your production OAuth setup.
For a private Make workflow used only by you: do not automatically assume you need a public verification process. First determine whether your project is personal-use or internal-only, and whether the Google services and scopes you are requesting actually require the broader review.
6. Google Workspace: When an Internal App Changes the Equation
If the automation is strictly for users inside your Google Workspace organization, an Internal application may be the cleanest architecture.
Google says internal apps are available only to users in the organization and do not require submission for public OAuth verification. The Internal option is only available when the project belongs to a Google Workspace or Cloud Identity organization.
| Your setup | Typical path |
|---|---|
| Personal Gmail + private automation | Use Make’s managed Google connection where possible; otherwise configure the smallest custom OAuth setup you actually need. |
| Google Workspace, employees only | Consider an Internal OAuth app if the workflow is genuinely restricted to your organization. |
| External customers/users | Use an External project and move the production project to In production; complete applicable verification for requested scopes. |
7. How to Reauthorize the Make.com Connection
After correcting the Google project, the Make connection still has to obtain a valid authorization again.
Open Connections in Make
Open your Make workspace and locate the affected connection in the Connections area.
Use Verify first when available
Make’s current documentation provides a Verify action for checking whether a connection is working. A failed verification indicates that the stored authorization needs attention.
Click Reauthorize
Complete Google sign-in and approve the requested permissions. Make documents Reauthorize as the first response to an OAuth connection that fails verification.
Create a new connection if reauthorization does not resolve it
If the existing connection is still invalid after the underlying Google configuration is corrected, Make recommends creating a new connection. This is especially useful when the old connection was created against a different client, project, or set of scopes.
Do not keep clicking Reauthorize every week. If the connection is predictably expiring seven days after consent, reauthorization is only a temporary workaround while the Google project remains in Testing. Move the relevant production OAuth project to In production instead.
8. If It Is Not the 7-Day Problem, Check These Causes
“Invalid refresh token” is not a diagnosis by itself. Google documents several reasons a refresh token can stop working.
The user revoked the connection
A Google account owner can revoke an application’s access. Once access is revoked, the associated authorization can no longer be used. Reauthorize the Make connection from the correct Google account.
The refresh token has not been used for six months
Google documents six months of non-use as one possible refresh-token expiration condition. This is a different problem from the seven-day Testing rule and should not be “fixed” by repeatedly recreating OAuth projects.
A Google Workspace administrator blocked the requested access
Google lists administrator policy enforcement as another possible reason a refresh token stops working. If multiple users in the same organization suddenly fail, check Workspace third-party-app controls and any recent policy changes.
The OAuth client or project changed
Verify the Client ID being used by Make. A common operational mistake is publishing one Google OAuth client while the Make connection still points to a different client or project.
The OAuth client was deleted
Google now automatically deletes OAuth 2.0 clients that have been inactive for six months. If the client was deleted, associated authorization tokens will fail and the connection needs to be rebuilt against an active client.
Required scopes changed
Adding sensitive or restricted scopes to a production application can trigger additional review requirements. Google recommends testing new scopes in a separate development project and submitting new production scopes for verification before relying on them in production.
9. The 100-Refresh-Token Limit Most Guides Miss
Google currently documents a limit of 100 refresh tokens per Google Account per OAuth 2.0 client ID. If that limit is exceeded, creating a new refresh token can invalidate the oldest existing refresh token.
This matters when the same Google account is repeatedly connected and reconnected across many applications, environments or automation setups. A large number of fresh authorization events can eventually make an older connection suddenly stop working.
Practical fix: stop repeatedly creating fresh OAuth connections unless you actually need them. Keep one stable production client and reuse the Make connection where appropriate. If an older token has been invalidated because the refresh-token limit was reached, reauthorize the required connection and retire unnecessary duplicate connections.
10. Do You Need a Custom Google OAuth Client in Make.com?
Often, no.
Make provides managed integrations for standard Google apps, and its current Google Sheets integration is marked as a verified app reviewed by Make. Its standard connection flow is simply to create a connection and sign in with Google.
Make’s own documentation explains that custom OAuth clients are useful when you specifically need to connect restricted Google services, use your own Google Cloud project, or operate an internal/custom configuration.
For a normal Google Sheets/Gmail/Drive workflow: start with Make’s managed connection when it provides the functionality you need. Use a custom OAuth client because you have a concrete reason for doing so—not simply because a tutorial told you to create one.
Want the simpler Make setup?
Start with Make’s managed Google integrations before building a custom OAuth project.
11. Production Checklist: Stop the Error From Returning
12. The Fastest Decision Tree
| What you observe | Check first | Likely action |
|---|---|---|
| Connection dies about every 7 days | Google publishing status | Move the external project from Testing to In production, then reauthorize. |
| Connection worked for a long time, then stopped | Revocation, inactivity, admin policy | Reauthorize and determine why the token became invalid. |
| Fails immediately after creating connection | Client ID, scopes, redirect URI, Google account | Correct the OAuth configuration or create a clean connection. |
| Multiple Workspace users fail together | Admin policy / app access controls | Check Workspace administrator restrictions. |
| Many connections for one Google account | Refresh-token count | Reduce duplicate connections and reauthorize the required one. |
| OAuth client no longer appears / credentials changed | Google Auth Platform → Clients | Confirm the client exists and is still the client Make is using. |
13. Frequently Asked Questions
Why does Make.com say “Invalid refresh token, please reauthorize” every 7 days?
The usual cause is an external Google OAuth project that remains in Testing status. Google says authorizations for test users expire after seven days, including refresh tokens issued for offline access. Make documents the same behavior for custom Google OAuth connections.
Does moving the Google app to In production fix the 7-day Make.com error?
Yes, moving the relevant external project from Testing to In production removes the Testing-mode seven-day authorization expiry. You should then reauthorize the Make connection so it obtains a valid production authorization. Verification for sensitive or restricted scopes is a separate issue.
Does publishing the Google app mean it is fully verified?
No. Publishing changes the project to In production. Google may still require verification for sensitive or restricted scopes, and an unverified app requesting unapproved scopes can still be subject to Google’s new-user restrictions.
Can I keep the app in Testing and just reauthorize Make every week?
You can reauthorize a Testing connection, and Make documents that as the workaround for a project intentionally left in Testing. It is not a durable production strategy. For a production external connection, move the project to In production instead.
Do Make.com Google connections always require a custom OAuth client?
No. Make supports standard managed Google connections. Custom OAuth clients are intended for situations where you need your own Google Cloud project or specific restricted/custom configuration. Make’s Google Sheets integration is currently marked as a verified app reviewed by Make.
What else can invalidate a Google refresh token?
Google lists several causes, including user revocation, six months of non-use, certain password changes involving Gmail scopes, exceeding refresh-token limits, time-based access expiration, administrator policy enforcement and other policy conditions.
Is there a limit on Google refresh tokens?
Google currently documents a limit of 100 refresh tokens per Google Account per OAuth 2.0 client ID. When the limit is reached, issuing another token can invalidate the oldest one.
Can Google Workspace users avoid public OAuth verification?
An app configured as Internal can avoid public OAuth verification when it is genuinely restricted to the Google Workspace or Cloud Identity organization that owns the project. The Internal option is not available for ordinary consumer Google accounts.
What should I do if reauthorizing the Make connection still does not work?
Confirm that the Google project is correct, the OAuth client still exists, the required APIs and scopes are enabled, Make is using the intended Client ID, and no Workspace policy is blocking the account. Make’s current documentation recommends creating a new connection if reauthorization does not resolve a failed connection.
One important distinction: a generic “invalid refresh token” error should not automatically be treated as a Google Testing-mode problem. The seven-day pattern is a strong clue; outside that pattern, inspect revocation, inactivity, limits, policies and OAuth configuration instead.
Related CreatorOpsMatrix Guides
Primary documentation used for this guide
- Google Cloud — Manage App Audience / Publishing Status
- Google Developers — OAuth 2.0 and refresh-token behavior
- Google Cloud — OAuth Verification FAQ
- Google Cloud — Submitting an app for verification
- Make — Connect to Google services using a custom OAuth client
- Make — Verify and reauthorize connections
Affiliate disclosure: Some links on CreatorOpsMatrix are affiliate links. If you purchase a product or service through one of these links, we may earn a commission at no additional cost to you. Affiliate relationships do not determine the factual information in this guide.
Operator responsibility: Google OAuth requirements, scope classifications, Workspace policies, Make connection behavior and vendor interfaces can change. Verify the current configuration in Google Cloud and Make before deploying a production automation.