Make connection expired or unauthorized: reauthorize without breaking scenarios

What an expired connection looks like

Make connections store the access you granted to another app. Make notes that apps using OAuth 2.0 only grant access for a limited time, so a connection can stop working even if nobody touched it. [1] When verification fails you see an exclamation mark on the Connections page instead of a green check. [1]

Check the scenario too. If the failed run ended in an AccountValidationError, Make disables the scenario scheduling immediately rather than waiting for repeated errors, so a connection problem can show up first as a scenario that has been switched off. [7]

Step by step: verify, reauthorize, replace

Make documents this sequence on its Connect an application page. [1]

• In the left sidebar click Credentials, then switch to Connections.
• Find the connection and click Verify. A green check means it works.
• If it fails, click Reauthorize and follow the prompts. Allow the pop-up if your browser blocks it.
• If reauthorizing still fails because the token was revoked, permissions changed or the app had an outage, retry once, then create a new connection.
• Use the Connections page to see which scenarios use the connection before deleting anything; deleting a connection may stop those scenarios.
• If a webhook uses the connection, Make says to delete the webhook first before deleting the connection.

Which scenarios share the connection

All users in a Make team can use and manage connections created in that team, and one connection can serve any module for the same app across scenarios. [1] That cuts both ways: reauthorizing once fixes every scenario that uses it, but an edit with the wrong account also breaks all of them at once. [1]

When you switch to a different account or authentication method, Make says you need a new connection. To move many modules over, Make documents two methods: the Make DevTool Swap Connection tool within one scenario, or a scenario built with the Make app that finds scenarios using the old connection ID and updates their blueprints. [3] The Make app method needs a paid plan, and Make advises testing on one or two scenarios first; you can restore a previous scenario version if something goes wrong. [3]

Why Google and Microsoft tokens stop working

Google lists the reasons a refresh token stops working: the user revoked access; the token was unused for six months; the user changed password and the token includes Gmail scopes; the OAuth app has an external user type and Testing publishing status, which limits tokens to 7 days unless only basic profile scopes are used; the account passed the limit of 100 refresh tokens per OAuth client, which silently invalidates the oldest; time-based access ended; or an admin restricted a requested service. [4]

Make's guide to custom Google OAuth clients says unpublished apps have a 7-day authorization period, so you must reauthorize every week until you move the app to In production under Audience, then Publish app, in the OAuth consent screen. [2] Missing scopes can produce Error 403 Insufficient Permission, and restricted scopes can fail for consumer gmail.com accounts. [2]

Microsoft documents a default refresh token lifetime of 90 days for most apps and 24 hours for single-page apps, and tokens can be revoked early. [5] Which events revoke a token depends on its type: for password-based tokens, a user password change, a self-service password reset or an admin reset revokes them; tokens issued to confidential (server-side) clients survive a user's own password change but are revoked by an admin password reset in the Microsoft Entra or Microsoft 365 admin center. A user or admin revoking all refresh tokens revokes every type. [5] Microsoft's table does not name Make, so if a connection breaks after a password event, reauthorize it.

Rerun failed work without stale or duplicate data

Once the connection works, decide what to do with runs that failed while it was down. Scenario run replay reruns the current scenario with old trigger data, and the data passes through all modules, including ones that already succeeded. [6] If a failed run wrote to one app before reaching the broken connection, replaying it can repeat that write. Disable completed routes or modules before replaying, and remember that replays consume credits. [6]

Also consider whether old data is still correct. A run triggered three days ago may carry an outdated status or price. If in doubt, let the next fresh trigger handle it rather than replaying stale bundles.

Prevent the next expiry

A few habits remove most surprise expiries.

• Publish custom Google OAuth apps to In production instead of leaving them in Testing. [2]
• Connect business automations with a dedicated account rather than one staff member's personal login, so a password reset or token revocation for that person does not break scenarios. [5]
• Name connections by account and purpose so the right one is reauthorized.
• Keep connection usage notifications on so you know when teammates reuse your connections. [8]
• Verify key connections monthly from Credentials, then Connections. [1]

Sources & verification

Product details and prices can change. Check the linked provider before buying.

1. Make Help: Connect an application Accessed 30 Oct 2026
2. Make Help: Connect to Google services using a custom OAuth client Accessed 30 Oct 2026
3. Make Help: Replace connections across multiple modules Accessed 30 Oct 2026
4. Google for Developers: Using OAuth 2.0 to access Google APIs Accessed 30 Oct 2026
5. Microsoft Learn: Refresh tokens in the Microsoft identity platform Accessed 30 Oct 2026
6. Make Help: Scenario run replay Accessed 30 Oct 2026
7. Make Help: Overview of error handling Accessed 30 Oct 2026
8. Make Help: Manage connection and key usage notifications Accessed 30 Oct 2026