AI API Keys: Get One, Use It, and Keep It Private

An AI API key is a secret credential that authenticates your code with a model provider such as Anthropic, Google, or OpenAI. You include the key in each request, and the provider uses it to identify your account and track usage. Tools like fenbs let you record the non-secret project decisions around that key, such as which model a team agreed to use and why, so everyone stays consistent without passing secrets around.

Getting a key is usually a few clicks. Keeping it safe and keeping the project setup documented takes more deliberate effort. This guide covers both.

What an AI API key does

When your code calls a model API, it sends the key in an authorization header. The provider checks the key, finds your account, and records the usage against your billing plan. The key itself has no permissions beyond what your plan allows. It does not restrict which endpoints you call or which models you use, unless you set additional restrictions in the provider console.

A key can be scoped or rotated. Some providers let you create multiple keys, set per-key spending limits, or restrict a key to specific IP addresses. Check the provider's documentation for what is available on your plan. For API documentation in general, see the api-documentation guide.

How usage billing works

Most AI APIs charge per token, where a token is roughly three to four characters of text. Each request sends input tokens and receives output tokens, and both count toward your bill. Some providers offer a free tier with a monthly allowance before charges begin.

Set a spending limit as soon as you create a key. Most consoles let you configure a monthly cap that disables the key after it is reached. Without a cap, a loop or a mistake in your code can send thousands of requests before you notice. Check the provider's billing settings page to confirm how limits and notifications work for your account.

Where a key must not live

Never commit a key to a code repository, paste it into a shared document, or put it in a chat message. Even a private repository can be forked, archived, or accidentally made public. Exposed keys are found and misused quickly.

• Store keys in environment variables: a .env file that is listed in .gitignore, or a secrets manager such as those offered by AWS, Azure, or your deployment platform.
• In CI and deployment pipelines, inject keys as encrypted environment variables, not as plain text in config files.
• Never log the value of a key, even in development. Logs travel further than you expect.
• Rotate keys after any suspected exposure. Most providers let you revoke a key and create a replacement in the console.

What to record outside the key

The key is secret, but many decisions around it are not. Which provider and model did the team agree to use? Why did you choose that model over another? What are the approved use cases for this key? Are there restrictions on what the code may send, such as avoiding personal data?

These decisions should live somewhere a teammate or a connected AI assistant can read. A decision written only in a chat thread is lost when the thread is closed or archived. Recording it in a shared project record means the next developer, and the next AI assistant that works on the project, starts with the approved setup.

Common setup mistakes

Most key-related problems come from one of three sources: the key is in the wrong place, the model choice was not communicated, or nobody set a spending cap. A fourth problem is less obvious: the project grows and the original setup decisions are forgotten. A new developer picks a different model because the approved one was not recorded.

A fifth problem happens at handoffs. When a developer leaves a project, the key they used may be stored somewhere only they knew about. Adopt a policy early: all keys go through a shared secrets manager, not a personal password vault or a local dotenv file that only one person has.

For more on provider-specific key setup, see the Claude API key guide and the Codex API key guide.

Keeping multiple keys organized across projects

When a team has several AI integrations, key management becomes a small project on its own. Each key has an owner, a rotation schedule, and a set of projects that depend on it. Without a record, a key gets rotated and two integrations break because nobody knew they shared it.

A simple inventory: for each key, record which provider it is with, which projects use it, who is the primary owner, and the last rotation date. That inventory does not need to contain the key itself, only metadata about it. Review the inventory when a team member leaves or a project ends.

How to set this up with fenbs

1. Create a free account. Start a personal project for the integration work.
2. Add a task for the API setup. Write what the integration needs to do and which provider you are using.
3. Open Decisions and rules and record the key choices: provider, model, approved use cases, and any restrictions on data the API may receive.
4. If you are rotating a key or troubleshooting a billing issue, add it as a task with notes on what was tried and what the outcome was.
5. Connect your AI assistant over MCP from Integrations. It will read the project rules before working, so it knows which model is approved and what limits apply.