An API key is a credential that identifies which application is calling a service. It helps providers enforce quotas, billing, and access policies for automated requests.

For beginners, the biggest risk is not understanding where keys should live. Secret API keys belong in protected environment variables and should never be pasted into public repositories, client-side bundles, or screenshots. Some providers also issue deliberately publishable client keys with restricted powers, so the provider's documentation determines whether a particular key is secret.

What API keys do and what they do not do

API keys are usually identification and access tokens, not full user authentication systems. They tell a service which app is calling, but they do not automatically prove a specific end-user identity unless combined with another auth layer.

Different providers assign different permissions to each key. A read-only key should not also allow write or delete operations when that capability is unnecessary. Least privilege limits damage if a key leaks.

Safe storage and loading patterns

The shell and JavaScript examples below are illustrative and intentionally use placeholder values. They show the right pattern: read keys from environment variables and fail early if a key is missing. Do not hardcode real credentials.

In production, rotate keys regularly, track where each key is used, and disable keys you no longer need. Key management is an operational habit, not a one-time setup.

bashIllustrative shell: load a placeholder API key from an environment variable
# Use placeholder values only in examples; never commit real credentials.
export WEATHER_API_KEY="example_key_replace_in_local_env"

# Confirm variable exists without printing the secret itself.
if [ -z "$WEATHER_API_KEY" ]; then
  echo "Missing WEATHER_API_KEY"
  exit 1
fi

Calling an API from JavaScript without leaking secrets

When a provider designates a key as secret, a browser application should call your own backend and let the backend call the third-party API. This keeps the credential out of client bundles and browser developer tools. Public client keys are different: they must be restricted by origin, scope, quota, or another control because every browser user can inspect them.

The JavaScript example demonstrates server-side usage with placeholders. It validates configuration and uses an X-API-Key header only as an illustration; real APIs may require that header, an Authorization scheme, a signed request, or another provider-specific format.

javascriptIllustrative JavaScript: server-side fetch using environment variables
const apiKey = process.env.WEATHER_API_KEY

if (!apiKey) {
  throw new Error("Missing WEATHER_API_KEY")
}

async function fetchForecast(city) {
  const res = await fetch(`https://api.example.com/forecast?city=${encodeURIComponent(city)}`, {
    headers: {
      // Follow the real provider's documented authentication scheme.
      "X-API-Key": apiKey
    }
  })

  if (!res.ok) {
    throw new Error(`Forecast request failed with status ${res.status}`)
  }

  return res.json()
}

API keys are simple to start with but easy to misuse. Treat them like secrets, keep them server-side, and build habits that make leakage less likely.

Topics
Back to all writing