Google API Key Management: Practical Setup and Security
Google API Key Management: Practical Setup and Security
Google API key management means creating, restricting, storing, rotating, and monitoring the API keys you use to call Google Cloud APIs — Maps, Places, Translate, Vision, YouTube Data, and dozens of others. The core problem is always the same: a Google API key is a bearer credential with no built-in expiry, so if it leaks, anyone can use it against your billing account until you notice and revoke it.
If you're here because you just got a "suspicious activity" email from Google Cloud, or you're setting up your first project and want to avoid a surprise bill, this article covers the practical steps: where keys live, how to restrict them properly, how to rotate them without breaking production, and how key management differs when you move from simple data APIs to AI/LLM APIs.
Where Google API keys are managed
Every Google API key belongs to a Google Cloud project and lives under APIs & Services > Credentials in the Cloud Console. From there you can:
- Create a new API key
- Restrict which APIs a key can call ("API restrictions")
- Restrict where a key can be used from ("application restrictions": HTTP referrers, IP addresses, Android/iOS app identifiers)
- Regenerate or delete a key
- View usage per key in the "Metrics" tab
There is no built-in concept of "sub-keys per user" or per-team quotas inside a single key — Google API keys are flat, project-scoped credentials. If you need per-user or per-application isolation, you create separate keys and separate restrictions for each, which becomes a manual bookkeeping problem as the number of integrations grows.
Step 1: Restrict every key to specific APIs
The single most common mistake is creating an "unrestricted" key that can call any enabled API in the project. When you create a key:
- Go to Credentials > Create Credentials > API key
- Click "Restrict Key" immediately
- Under "API restrictions," select only the specific APIs this key will call (e.g., only Maps JavaScript API, not the whole Maps platform)
A key restricted to one API is useless to an attacker for anything else, even if it leaks.
Step 2: Restrict by application context
Application restrictions limit where the key can be used from, independent of which API it calls:
- HTTP referrers — for browser-based JavaScript, restrict to your actual domains (
https://yourapp.com/*) - IP addresses — for server-side calls, restrict to your known outbound IPs
- Android/iOS app — restrict by package name + SHA-1 fingerprint, or bundle ID
Browser keys with referrer restrictions are still visible in your frontend source, so referrer restriction is a mitigation, not a secret. Server-side keys with IP restriction are closer to a real secret and should be treated like one — never committed to a repo, never logged in plaintext.
Step 3: Store keys outside your codebase
Basic hygiene that's still worth stating explicitly:
# Bad: hardcoded in source
const apiKey = "AIzaSyD-abc123...";
# Better: environment variable, loaded at runtime
const apiKey = process.env.GOOGLE_API_KEY;For anything beyond a personal project, use Secret Manager (or your CI/CD's secret store) rather than .env files checked into version control. Add a pre-commit hook or CI scan that flags strings matching Google's key pattern (AIza...) before they reach a public repo — leaked Google API keys get scraped and abused within minutes of hitting GitHub.
Step 4: Rotate keys on a schedule, not just after incidents
Rotation for Google API keys is manual: generate a new key, update it everywhere it's used, confirm traffic has shifted, then delete the old one. To do this without downtime:
- Create the new key with identical restrictions
- Deploy it alongside the old key (most services read the key from config, so this is a config change, not a code change)
- Watch the Metrics tab to confirm the new key is taking traffic
- Delete the old key only after traffic has fully shifted
Doing this quarterly, or whenever someone with key access leaves the team, keeps your exposure window small even if a leak goes unnoticed.
Step 5: Set quotas and monitor usage
Under APIs & Services > Quotas, set per-API request limits so a compromised key or a runaway script can't generate an unlimited bill. Pair this with billing alerts on the project itself. The Metrics tab per credential shows request volume and error rates per key, which is often the first signal that a key has leaked — a sudden spike from unfamiliar traffic patterns.
Where this gets harder: AI API keys across a team
Google Cloud's key management model — restrict, rotate, monitor per key — works well for stable, single-purpose keys like a Maps widget. It gets harder once a team is issuing keys for AI/LLM access across multiple products, environments, and people, because you also need to know who used a key, how much it cost, and what happened on a per-request basis (which model, how many tokens, was a tool called), not just raw request counts.
This is the same underlying problem, just with different data. If your team is already managing Google Cloud API keys carefully and now needs to give multiple apps or engineers access to Claude, doing it manually — one shared key, no per-app breakdown, no usage metadata — recreates the exact blind spot you're trying to avoid with Google's keys. SubToAPI turns a Claude account into a proper API surface: distinct sub_live_... keys per application, streaming and tool use over plain HTTPS, and usage metadata per key so you can see cost and activity by team or project instead of by one shared credential. Setup follows the same pattern as any REST API — see the quickstart — and plans start at €9/month with a free trial at signup.
FAQ
How do I restrict a Google API key to one specific API?
In Cloud Console, go to Credentials, select the key, click "Restrict Key," then under "API restrictions" choose the specific API(s) it should be allowed to call. Save — the restriction applies immediately.
What should I do if a Google API key leaks?
Regenerate the key immediately from the Credentials page (this invalidates the old one instantly), update your app config to use the new key, and check the Metrics tab for unusual usage during the exposure window before deleting the old key entry.
Are Google API keys the same as OAuth client credentials?
No. API keys authenticate the calling project and are used for public/anonymous access to certain APIs. OAuth client IDs and service account keys authenticate a user or service identity and are required for APIs that access private user data — they follow separate management flows in the same Console.