YouTube Data API: invalid_grant, refresh token expired

• The user revoked access. Either directly from Google Account > Security > Third-party access, or as a side effect of changing their Google Account password in some account-security scenarios. This is the most common real-world cause and the one worth checking first.
• Six months of inactivity. A refresh token that goes unused for six consecutive months expires automatically. Critically, calling the YouTube API with the resulting access token does not reset this clock — only an actual token-refresh request against the refresh token counts as activity, so an integration that mints one long-lived access token and never refreshes can still lose the refresh token silently in the background.
• The 50-token-per-client-per-user limit. Google allows at most 50 live refresh tokens for a given OAuth client ID and Google Account combination. Once that ceiling is hit, issuing a 51st refresh token — which happens every time that user completes the consent flow again — silently invalidates the oldest one. Integrations that re-run the full OAuth flow on every reconnect (instead of reusing a stored token) hit this far more than expected, and the failure lands on whichever other, unrelated integration happened to be holding that oldest token.
• The app is stuck in Testing publishing status. An OAuth client on Google Cloud Console with an External audience and "Testing" publishing status has every refresh token it issues expire after exactly 7 days, regardless of activity. This is easy to miss because everything works correctly in initial development and then starts failing a week after each test connection — the fix is moving the OAuth consent screen to "In production," which removes the 7-day ceiling.

Retrying the same refresh request will not succeed — the token is not in a transient bad state, it is permanently invalidated. Requesting a new access token with the same refresh token, waiting, or restarting your server all leave the underlying refresh token exactly as invalid as before. The only path back to a working connection is a fresh authorization: the channel owner has to go through Google's consent screen again, at which point your app receives a brand-new refresh token to store in place of the dead one.

• Refresh tokens on a real, predictable cadence — well inside six months — so the inactivity-expiry clock never has a chance to run out, and treat a scheduled refresh as the source of truth for "is this connection alive," not a wait-and-see approach.
• Never re-run the full OAuth authorization flow just to get a fresh access token for a channel that already has a valid refresh token — that behavior is exactly what burns through the 50-token limit and can knock out someone else's working connection as a side effect.
• Confirm the OAuth consent screen's publishing status is "In production" before shipping — a client left in Testing status will look completely fine for a week and then start failing every connection made during development or an early rollout.
• Treat invalid_grant as a terminal, non-retryable state that requires user action, not a transient error to back off and retry.

PostGate refreshes YouTube connections proactively on a fixed schedule rather than reactively on demand, and because PostGate's own hosted Google Cloud project runs in production publishing status, the 7-day testing-mode expiry never applies to a channel connected through PostGate. When a refresh does return invalid_grant — most often because the channel owner revoked access — PostGate marks the profile reauth_required instead of letting the next scheduled upload fail against a dead token. See profile health and the YouTube quota model, a separate mechanism that can also block an upload but for a completely different reason.