What Is an API Key? How API Key Authentication Works

An API key is a single credential — usually a long, random string — that identifies the application or project making a request, not necessarily a specific user. It’s the simplest form of API authentication, and one of the oldest: no login flow, no token exchange, just a string that grants access to whoever holds it.

How API Keys Are Sent

API keys travel with a request one of two ways:

In a header (the more common, more secure option):

X-API-Key: sk_live_51H8x2KJ9pL3mN7qR

As a query parameter (simpler to try in a browser, worse for security):

GET /v1/data?api_key=sk_live_51H8x2KJ9pL3mN7qR

The header form keeps the key out of server access logs, browser history, and anything that might screenshot or share a URL. The query-parameter form is still common — some APIs support only that — but it’s the weaker choice when you have one.

API Keys vs. Bearer Tokens vs. Basic Auth

The three overlap in how they’re transmitted but differ in what they represent:

• API keys identify a project or application, are usually long-lived, and rarely expire on their own unless you rotate them manually.
• Bearer tokens (see What Is a Bearer Token) are usually short-lived and tied to a specific login or authorization event.
• Basic auth sends an actual username and password, base64-encoded, on every request.

A practical rule of thumb: if revoking the credential should also end a user’s session, it’s probably a bearer token. If it identifies which app or project is calling your API regardless of who’s using it, it’s an API key.

Where API Keys Come From

Most APIs issue a key the moment you create an account or a project — usually visible once in a dashboard, sometimes only at creation time with no way to view it again (forcing you to regenerate if you lose it). Some APIs issue separate keys per environment (test vs. live) so you can develop against sandbox data without touching production.

Security Best Practices

• Never commit a key to source control. Once it’s in git history, it’s effectively public — rotating the key is the only real fix, deleting the commit isn’t enough.
• Prefer headers over query parameters when the API supports both — query strings end up in logs, browser history, and referrer headers.
• Scope keys narrowly. If your API supports read-only or limited-permission keys, use them for anything that doesn’t need full access.
• Rotate periodically, and immediately if a key might have leaked (pushed to a public repo, pasted somewhere it shouldn’t have been).
• Use environment variables, not hardcoded strings, so the same code can run against different keys per environment without editing source.

Testing API Key Auth

Some APIs expect the key in a custom header, others in a query parameter, and getting it wrong just looks like a generic 401 with no explanation. HTTP Titan’s Auth tab has a dedicated API Key mode with a header/query toggle, so switching between the two while debugging is a dropdown, not a rewrite of the request.