OpenAI API Keys: Create One and Keep It Out of Project Notes
An OpenAI API key authenticates every request you make. Here is how to create one, store it safely, revoke it if something goes wrong, and record the setup decisions your team needs without ever storing the key itself.
Updated 4 min read
An OpenAI API key is the credential that authenticates every request your code or tool sends to OpenAI's models. Creating one takes about a minute. Keeping it safe requires a small set of habits you establish once. Tools like fenbs let you record the non-secret setup decisions your team needs, such as which environment holds the key and what the review rules are, without ever putting the key itself in a note or task.
How to create an OpenAI API key
Log in to your OpenAI account and go to platform.openai.com (opens in a new tab). In the left sidebar, open the API keys section. Click "Create new secret key." Give it a name that describes what it is for: "local-dev," "staging-summarizer," or "n8n-prod." Copy the key immediately because OpenAI shows it only once.
If you miss copying it, the key is not lost: you can create a new one and delete the old one. Deleting a key is always reversible in the sense that you can create a replacement, but any service using the old key will stop working until you update it. Name your keys clearly so you know which service each one belongs to.
Where to store the key safely
The key is a secret. It must never appear in source code, in a shared document, in a task note, or in a chat with an AI assistant. Treat it like a password.
- Local development: store it in a .env file in your project root, load it with a library like python-dotenv or dotenv for Node.js, and add .env to your .gitignore before the first commit.
- Shared environments: use a secrets manager such as AWS Secrets Manager, Azure Key Vault, or a similar service your team already uses. Do not paste the key into environment variable fields visible in a shared dashboard unless access is restricted.
- CI/CD and deployment: use the secrets feature in your build or deployment tool. These are designed to keep values out of logs and out of the build artifact.
- No-code tools: when a tool like Zapier or n8n asks for an API key, it stores it encrypted in its own secrets vault. Do not paste it into a workflow step that logs its inputs.
What to do if a key is exposed
If a key appears in a commit, a log file, a shared note or a chat message, revoke it immediately. Go to the API keys section in the platform and delete it. Then create a new key and update every service that used the old one. Do not wait to see if anyone noticed.
Check your usage dashboard after revoking the key. If you see requests you did not make, report it to OpenAI and check whether any other credentials in the same project or repository may have been exposed. One exposed key is usually a sign of a process that needs fixing, not a one-off accident.
Set spending limits and monitor usage
OpenAI lets you set monthly spending limits in the account settings. Set one before you start building. A bug that sends thousands of requests, or a loop that never terminates, will spend real money in minutes if there is no limit. Start with a low limit and raise it when you understand your actual usage.
The usage dashboard shows requests, tokens and cost by day and by key. Check it when you start a new project and after any significant change to the code. Unexplained spikes usually mean a bug, not normal usage.
Record the setup decisions, not the key
The setup decisions your team needs are not secrets: which environment holds the production key, who can create new keys, what the review trigger is, and what the spending limit is set to. Record those in fenbs as Decisions and rules, with the person who decided and the reason. Every AI assistant you connect reads them. The key itself stays in a secrets manager.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
Using project-level keys and scoped permissions
OpenAI allows organization-level and project-level API keys. A project key is scoped to a specific project and cannot access other projects' resources. Use project keys for production integrations so that a compromised key has a limited blast radius.
If your organization has multiple people creating keys, decide and document who creates them, who can revoke them, and how new team members request access. That process is a decision worth recording, not just an informal understanding. Storing it in a shared record ensures it survives team changes and stays available to everyone who needs it.
How to manage key decisions with fenbs
Keep the process, not the credential, in your shared record. The key belongs in a secrets manager. The decisions about how you use it belong in fenbs.
- Create a free account. You can start with a personal board for a solo project.
- Add a project for your API integration. Include the environment setup in the project description: where the key is stored, which environment uses which key.
- Write the access decisions as Decisions and rules: who can create keys, the spending limit agreed, the review rule for unexpected usage.
- Record any incidents: if a key is rotated because of an exposure, write a lesson so the next person handling this knows what happened and what was changed.
- Connect your AI assistant from Integrations over MCP. It will read your rules before helping with any code that touches the API.