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.