Let’s talk
GUIDE

My n8n workflow worked, and now it fails with 401 or 403. Why?

A 401 means the service no longer accepts who the workflow says it is: the token is missing, expired or revoked. A 403 means the service knows who it is but does not allow this action: a permission or scope is missing, or the account is not on an allowed list. Retrying does not fix either; the credential or its permissions have to change.

When a Google connection worked and then stopped, check the Google Cloud app first. If its publishing status is "Testing", Google issues refresh tokens that expire after 7 days (unless the app asks only for basic profile and email), so the workflow fails about a week after each reconnection.

Updated Sep 30, 2026

How it works

  1. Read the failing node

    Open the failed execution and note the node, the status code and the service. The error text usually names the credential it used.

  2. 401: reconnect the credential

    Open the credential in n8n and reconnect or replace the key. If the connection dies again after about a week, look at the app's publishing status.

  3. 403: add the missing permission

    n8n's own advice for a 403 is to update permissions or scopes, or generate a new key with them. A reconnect alone does not add a scope the app never asked for.

  4. Check the grant, not the consent screen

    After approving, confirm the token actually carries the scope the action needs. A consent that looks complete can return fewer permissions than you asked for.

  5. Make the next expiry loud

    Point the workflow to an error workflow that alerts a person, so the next expired credential is a message, not a week of missing records.

What it costs to run

No list price applies: fixing a credential costs no usage. The cost is what did not happen while it was broken: the runs that failed and the records that never arrived.

What we learned building it

From our own booking rehearsal on a fictional Google calendar, with a local n8n run, 28 Sep 2026, and from the webhooks of our own lead handling. Not a client system.

A completed consent still returned a 403
Google showed the approval as done, but the token held only the free/busy permission, not event access, so creating the booking returned 403. We checked the granted scopes, asked for event access again, and it passed.
A test app only lets its listed testers in
Our agency account got "403 access_denied" until it was added to the test users of the Google Cloud app. The error looked like a code problem; it was a list.
A failed refresh means reconnect, not retry
An old connection answered the refresh with "400 invalid_grant". No retry could revive it; reconnecting the account with the same scopes did.
Make your own endpoints say which side failed
Our webhooks answer 403 to a missing or wrong secret and our signed links answer 401 to a bad signature, so a log line tells us at once whether the caller or the link was wrong.

When it is not worth it

  • If a workflow runs once a month and one person watches it, reconnecting by hand when it fails may be enough.
  • If the service offers a key that does not expire and the client accepts that risk, an OAuth app in production review may be more work than the workflow is worth.

Questions

Why exactly every 7 days?

Google issues 7-day refresh tokens to apps whose publishing status is "Testing", unless the app asks only for basic profile and email. Publishing the app, or using an app already in production, removes that limit.

Will creating a new credential fix a 403?

Only if the new one asks for the missing permission, or the account is added where the service expects it. Otherwise it fails the same way.

What else ends a Google refresh token?

Google lists these: the user revoked access, it was unused for six months, the user changed password and the token has Gmail scopes, or the account passed the limit of live tokens.

Sources

Have a client connection that keeps dying and no time to trace it?

See the service: For agenciesLet’s talk

All guides