On this page
An API key is a string that a service issues to a customer and expects with every API request, so the service can tell which account or project the request belongs to and, for most keys, what that request is allowed to do.
Identify or authorize
Some keys only identify. Google Cloud says a standard API key provides "a way to associate a request with a project for billing and quota purposes", and that such a key "doesn't identify a principal", so the request can't be checked against IAM permissions (Google Cloud). Others carry real power. A Stripe secret key "has unrestricted permissions on all Stripe APIs" (Stripe). Most API keys you put in a backend .env file are of the second kind: whoever holds the string can act as you.
That is what makes an API key a secret. It is a bearer credential: the service can't tell your copy from a leaked one.
Types you will meet
Stripe's key types are a clear example of the range:
| Stripe key | Prefix | Safe to expose |
|---|---|---|
| Publishable | pk_ | yes, meant for browser and mobile code |
| Restricted | rk_ | no; permissions you choose |
| Secret | sk_ | no; full access |
The pattern is common. A publishable key is designed to sit in front-end code, and a public environment variable is the right place for it. A secret or restricted key belongs on servers only. Where a provider offers restricted keys, use them: Stripe recommends restricted keys "for most use cases", and no longer recommends secret keys for new ones.
Common mistakes
- One key for everything. The same key in development, staging and production means a laptop leak is a production leak. Most providers let you create several keys, often with separate test and live modes.
- Keys in front-end code. A secret key behind a
NEXT_PUBLIC_orVITE_prefix ends up in every visitor's browser. - No record of where a key lives. When it has to be replaced, nobody knows which services use it.
- Losing the only copy. Stripe shows a key you create in live mode once; if you lose it, you rotate it.
Replacing a key
Keys get replaced when someone who saw them leaves, when they leak, or on a schedule. The provider issues the new key; your job is to deploy it and revoke the old one, ideally with both working for a short overlap window. That process is credential reissue, and the rotation guides by service cover individual providers, starting with Stripe.
How Crunu stores API keys
In Crunu, an API key is one variable in an environment, for example STRIPE_SECRET_KEY in payments-api / production. The value is encrypted on your device, hidden in the editor until someone with access chooses to show it, and delivered to programs by crunu run. Each environment has its own key, so a person with access to development can't read the production Stripe key.
Crunu recognizes 20 common services, including AWS, Stripe, GitHub, OpenAI and Anthropic, shows their icons, and for most of them links to the page where the provider issues a new key. It does not create or revoke keys at providers. When someone leaves, the reissue checklist lists the API keys they received that are still in use, so you can replace them at each provider. More on getting keys to a team without chat: how to share .env files with your team.
Sources
- Google Cloud: Manage API keys, checked October 30, 2026.
- Stripe Docs: API keys, checked October 30, 2026.
From the blog
Secrets
NEXT_PUBLIC_ leaks: how secrets get into a JavaScript bundle
Any variable with a public prefix is shipped to every visitor. How NEXT_PUBLIC_, VITE_, PUBLIC_ and NUXT_PUBLIC_ work, how to check your bundle, and what to do.
Sharing .env files guide
Practices
Rotating API keys without downtime: the overlap window
Issue the new key, roll it out, confirm the old one is idle, then revoke it. How AWS, Stripe and databases support overlap, and what to do when they don't.
Offboarding guide
CI/CD
GitHub's new OIDC subject format: fixing AWS trust policies
Not authorized to perform sts:AssumeRoleWithWebIdentity on a new repo? GitHub added owner and repo IDs to the OIDC sub claim. How to check and fix the policy.
CI and OIDC guide