n8n Automation HubThe same pattern, expected to just work
Sending a file by email from inside an automation is a task this account handles the same way every time: spin up a throwaway webhook-triggered workflow, wire a Gmail node behind it, fire it once with the file's data, then delete the workflow. It's a pattern that has worked before without incident, which is exactly why the first credential failure looked like a fluke rather than the start of a two-part problem.
Failure one: an expired token, the ordinary kind
The first credential, used across roughly thirty other client-automation-style workflows on this account (onboarding emails, invoices, newsletters), failed immediately with Client authentication failed. That message is the standard shape of an expired or otherwise invalid OAuth access token — the underlying Google Cloud OAuth client this credential points to still exists, it's just that the stored token n8n is holding no longer authenticates against it. The fix for this class of failure is mechanical: open the credential in the n8n UI and run through the Google OAuth consent screen again to mint a fresh token.
Failure two: not an expired token at all
Switching to the account's second Gmail credential — used in a smaller set of e-commerce and order-related workflows — didn't produce the same error. It failed with The OAuth client was deleted. That's a meaningfully different failure than an expired token: it means the OAuth client itself, the Google Cloud application registration the credential was built against, no longer exists on Google's side. Reconnecting won't help here, because there's nothing left to reconnect to — the fix requires registering an entirely new OAuth client in Google Cloud Console and building a fresh n8n credential around it from scratch, not just refreshing the existing one.
Why the distinction between the two errors matters
Both failures look, at a glance, like "the Gmail credential is broken" — and it would be easy to apply the same fix (a quick reconnect) to both and assume the job is done. Doing that to the second credential would fail again immediately, because a reconnect flow assumes the OAuth client it's reconnecting to still exists. Reading the specific error text before choosing a fix mattered here: "authentication failed" and "client was deleted" point to two different remediation paths, one of them requiring meaningfully more setup work than the other.
What this means for anything that needs to send email
Neither of these fixes is something an automation or an API call can complete on its own — both require a person to sit through a browser-based Google OAuth consent flow, and the second additionally requires a person with access to the Google Cloud project to create a new OAuth client first. In practice, that means checking credential health before routing any new email-send task through either of these Gmail nodes, rather than discovering a broken credential mid-task. Fallback delivery paths worth having ready for exactly this situation: pasting content directly instead of emailing it, or a Google Drive file upload node, if that path is itself working.
Gmail credential errors and what each one needs
| Error text | What it means | Fix |
|---|---|---|
| Client authentication failed | The stored token is no longer accepted | Reconnect the credential in n8n |
| The OAuth client was deleted | The Google Cloud OAuth client no longer exists | Create a new OAuth client and a new credential |
| invalid_grant / token expired or revoked | The refresh token was revoked or expired | Reconnect the credential |
| Insufficient permission / scope errors | The token lacks a scope the node needs | Reconnect and grant the missing scope |
Why tokens keep expiring: Testing mode
A common reason for Google credentials that need reconnecting every week is the OAuth consent screen's publishing status. Google's documentation states that for an app with external user type in "Testing" status, refresh tokens expire after 7 days. Every Google credential built on such a client fails a week after its last reconnect, whatever the workflow does.
The options are to publish the app (for sensitive Gmail scopes this means Google's verification process), to use a Google Workspace account with an internal app, or to accept the weekly reconnect and set a reminder. On this instance the choice was the reminder, which is why a reconnect checklist exists at all.
Creating a replacement OAuth client
- In Google Cloud Console, open the project, go to APIs & Services, then Credentials, and create an OAuth client ID of type Web application.
- Add n8n's OAuth callback URL as an authorized redirect URI. n8n shows the exact URL in the credential dialog, and it must match character for character.
- Make sure the Gmail API is enabled in the same project.
- In n8n, create a new Gmail OAuth2 credential with the new client ID and secret, and connect it.
- Switch each workflow's Gmail nodes to the new credential, then send one test message.
Checking credential health before you need it
A failed email in the middle of a one-off task is the worst moment to find a broken credential. A small scheduled workflow that uses each Google credential for a harmless read, such as listing one label, and alerts on failure finds a broken credential within a day, independently of the workflows that need it.
Frequently asked questions
What does 'The OAuth client was deleted' mean in n8n?
The Google Cloud OAuth client the credential was built on no longer exists. Reconnecting can't help; you need a new OAuth client and a new n8n credential.
Why do my Google credentials in n8n expire every 7 days?
Google expires refresh tokens after 7 days for external apps whose OAuth consent screen is in Testing status. Publishing the app or using an internal Workspace app avoids it.
Can the n8n API reconnect an OAuth credential?
No. A new refresh token can only come from the Google consent screen in a browser, completed by a person.
How can I detect a broken credential early?
Run a scheduled workflow that makes a harmless call with each credential and alerts you on failure.