Make.com Invalid Refresh Token: Fix the 7-Day Reauthorize
Published: July 14, 2026 · Updated: August 2026Question: Why does Make.com say “Invalid refresh token, please reauthorize” every 7 days?
Quick Answer: This happens when the Google connection uses a custom OAuth client left in Testing status in Google Cloud Console. Google caps test-user tokens at 7 days by design. Publishing the app to Production in the OAuth consent screen removes the 7-day cap — but if your scopes are sensitive, you’ll also need Google’s separate verification process to fully clear the “unverified app” warning.
Key Facts
What Causes the Make.com Invalid Refresh Token Error
The exact message — “Failed to verify connection… Invalid refresh token. Please reauthorize the connection” — shows up on Make’s own community forum on a near-constant basis, almost always tied to a Gmail, Google Drive, or Google Sheets connection that worked fine for about a week and then broke without warning.
The root cause is not Make.com. It’s a specific, documented Google Cloud policy: any OAuth client left in Testing publishing status has its token authorizations capped at exactly 7 days from the moment the user consents. This isn’t a bug or an edge case — it’s how Google enforces the boundary between an app that’s still in development and one that’s ready for real users. Once that 7-day window closes, the refresh token Make.com was relying on to keep the connection alive silently stops working, and the next scenario run throws the “invalid refresh token” error.
This only affects custom OAuth clients. If your Make.com scenario uses Make’s own built-in Google connection — the default option most people pick — you won’t hit this at all. Make’s shared app has already completed Google’s verification process. The 7-day expiry almost exclusively affects operators who set up their own OAuth client in Google Cloud Platform, typically to use a separate API quota or satisfy an internal IT security policy.
How to Fix the Make.com Invalid Refresh Token Error
There are three ways to resolve this, depending on your situation. Start with the first one — it covers most cases.
Publish the App to Production
In Google Cloud Console, go to APIs & Services → OAuth consent screen → Audience, and click Publish App. This moves your project’s publishing status from Testing to In Production. The 7-day token cap is a Testing-status behavior specifically — once published, it no longer applies, regardless of what scopes your app requests. You’ll need to reauthorize the Make.com connection one final time after publishing, since the old token was issued under the previous status.
Submit for Verification if Your Scopes Are Sensitive
Publishing alone is not the finish line if your OAuth client requests sensitive or restricted scopes — and most Gmail, Drive, and Calendar integrations do. Until Google completes verification for those specific scopes, users will see an “Unverified app” warning screen and the app stays capped at 100 users, even in Production. Submitting for verification requires a privacy policy URL, a homepage, and — for restricted scopes like broad Gmail access — a paid third-party CASA Tier 2 security assessment. Budget one to six weeks for this, and start it well before you need the connection to be fully public-facing.
Switch the User Type to Internal (Workspace Orgs Only)
If your Google account is part of a Google Workspace organization, you can set the OAuth consent screen’s User Type to Internal instead of External. Internal apps are restricted to accounts within your own domain, and because of that, they are exempt from both the Testing-mode 7-day expiry and Google’s public verification requirement entirely — there’s no 100-user cap and no unverified-app warning. This is the cleanest fix if the connection only ever needs to serve your own team.
Which Fix Applies to You
| Your situation | Fix |
|---|---|
| Using Make.com’s default Google connection | Nothing to fix — this issue doesn’t apply to you |
| Custom OAuth client, only read-only or narrow scopes | Fix 1 — publish to Production, done |
| Custom OAuth client, Gmail/Drive/Calendar write access | Fix 1 + Fix 2 — publish, then submit for verification |
| On a Google Workspace org, connection is internal-only | Fix 3 — switch User Type to Internal |
If you’re setting up Google connections in Make.com for the first time, starting with Make’s own built-in connection avoids this entire problem.
Why the Error Can Come Back After You Publish
Two follow-up issues account for most repeat cases after someone has already published their app.
- The scope was added after verification. Adding a new sensitive or restricted scope to an already-verified app resets that scope’s status — it shows up unverified until you resubmit, even though the rest of your app remains approved. Google’s own guidance is explicit here: don’t push code using a new scope to production until that specific scope shows as approved on the consent screen.
- A second, unpublished OAuth client is in use. If your team has more than one Google Cloud project or OAuth client — common when someone spins up a “quick test” client and it ends up in production use — the working connection can quietly point at the wrong one. Check the client ID shown in Make’s connection details against the one you actually published.
Don’t confuse “Published” with “Verified.” These are two separate states in Google’s system, and conflating them is the single most common reason people think they’ve fixed this and then see the error return. Publishing changes your app’s status from Testing to Production and removes the 7-day cap. Verification is Google’s separate review of your specific scopes, and it’s what removes the unverified-app warning and the 100-user ceiling. You can be published and unverified at the same time — and for sensitive scopes, that’s the normal state until verification completes.
FAQs: Make.com Invalid Refresh Token Error
Why does my Make.com Google connection keep breaking every 7 days?
This happens when a custom Google OAuth client used for the connection is left in Testing publishing status in Google Cloud Console. Google caps test-user token authorizations at 7 days by design, regardless of which platform — Make.com, a custom script, or anything else — is using that OAuth client.
Does publishing my app to Production completely fix the reauthorization error?
It fixes the 7-day expiry specifically, since that limit is tied to Testing status. But if your OAuth client requests sensitive or restricted scopes — most Gmail and Drive integrations do — publishing alone still leaves your app showing an Unverified app warning and capped at 100 users until Google completes a separate verification process for those scopes.
How long does Google’s OAuth verification take?
Verification for sensitive scopes typically takes a few days to a few weeks. Restricted scopes, which require a CASA Tier 2 security assessment, commonly take several weeks and involve a paid third-party audit. Google recommends starting verification well before you need it in production.
Can I avoid this problem entirely by using Make.com’s built-in Google connection instead of a custom OAuth client?
In most cases, yes. Make.com’s default Google connection uses Make’s own pre-verified OAuth client, which Google has already completed verification for. The 7-day expiry and unverified-app cap almost always only affect users who deliberately created their own custom OAuth client in Google Cloud Platform, typically to use their own API quota or to satisfy an internal IT policy.
What counts as a sensitive or restricted Google OAuth scope?
Sensitive scopes include things like reading or modifying Gmail messages, accessing Google Drive files, or reading Calendar data. Restricted scopes are a smaller, higher-risk subset — full Gmail account access and certain Drive scopes among them — that require the additional CASA security assessment. Read-only or narrowly scoped access, such as a single-label Gmail scope, is sometimes classified as non-sensitive and doesn’t trigger verification at all.
If my organization uses Google Workspace, is there a way to skip verification altogether?
Yes. Setting the OAuth consent screen’s User Type to Internal instead of External restricts the app to accounts within your own Google Workspace organization. Internal apps are not subject to the Testing-mode 7-day expiry, the 100-user cap, or Google’s public verification requirement, since the app never leaves your organization’s domain.
Will republishing the app disconnect my existing Make.com scenarios?
Publishing the app itself does not revoke existing tokens. However, you will typically need to reauthorize the connection in Make.com one final time after publishing, since the old token was issued under Testing status. After that one reauthorization, the connection should hold without expiring every 7 days.
Does this same 7-day expiry affect other automation tools like Zapier or n8n?
Yes. The 7-day cap is a Google Cloud policy tied to the OAuth client’s publishing status, not a Make.com-specific limitation. Any platform — Zapier, n8n, a custom script, or Make.com — that authenticates through a custom Google OAuth client left in Testing status will hit the identical expiry. The fix is the same regardless of which automation tool is on the other end: publish the OAuth client to Production.
How do I check whether my Google Cloud project is in Testing or Production status?
In Google Cloud Console, open the project tied to your OAuth client, go to APIs & Services, then OAuth consent screen. The publishing status — Testing or In production — is shown near the top of that page, along with the current user cap and any pending verification requirements for your scopes.
Build the Connection Right the First Time
Most operators never need a custom OAuth client at all. Make’s built-in Google connections skip this entire problem — no 7-day expiry, no verification queue, no unverified-app warning. The No-Code Automation Blueprint packages the connection patterns used across every guide on this site.
Get the Automation Blueprint →Free JSON scenario files, importable directly into Make.com.