What Are API Keys?

When your app calls an external API — to generate text, charge a card, send email, or fetch weather — the service needs to know the request is really from you. An API key is that proof: a long random string tied to your account.

You paste the key into your app's configuration. Server code includes it in request headers (Authorization: Bearer sk-..., or X-API-Key: ...). The provider checks the key, applies rate limits and billing to your account, and returns data.

Keys are not encryption. They are identifiers with privileges. If someone copies your Stripe secret key, they can create charges. If someone copies your OpenAI key, they can run models on your bill.

AI coding tools generate integrations fast — and often drop real keys into .env files or even source code. First-time makers upload the whole folder to GitHub without reviewing. Within minutes, bots scan public repos for key patterns and abuse them.

Launch multiplies exposure. Production keys often have higher limits than test keys. A leaked production Stripe key can process real payments; a leaked OpenAI key can burn through credits overnight.

Before sharing any public URL, confirm keys are not in your repo history, not in client-side JavaScript, and rotated if they were ever exposed. These are launch-blockers, not nice-to-haves.

Local development: a .env file in your project root, listed in .gitignore. Your code reads process.env.OPENAI_API_KEY, os.environ['OPENAI_API_KEY'], or the equivalent for your stack. The .env file stays on your laptop — it never goes to GitHub.

Production: your hosting dashboard's environment variables panel. On Vercel, that is Project → Settings → Environment Variables. On Railway, it is your service's Variables tab. On Render, it is Environment → Environment Variables. You type the same variable names but paste your production key values.

Sharing with teammates: a password manager or secrets vault, never Slack, email, or a committed file. Your teammates each maintain their own local .env with their own test keys. Commit .env.example with placeholder values so teammates know what variables the app needs.

Never in source code files (.js, .ts, .py, etc.) as string literals. Even if you delete the line later, the value lives in Git history and can be extracted.

Never in GitHub — not in .env files, not in comments, not in README examples with real values. Even private repositories expose keys to every collaborator, and repository visibility can change.

Never in frontend JavaScript that the browser downloads. Anything in your bundle — including environment variables prefixed NEXT_PUBLIC_ or VITE_ — is visible to every user who opens DevTools. Backend API calls should proxy requests rather than send keys to the browser.

Never in screenshots, screen recordings, Notion pages, or support tickets. Keys embedded in images are readable. Paste placeholder strings when demonstrating configuration.

Frontend apps (React, Vue, plain HTML) run in the browser. There is no safe way to include secret API keys — the source code ships to the user's machine. If your AI-built frontend calls OpenAI directly, that key is visible to anyone with browser DevTools.

The correct pattern: create a backend route (a Next.js API route, a Django view, a Node Express endpoint) that receives requests from your frontend, makes the API call server-side with the key stored as an environment variable, and returns only the safe response data to the browser.

Some SDKs offer client-safe versions: Stripe's publishable key for frontend checkout widgets, Supabase's anon key for client SDKs when row-level security is configured correctly. Read the provider's documentation before trusting any key in the browser.

A .env file is a plain text file in your project root that stores environment variables for local development. Each line has the format KEY=value, for example OPENAI_API_KEY=sk-proj-abc123. Your application reads them when it starts; they are never baked into your built code.

The .env file must be listed in .gitignore — that one-line addition to .gitignore prevents the file from ever being committed to Git. Verify it is there before your first push. If .env already shows up in GitHub Desktop's file list, add it to .gitignore before committing.

Use separate .env files for different environments if your setup supports it: .env.local for local overrides, .env.test for test runs, .env.production for build-time public variables. The naming conventions vary by framework — check your framework's documentation.

.env.example is a safe template that you commit to GitHub. It lists every variable your app needs but uses placeholder values — OPENAI_API_KEY=your_key_here instead of a real key. It tells collaborators (and your future self) what to fill in without exposing real secrets.

When someone clones the project, they copy .env.example to .env and paste their own real values. The real .env is excluded by .gitignore. This two-file pattern is the standard way to document required secrets without leaking them.

If your project does not have a .env.example yet, create one. List every variable from your .env with placeholder strings as values. Commit it. This is a small step that prevents significant confusion and security problems.

Payment providers often give two keys. Stripe's publishable key (pk_live_...) is designed for frontend checkout widgets — limited power, relatively safe in browsers. The secret key (sk_live_...) must stay server-side only. Never send it to the browser.

OpenAI, Anthropic, and most AI providers issue keys that are always secret. There is no safe browser exposure — route AI calls through your backend.

Supabase and Firebase use anon keys for client SDKs with row-level security rules, plus service role keys that bypass security and must never ship to browsers. Read each provider's documentation — naming varies across services.

Assume compromise if a secret touched GitHub, was pasted in a screenshot, or appeared in client-side code. Rotation is urgent, not optional. Open the provider dashboard, revoke the old key, generate a new one, update your local .env and hosting env vars, and redeploy.

Removing the file from your latest commit is not enough — Git history still contains the exposed value. Bots continuously scan commit history. Rotate the key regardless of whether you clean up history; then use git filter tools or GitHub's guidance on removing sensitive data from history.

Check your billing dashboard for unexpected usage. Report significant abuse to the provider — many have processes for reversing fraudulent charges when you report promptly after discovering an exposure.