API key

How API keys work

An API key is the simplest credential an API can issue. The provider generates a long random string, ties it to an account or project and checks it on every request. If the key is valid, the call runs and the usage counts against that account. If it is not, the API refuses the call.

Most data APIs read the key from a request header. RichAPI expects x-api-key on every request, and the same key and credit pool sit behind every endpoint 4. Google Cloud recommends a header over a query parameter, since a key placed in a URL can be harvested through URL scans 1.

That convenience is the main risk. A key is a bearer credential, so anyone who has the string can use it, and the API cannot tell a leaked copy from the original. The NCSC describes API keys as shared bearer tokens that are easily compromised through poor secrets management, and notes that they often offer broad access without expiration or a way to limit permissions 2. It recommends stronger methods such as signed JWTs or certificates 2.

Keys leak in predictable places.

• Source code. Google Cloud warns that keys hardcoded in source or committed to a repository are open to interception or theft 1.
• Client apps. A key shipped inside browser or mobile code can be extracted by any user. The client should send requests to a server, which adds the credential 1.
• Shared keys. One key used by a whole team leaves no audit trail. Google Cloud suggests a separate key for each team member and application 1.
• Forgotten keys. Unused keys widen the attack surface, so delete the ones nobody needs 1.

For a usage-billed B2B data provider, a leaked key is a direct cost. Every call it makes spends the account balance, whether the caller is a production AI agent or a stranger who found the string in a public repository.

Keys and OAuth often live side by side. RichAPI uses the API key for REST calls and OAuth for connections to its MCP server, so an assistant connected over MCP never sees the raw key, and disconnecting that connection revokes its access 3.

How to manage API keys in production

Key hygiene is mostly process. Six habits prevent most incidents.

**Store keys in a secrets manager.** Never paste them into notebooks, tickets or chat threads. The NCSC recommends a secrets manager and warns that secrets kept in many places become hard to audit, a problem it calls secrets sprawl 2.

**Keep keys on the server.** Route browser and mobile requests through a backend that adds the credential 1.

**Use one key per workload.** Separate keys for production, staging and each client make a leak easier to trace and contain. On RichAPI, every workspace has its own API keys, and workspaces keep their own credentials, requests, usage and billing 3.

**Restrict what a key can do.** Google Cloud recommends restrictions so a compromised key can do less damage 1. Where a provider has no per-key scopes, separate workloads at the account or workspace level instead.

**Rotate on a schedule and after any exposure.** The NCSC says a credential lifetime should fit the use case and the threat, with rotation automated where possible 2. Rotation is cheap when the key lives in one secrets store and slow when it has been copied into ten scripts.

**Watch usage every day.** A spike in calls or credit burn outside normal hours is often the first sign of a leak. RichAPI has a free usage endpoint, which makes a nightly anomaly check cost nothing to run 4.

If a key leaks, revoke it first and investigate second. On RichAPI, revoked keys stop working immediately, so containment starts the moment someone acts 3.

Example of containing a leaked API key at an agency

An agency runs data enrichment jobs for several clients. All of them share one key that sits in a team spreadsheet. A contractor copies the key into a script, pushes the script to a public repository, and the key starts spending credits overnight.

Before                          After
one key in a spreadsheet        one named key per client
copied into scripts             loaded from a secrets manager
no owner                        named owner per key
no usage check                  nightly usage report with an alert
analysts share the server key   analysts sign in with OAuth

The response starts with revocation. The team revokes the leaked key from the dashboard, and the stranger's calls fail at once 3. Each client then gets its own named key, so a future leak can be revoked without stopping work for anyone else.

Next, the keys move into a secrets manager and the scripts read them from the environment, which ends the copy and paste that caused the leak 2. The repository history still contains the old key, so the team treats that string as permanently burned rather than trying to scrub it.

A scheduled job now calls the free usage endpoint each night and alerts when spend jumps above its normal range 4. Separate keys narrow the damage, but they still draw on the same team balance, so the alert is the control that limits how much a leak can cost.

Analysts who work from an assistant connect through the MCP server and sign in with OAuth, so the raw key never reaches their laptops 3.

API key vs OAuth

Both let a client call an API on behalf of an account. An API key is a long-lived secret tied to that account. OAuth lets a user approve a connection without handing over the key, and that connection can be revoked on its own 3.