Reconnect this account - and the reconnect button is greyed out

Why does the platform tell you to reconnect and then not let you?

Because the word "connection" covers two different things, and only one of them can be reauthorized. A connection built on OAuth - where you clicked through a consent screen - can be renewed. A connection built on an API key you pasted in cannot: there is nothing to re-consent to. The email does not distinguish them.

This played out in public on Make's forum in July, and it is worth reading in the order it happened. First the report:

Responding to email from make saying that reauthorization of the stripe connection is required. [...] When I view my list of connections, the "reauthorize" button next to the Stripe connection is grayed out. I clicked verfity, next to the stripe connection, and that worked fine. I also clicked "reauthorize" on another connection in the list and was able to do that no problem.

• a user, Stripe Re-authorization Necessary, but button is grayed out, Make Community, 20 July 2026, read 18 August 2026

The answer came the next day - from another user, not from the vendor:

The Reauthorize button is only clickable when you create a connection that uses OAuth. For Stripe it seems you are using an API Key which means you can't reauthorize it. Your other Quickbooks connection is OAuth which is why you are seeing it.

• another user, same thread, 21 July 2026

And then the sentence that is the whole reason this article exists:

It's confusing to get an email from Make saying I have to reauthorize the Sripe connection ASAP, but then not be able to do it. How can I tell that I'm using an API key vs a connection that uses OAuth?

• the thread's author, same thread, 21 July 2026

That question was never answered in the thread. It is a reasonable question, the person asking it had already done everything right, and the interface gives them no way to answer it themselves.

The thread does have an ending, though, and it is the part worth keeping. A day later another affected user posted the reply he had received from Make's support team:

We sincerely apologise for the confusion. The communication was intended only for OAuth-based connections, where you would see a Re-authorize button. Unfortunately, we missed mentioning this in the announcement. Since you're using an API key-based connection, no action is required from your end.

• a user quoting Make's Customer Care Team, in Stripe Re-authorization Necessary, but button is grayed out, Make Community, 22 July 2026, read 18 August 2026

So the email went to people it did not apply to, and the vendor said so. If you spent an evening on a greyed-out button in July, nothing was wrong with your account. That is worth knowing before the next such email arrives, because the next one will look identical.

What actually expires when a connection "expires"?

Two separate things, on two separate clocks. The access token is the short-lived pass your automation sends with every request, and the platform renews it silently as it expires. The refresh token is the long-lived permission to keep doing that. When people say a connection died, they almost always mean the refresh token stopped working.

The distinction matters because the two failures look identical from the dashboard and need completely different responses. An expired access token is a non-event handled automatically. A dead refresh token means the service on the other end has withdrawn standing permission, and no amount of retrying will bring it back.

What actually kills a working connection?

Rules set by the service you connected to, not by your automation platform. Google publishes its list, and it is the most useful page an owner of a broken Gmail or Sheets automation can read - because none of it appears in the automation tool's interface:

You must write your code to anticipate the possibility that a granted refresh token might no longer work. A refresh token might stop working for one of these reasons:

The user has revoked your app's access.

The refresh token has not been used for six months.

The user changed passwords and the refresh token contains Gmail scopes.

The user account has exceeded a maximum number of granted (live) refresh tokens.

The user granted time-based access to your app and the access expired.

If an admin set any of the services requested in your app's scopes to Restricted (the error is admin_policy_enforced).

For Google Cloud Platform APIs - the session length set by the admin could have been exceeded.

• Using OAuth 2.0 to Access Google APIs, Google Identity documentation, read 18 August 2026

Read that list as an owner rather than a developer and three of the entries are ordinary business events. Somebody changed the password on a mailbox account - note Google's condition is narrower than it first looks, and applies where the token carries Gmail scopes. A seasonal automation sat unused over a quiet half-year. An admin tightened a policy on a service your app asks for. None of these feel like touching the automation, which is exactly why the owner is certain they changed nothing - and they are right.

Google adds one more condition for corporate accounts, and its numbers explain a whole category of "it dies every morning":

As session durations can be very limited (between 1 hour to 24 hours), this scenario must be handled gracefully by restarting an auth session.

• Using OAuth 2.0 to Access Google APIs, Google Identity documentation, on Google Cloud session control policies

Why does deleting and recreating the connection make things worse?

Because on Google's side every rebuild mints another token against a ceiling you cannot see, and at that ceiling one of your working tokens is destroyed to make room. The documented limit:

There is currently a limit of 100 refresh tokens per Google Account per OAuth 2.0 client ID. If the limit is reached, creating a new refresh token automatically invalidates the oldest refresh token without warning. This limit does not apply to service accounts.

• Using OAuth 2.0 to Access Google APIs, Google Identity documentation, read 18 August 2026

Note the scope of that limit precisely: it is per Google account per client ID, so it counts your reconnections to one particular platform, and service accounts are excluded. A hundred sounds unreachable until you picture the standard troubleshooting ritual - delete the connection, add it again, test, still broken, delete it again - repeated across a year by several people who each "just reconnected it quickly".

The failure mode this produces is the nastiest kind: the automation you fixed last month stops, and the thing that killed it is the automation you fixed this morning.

Why does reconnecting not clear a permissions error?

Because reauthorizing renews the credential, and a permissions error is not about the credential being stale - it is about what the credential was allowed to do when it was granted. Renewing the same narrow permission produces the same refusal, which is exactly what happened here:

It worked in the past but now when I try to run it it says The operation failed with an error. [403] Request had insufficient authentication scopes. I check and Make has all the necessary permisions. I have also deleted the Gmail module and added it again. But no luck.

• a user, Issue with Gmail connection, Make Community, 10 August 2026, read 18 August 2026

A moderator suggested verifying and reauthorizing from the credentials screen. That is the standard advice, and it did not work: "Tried it and didn't worked. Got the same message." The same person then reported what the module was displaying at that moment:

One more thing that might help is that when I click on the Gmail module it says: You have until January 26th 2027, 03:15 PM (Tue) to reauthorize your connection.

• the same user, same thread, 10 August 2026

Two readings of one connection, pointing opposite ways: the run says the permissions are insufficient right now, and the module says the connection is good until next January. Both can be true, because they describe different things - one is about scope, the other about expiry. Nothing here is a bug in the owner's setup, and it is the same trap as a green test that hides a failing live run: the reassuring signal and the failing one are answering different questions. The permissions granted when the connection was created are simply narrower than what a later action asks for, and only the run finds that out.

What do you do when the vendor says the cause is not on their side?

You establish which side owns the credential before you spend another evening on it. This is not a hypothetical stand-off - it is a normal outcome, and vendors say so plainly:

So far, we have not found the root cause on our side causing this issue. It looks like it might be on Spotify's side, but we are looking into this problem now.

• a Make staff member, in BUG: Spotify API persistent 401 Unauthorized, Make Community, 27 July 2026, read 18 August 2026

Two days later the same Make employee posted that "This issue has now been resolved, with a fix applied to all zones", and the reporter confirmed it was working. So the guess about Spotify was wrong and the cause was on Make's side after all - which is the actual lesson. From outside, you cannot tell which side owns a broken connection, and neither can the people answering you on day one.

When both sides show green and the connection still fails, the useful question stops being "which button do I press" and becomes "whose rule expired". That is answerable: the service that issued the token publishes its rules, the platform publishes what it stores, and the account's own security log records password changes, admin policy changes and revoked app access. It is an hour of reading in the right places rather than another week of pressing reconnect.

How do you tell which kind of connection you have?

By where the secret came from, not by what the list calls it. Ask one question per connection: when you set it up, did you land on the service's own login and consent screen, or did you paste a string you copied from the service's settings? The first is OAuth and can be reauthorized; the second is a key, and the only repair is to replace it.

One caution before you rotate anything in that table: a key or a service-account file is often pasted into more than one system. Find every consumer first, move them across, and retire the old credential only once each one is proven working

• otherwise repairing this automation quietly breaks two others.

Write the answer down next to each connection once. It converts every future "reconnect this" email from a puzzle into a two-minute job.

What should you check, and in what order?

Work from the account that owns the permission outward, because that is where the decision was actually made:

1. Check the service's own security page first, not the automation platform. Google, Microsoft and Meta all list third-party apps with access and recent security events. A password change, a removed app, or an admin policy will be visible there and nowhere else.
2. Identify the credential type using the table above, before pressing anything.
3. If it is OAuth, reauthorize with the same user account that created it originally. Reconnecting as a different colleague produces a connection with that person's permissions, which is a new and quieter problem.
4. Read the exact error text from the run, not the connection test. "403 insufficient scopes" is a permissions problem and needs re-consent; "invalid_grant" means the token itself is gone.
5. Stop deleting and recreating. Each rebuild burns a slot against the limit above and destroys the evidence of what failed.
6. Check whether anything else broke at the same moment. One expired login used by six automations produces six unrelated-looking failures, and fixing them one at a time costs six times as much as fixing the credential once. Some of those six will not announce themselves at all - a scheduled job that simply stops running produces no error to notice.

Why does this keep happening to the same accounts?

Because most connections are created in the moment by whoever was building the automation, using their own login, with whatever permissions they happened to have. That works until that person changes their password, leaves, or has their admin tighten a policy - at which point the business discovers that a load-bearing process was standing on one individual's personal session.

The structural fix is unglamorous and permanent: connections that matter get their own dedicated account, with its own permissions, owned by the business rather than a person. Everything else is maintenance you will keep repeating.

When is this worth handing over?

If one automation is down, the error mentions authorization, and you can get to the account that owns it, do it yourself - the checklist above is the whole job and it takes an afternoon.

It becomes a different job when several automations fail at once and nobody can say which shared login they were standing on, when the credential belongs to somebody who no longer works with you, or when both the platform and the service report themselves healthy and the runs keep failing anyway. Untangling that means mapping which processes depend on which credential, moving the load-bearing ones onto accounts the business controls, and proving each one runs afterwards - work with an end state you can check, which is what a fixed-price Fix M is scoped around.

Sources

• Stripe Re-authorization Necessary, but button is grayed out - Make Community, thread opened 20 July 2026, read 18 August 2026. The greyed-out reauthorize button, the OAuth-versus-API-key explanation from another community member, and the unanswered question about telling them apart.
• Issue with Gmail connection - Make Community, thread opened 10 August 2026, read 18 August 2026. The 403 insufficient-scopes error persisting after reauthorizing from the credentials screen, and the module's displayed reauthorization deadline.
• BUG: Spotify API persistent 401 Unauthorized - Make Community, thread opened 24 July 2026, read 18 August 2026. The vendor statement that the root cause was not found on their side on 27 July, and the same employee's confirmation on 29 July that a fix had been applied across all zones.
• Using OAuth 2.0 to Access Google APIs - Google Identity documentation, read 18 August 2026. The documented reasons a refresh token stops working, the 100-token-per-client limit that silently invalidates the oldest token, and Google Cloud session-control durations.