# When to Use API Keys

## The Right Tool for the Job

API keys are one of the most versatile authentication mechanisms available, but they are not appropriate for every scenario. This page provides a practical decision framework to help you determine whether API keys are the right fit for your use case.

## Good Use Cases for API Keys

### Server-to-Server Communication

API keys excel when one backend system calls another. In this model, the key identifies the calling service or organization, and the secret never leaves a controlled server environment. There is no end user in the loop, no browser involved, and the key can be stored securely in environment variables or a secrets manager.

This is the most common and most appropriate use case for API keys. Examples include a payment service calling a fraud-detection API, a backend fetching data from a third-party weather service, or a CI/CD pipeline interacting with a deployment API.

### Public Developer APIs

If you are building an API that external developers will consume, API keys are the standard entry point. They let you identify which developer (or application) is making a request, enforce [per-consumer rate limits](/docs/security/rate-limiting), and track usage for billing or analytics.

Platforms like Stripe, Twilio, SendGrid, and Google Maps all use API keys as the primary mechanism for developer access. The key ties requests to a billing account, making it easy to meter usage and generate invoices.

### Usage Metering and Billing

API keys are a natural fit for usage-based business models. Because every request carries a key that maps to an account, you can count requests, measure resource consumption, and apply tiered pricing, all without complex token introspection or user-session management.

### Internal Tooling and Automation

For internal APIs consumed by scripts, cron jobs, or internal dashboards, API keys offer a low-friction solution. They are easy to issue, easy to [rotate](/docs/security/key-rotation), and avoid the overhead of setting up an OAuth authorization server for an audience of internal services.

## Bad Use Cases for API Keys

### User-Level Authentication

API keys identify _applications_, not _users_. If your API needs to know which individual person is making a request (for example, to return that user's data or enforce per-user permissions), API keys alone are insufficient. You would need to build a separate user-to-key mapping, which quickly becomes an ad hoc (and likely insecure) reimplementation of OAuth.

For user-level authentication and authorization, use OAuth 2.0, OpenID Connect, or session-based authentication.

### Client-Side or Browser Applications

API keys must be kept secret. Any key embedded in a browser application, mobile app bundle, or client-side JavaScript is effectively public. It can be extracted by anyone who inspects the source code or network traffic.

If you must authenticate from a client-side application, use a backend proxy that holds the API key, or use a user-level authentication flow like OAuth 2.0 with PKCE, which was designed specifically for public clients.

### Scenarios Requiring Fine-Grained Delegation

OAuth 2.0 supports scopes that let a user grant an application access to specific resources ("read my email but not my contacts"). API keys have no built-in concept of delegated, user-consented permissions. If your API requires this model, OAuth is the better choice.

## Decision Framework

Use the following checklist to determine whether API keys are appropriate for your scenario:

| Question | If yes... |
| --- | --- |
| Is the caller a server or backend service? | API keys are a strong fit. |
| Do you need to identify and bill the calling application? | API keys are ideal for this. |
| Does the API act on behalf of a specific end user? | Use OAuth 2.0 or JWTs instead. |
| Will the key be exposed in client-side code? | Do not use API keys directly; add a backend proxy. |
| Do you need delegated, user-consented scopes? | Use OAuth 2.0. |
| Is simplicity and fast time-to-market a priority? | API keys have the lowest implementation overhead. |

### A Practical Rule of Thumb

If your API consumer is a **server** and you need to answer the question "which application or account made this request?", API keys are almost certainly the right starting point. If your API consumer is a **user** and you need to answer "which person is making this request and what are they allowed to do?", you need a user-level authentication protocol.

Many successful APIs start with API keys and add OAuth 2.0 later when user-level delegation becomes a requirement. The two mechanisms are [complementary, not competing](/docs/introduction/api-keys-vs-other-auth).