deleted_client error. This guide explains exactly what Google counts as inactivity, what breaks the moment a client goes, how long the restore window really is, and where the risk sits in a production setup.What actually changed
Google added an unused-client deletion policy to the OAuth 2.0 Policies page on 27 October 2025. The wording is short and it is not optional: Google reserves the right to delete unused OAuth clients when a client has been inactive for at least six months.
This is not a verification rule and it is not tied to sensitive or restricted scopes. It applies to the credential itself. An app that passed verification years ago, sitting in a project nobody logs into, is exactly the profile this policy is aimed at — and exactly the profile most likely to be caught out by it.
What Google counts as “inactive”
This is the part most teams get wrong. A client is treated as unused only if both of the following have gone six months without happening. One of them alone is not enough to keep it alive.
No token activity
The client has not been used for any credential or token request against Google’s OAuth 2.0 endpoint. Traffic to Google APIs using an already-issued token is not the same thing as a token request.
No configuration change
Nobody has edited the client’s settings, manually or programmatically — no name change, no secret rotation, no redirect URI update.
The counter is per client
A busy project does not protect a quiet client inside it. Each OAuth client is assessed on its own activity, so the unused staging client in an active project is still at risk.
One email is your only warning
Google sends a notification 30 days before a scheduled deletion — to the project contacts on file. If that address is a departed employee or an unmonitored alias, the warning is effectively invisible.
The timeline, end to end
Last token request or configuration edit on the client. The six-month clock starts here.
Google emails the project contacts: the client is scheduled for deletion in 30 days. Using the client for an authorization request before the window closes stops the deletion.
The client is deleted. Sign in with Google stops working through it, existing access and refresh tokens fail, and authorization attempts return a deleted_client error. A second email confirms the deletion.
Deleted clients are typically recoverable for at least 30 days from the Deleted Credentials page in the Cloud Console.
Recovery is no longer available. A new client means a new client ID — and every user of the old client has to re-authorize.
Why the failure is worse than it looks
Losing a client is not a credential problem you can quietly swap out. It is a re-consent event for every user attached to it.
Refresh tokens die with the client
The whole point of a refresh token is that the user is not in the loop. When the client is deleted, those tokens fail — so a background job that has run unattended for two years stops, and the only fix is getting each affected user back through a consent screen.
A new client ID is not a drop-in replacement
Recreating the client gives you a different client ID and secret. Redirect URIs, JavaScript origins, branding, App Check, Android SHA-1 fingerprints and store IDs all have to be re-established, and anything that hard-coded the old ID needs to ship a release.
Verification is a separate exposure
If the app used sensitive or restricted scopes, rebuilding the OAuth setup around a fresh client is the point where brand and scope verification questions resurface. That is a review process on its own timeline, not a console setting — see our Google Workspace API verification guide for how that path differs.
The clients most at risk are the ones nobody watches
Disaster-recovery clients, annual reporting integrations, a client created for a customer who onboards next quarter, the “old” client kept live during a migration. These are all legitimately dormant and all sitting on the same six-month clock.
Where this needs handling, not a reminder
Setting a calendar reminder is not a control. The work is knowing which clients you actually have, which ones are genuinely dormant, and which ones cannot be allowed to lapse — then making the lifecycle survivable. At a high level this is the sequence handled as part of a managed Google API setup.
Inventory every OAuth client across every project, including the ones auto-created by Apps Script, Firebase and other Google platforms on your behalf.
Classify each client: production, staging, dormant-but-required, or genuinely obsolete — because the correct action for the last category is a deliberate deletion, not keeping it alive.
Fix the notification path first, so the 30-day warning reaches a monitored contact rather than a former employee’s inbox.
Put a keep-alive discipline on the clients that must not lapse, using activity that Google actually counts.
Document the recovery path for each production client, so a deletion is a 30-day restore rather than a re-consent campaign across your entire user base.
What a properly managed setup gets you
If your integration also touches the YouTube Data API, the client-lifecycle question sits on top of a separate authorization decision — our breakdown of API key vs OAuth 2.0 for YouTube covers which path pulls you into verification in the first place.
Common ways teams lose a client
Not sure which of your OAuth clients are on the clock?
Google’s unused-client deletion turns every dormant credential into a dated liability, and the recovery window is short. I provide hands-on Google OAuth and API verification support — client inventory and lifecycle review, scope and verification preparation, and getting a broken or rebuilt OAuth setup back into a working, review-ready state. Details on the Google API verification service page.
Approval support, verification preparation and technical implementation support only. Policy rules described here are summarised from Google’s published OAuth 2.0 Policies and Cloud Console documentation as of August 2026; Google may change them, and all review and verification decisions rest solely with Google.