What I found
- The local vault now has
SAIL_GOOGLE_ADS_* and GOOGLE_ADS_* pointing to the same client ID family (961786446236-...) and the same refresh token.
SAM_GMAIL_GOOGLE_ADS_REFRESH_TOKEN is a separate lane for samaguiar1982@gmail.com.- The
gmail lane still works, but only exposes the primary 381 account (3681763507) as a manager account.
- The
generic / sail lane currently fails with invalid_grant.
Root-cause read
- Part of the mess is real token churn.
- Part of the mess is stale documentation that still describes older app/client layouts.
- Official Google docs say refresh tokens can die after 7 days in
Testing, and older tokens can also be invalidated if too many are minted for the same user/client.
Account-path mapping
aguiarlawmarketing@gmail.com is documented as the lane that sees the 381 account plus the protected LSAs.samaguiar1982@gmail.com is documented as having a separate MCC / extra accounts, but the current live preflight did not expose a non-manager Search client there.AW-939966791 still appears to live outside the currently visible direct-access path.
Durable recommendation
- Keep one canonical OAuth client.
- Keep one named token per Google identity.
- Repair only one non-Gmail lane next instead of rotating everything.
- Verify the SAIL consent screen is
In production, then repair aguiarlawmarketing@gmail.com and rerun guarded preflight.
Local artifact