Store API keys in environment variables, never in source code. Add .env to .gitignore. Use keys server-side only — never expose them in client-side JavaScript. Rotate keys if you suspect a leak. Use different keys for development and production.
Your API key is directly tied to your credit balance and billing. Anyone who has your key can make requests on your account, consume your credits, and potentially access your usage data. A leaked key in a public GitHub repo is typically discovered and exploited within hours by automated scanners.
The consequences of a leaked API key range from inconvenient (unexpected charges) to severe (hitting rate limits that break your production app, or an attacker making requests that get your key suspended). Treating API keys with the same care as passwords is not paranoia — it is standard practice.
The most common mistake is hardcoding API keys directly in source code. This is dangerous because source code is shared, versioned, and often stored on multiple machines.
Store your API key in an environment variable and read it at runtime. Every programming language has a way to access environment variables. Use a `.env` file for local development and set environment variables directly on your hosting platform for production.
# .env file (local development only — never commit this)
PRICEFETCH_API_KEY=pf_live_abc123
# .gitignore — add this line
.env
.env.local
.env.production
# Python — reading the key
import os
api_key = os.environ["PRICEFETCH_API_KEY"]
# Node.js — reading the key
const apiKey = process.env.PRICEFETCH_API_KEY;
# If the key is missing, fail loudly
if (!apiKey) throw new Error("PRICEFETCH_API_KEY not set");Even if you use environment variables, it is easy to accidentally commit a `.env` file or a test file with a hardcoded key. Here is how to prevent that:
Add `.env` to `.gitignore` before your first commit. If you add it later, git already tracks the file and the ignore rule will not apply to existing tracked files.
Use `git diff --staged` before every commit to review what you are about to commit. Look for strings that start with API key prefixes (like `pf_live_`, `sk_`, or `key_`).
Use a pre-commit hook that scans for potential secrets. Tools like `git-secrets`, `trufflehog`, or `detect-secrets` automatically block commits that contain patterns matching API keys or passwords.
If you have already committed a key to git history, rotating the key is more important than rewriting git history. Rotate the key immediately (generate a new one in your dashboard), then clean up the git history if needed. The key should be considered compromised the moment it entered version control.
API keys must never appear in client-side JavaScript. Any code that runs in the browser is visible to the user — they can open DevTools, inspect network requests, and extract your API key.
The correct pattern is to call the price API from your server (an API route, serverless function, or backend service) and have your frontend request data from your own server. Your server acts as a proxy: the API key lives only on the server, and your frontend never sees it.
In Next.js, this means using API routes or server components — not calling the price API directly from a client component. In a traditional frontend + backend architecture, the backend handles all API calls.
// WRONG — API key exposed in browser JavaScript
// src/components/PriceChecker.tsx (client component)
const response = await fetch(
`https://api.pricefetch.dev/v1/price?url=${url}`,
{ headers: { "X-API-Key": "pf_live_abc123" } } // Visible in DevTools!
);
// CORRECT — API key stays on the server
// src/app/api/price/route.ts (Next.js API route — server-side)
export async function GET(request: Request) {
const { searchParams } = new URL(request.url);
const url = searchParams.get("url");
const response = await fetch(
`https://api.pricefetch.dev/v1/price?url=${url}`,
{ headers: { "X-API-Key": process.env.PRICEFETCH_API_KEY! } }
);
return Response.json(await response.json());
}
// Client component calls YOUR server, not the price API directly
const response = await fetch(`/api/price?url=${url}`);Use separate API keys for development and production. If your development key leaks (which is more likely since dev environments are less controlled), your production service is unaffected.
Rotate your production key periodically — every 3-6 months is a reasonable cadence. When you rotate, generate the new key in your dashboard, update your production environment variable, verify the new key works, then deactivate the old key.
If you suspect a key has been compromised — it appeared in logs, was shared in a chat message, or showed up in a public repo — rotate immediately. Do not wait. Generate a new key and deactivate the old one within minutes.
Most API dashboards (including PriceFetch) let you regenerate your key with one click. The old key is deactivated immediately and a new key is issued. Update your environment variables wherever the key is used.
Sign up in 30 seconds. No credit card required. One credit per successful API call.