API Keys: What They Are, Where They Go, How To Not Leak Them

Every API requires you to prove who you are before it lets you do anything. The most common way to do that is with an API key — a long string of characters that functions like a password for machine-to-machine communication. It identifies you, grants access, and — if you handle it wrong — lets someone else run up your bill. API key management is one of those skills that seems like a minor detail until you leak a key and it becomes the only thing that matters.

What The Docs Say

The documentation for any API-based service will tell you to generate an API key in your account dashboard or developer settings. The exact location varies by service — OpenAI keeps them in the API section of your account, Stripe has a separate developer dashboard, Ghost puts them in custom integrations — but the concept is the same everywhere. You create a key, the service stores a reference to it, and you include that key in your API requests to prove the request is coming from you.

Docs typically describe several types of authentication. The simplest is an API key — a static string that identifies your account. Bearer tokens are session-based — you authenticate once, get a temporary token, and use that token for subsequent requests. OAuth tokens are more complex — they let a user authorize your application to access their data on a service (this is what happens when you click "Connect your Google account" in a tool like Zapier). Each type has different security properties and different use cases, but API keys are by far the most common thing you'll encounter when you're making direct API calls.

The key goes in different places depending on the API. Some APIs want it in the request headers (the most common approach — you'd include something like Authorization: Bearer sk-abc123... in the header). Some want it as a URL parameter (api.example.com/data?api_key=abc123). Some expect it in the request body. The documentation tells you which approach to use, and it matters — putting the key in the wrong place is one of the most common reasons a first API call fails.

What Actually Happens

The generation step is usually straightforward. You find the developer section, click "Create new key," and the service shows you a string of characters — typically 30 to 60 characters long, a mix of letters, numbers, and sometimes special characters. Many services show you the key exactly once. If you close that dialog without copying it, you'll need to generate a new one. This catches people off guard regularly, so copy the key immediately and store it somewhere safe before doing anything else.

Here's where the gap between docs and reality shows up: the docs explain authentication as a technical specification. What they don't explain with nearly enough urgency is the security side. An API key is functionally a password that grants access to a service — often a paid service with metered billing. If someone else gets your OpenAI API key, they can make API calls that appear on your bill. If someone gets your AWS access key, the damage can be significantly worse — there are well-documented cases of leaked AWS keys resulting in thousands of dollars in charges within hours as automated scripts spin up compute resources [VERIFY — specific dollar amounts vary, but the pattern is well-documented on Hacker News and AWS security blogs].

The most common way people leak keys is by committing them to a public GitHub repository. You're building a project, you hardcode the API key into your code because it's just a test — and then you push to GitHub. Automated bots scan public repositories for API key patterns. Within minutes, your key is compromised. GitHub now has secret scanning that catches some of these, but relying on GitHub to save you is not a security strategy.

Other common leak vectors: sharing code snippets in public forums or chat channels with the key still in them, putting keys in client-side JavaScript (which is visible to anyone who opens browser developer tools), including keys in screenshots of code, and storing them in shared documents or wikis without access controls.

The secure approach is environment variables. Instead of putting api_key = "sk-abc123..." directly in your code, you store the key in a .env file (a simple text file that holds configuration values) and reference it by name in your code. The .env file stays on your machine — you add it to your .gitignore file so it never gets committed to version control. For deployed applications, hosting platforms like Vercel, Netlify, Railway, and Render all have dedicated secret storage where you can set environment variables that your code can access without the values ever appearing in your repository.

The pattern is always the same: keys stay in the environment, never in the code. If you only remember one thing from this article, remember that.

When To Use This

You'll deal with API keys the moment you move beyond pre-built integrations. When a Zapier or n8n integration asks you to "connect your account," what's often happening behind the scenes is an OAuth flow or API key entry — the tool stores the key for you and includes it in every request automatically. But when you use an HTTP Request node to call an API directly, or when you use Postman or curl, you're responsible for including the key yourself.

The practical workflow looks like this: generate the key in the service's dashboard, store it in a .env file or your automation tool's credential store, reference it by name (never by value) in your requests. When testing in Postman, use Postman's environment variables to store the key rather than pasting it into every request. When building in n8n, create a credential for the service and reference that credential in your HTTP Request node.

Key rotation is also worth understanding. Some services let you have multiple active keys — generate the new one, update your applications, then revoke the old one. This is how you change keys without downtime. If a service only allows one active key at a time, you'll have a brief window where your applications break while you update them with the new key. This is annoying but manageable for most non-critical workflows.

When To Skip This

If you exclusively use pre-built integrations in automation tools and never make direct API calls, the tool handles key management for you. Zapier's "connect your account" flow stores credentials securely — you don't need to manually manage keys for those connections. The same is true for most native integrations in n8n, Make, and similar platforms.

But skipping this knowledge has a ceiling. The moment you need a custom API connection, or the moment a credential error shows up in your workflow and you need to debug it, you're back here. Understanding what an API key is, where it goes, and why it matters is the baseline literacy that makes everything else in this series possible.

If you think you may have leaked a key — even if you're not sure — revoke it immediately and generate a new one. Then check your service's usage logs for any activity you don't recognize. Speed matters here. The time between "I think that key might be exposed" and "I've revoked and replaced it" should be measured in minutes, not hours. The paranoid approach is the correct approach.

This is part of CustomClanker's API Literacy series — the thing nobody explains before you try to connect two tools.