A unique code passed with requests to an API to identify the caller and control access.
Developers or system administrators reading documentation on API security and usage management.
01What it is and how it works
An API key is a long string of letters and numbers generated by a service provider. When your application makes a request to an API, it includes the key in the request header or query string. The server reads the key, looks it up in its database, and checks whether that key has permission to perform the requested action. Keys can be scoped to limit which endpoints are reachable and how many requests are allowed per minute. They are tied to a billing account or project, so usage is attributed to the right owner. Keys are not encrypted by default, so they must be sent over HTTPS to avoid interception. They do not prove the identity of an end user; they prove the identity of the calling application.
An API key is like a password for apps. You include it in your request, and the server checks it to decide if you are allowed to use the API.
02What to do about it
This week, generate a new API key from your provider's dashboard and store it in a secrets manager or environment variable, never in source code. Rotate any keys that have been committed to a public repository. Set up usage alerts so you are notified if request volume spikes unexpectedly. Review which IP addresses or domains are allowed to use each key and restrict them where possible. Document which team members have access to which keys and remove access for people who no longer need it.
03How it is measured or noticed
You know an API key is working when requests return successful responses instead of 401 or 403 errors. In your provider's dashboard, you can see request counts, error rates, and latency grouped by key. Logs will show the key string in request headers if you inspect them. If a key is revoked or expired, the API responds with an authentication error. Usage quotas are typically displayed per key in the billing or usage section of the dashboard.
04Common mistakes
- Hardcoding API keys directly in source code or configuration files that get committed to version control
- Using the same key across multiple environments (development, staging, production) instead of generating separate keys
- Leaving keys unrestricted so any IP address or domain can use them
- Not rotating keys regularly or after suspected exposure
- Storing keys in plain text files on shared servers or sending them over unencrypted HTTP connections
05Limits
API keys are not a substitute for user authentication. They identify the calling application, not the individual user behind it. They do not provide fine-grained access control on their own; for that you need OAuth tokens or session-based authentication. API keys only work with services that explicitly require them. Some APIs use OAuth, JWT tokens, or mutual TLS instead, and an API key will not work there. If a service does not expose an API, there is no key to manage.
06Worked example
A marketing team uses OpenAI's API to summarize customer reviews. They create a key in the OpenAI dashboard, assign it to their 'review-analysis' project, and set a monthly spending limit of $500. Their script reads the key from an environment variable called OPENAI_API_KEY and includes it in the Authorization header of each request. When the script runs, the API returns summaries. If the key is deleted or the limit is exceeded, the API returns an error and the team gets an email alert.
Frequently asked questions
Is an API key the same as a password?
No. An API key identifies a program or service calling an API, while a password identifies a human logging into an account. API keys usually have broader, more permanent permissions and are not designed to be memorised or typed by a person.
When should I use an API key instead of OAuth or tokens?
Use an API key for simple server-to-server calls where you just need to identify the calling project, especially when the provider documents a key-based flow. Use OAuth or short-lived access tokens when you need to act on behalf of a specific user, scope permissions, or let users revoke access without rotating the whole project credential.
Where do API keys come from and who issues them?
They are generated by the service you want to call, from that provider's developer console or dashboard. The provider ties the key to a project or account, and it is your responsibility to create, copy and store it the first time, because most dashboards only show the full value once.
Why is my request returning a 401 or 403 even though I sent the key?
A 401 usually means the key is missing, wrong, or revoked, while a 403 means the key is valid but is not allowed to do that action, often because of IP restrictions, referrer checks, or an insufficient plan. Check that the key is loaded from your secrets manager, sent in the header the docs specify, and not hitting a rate or quota limit.
What happens if I commit an API key to source control?
Anyone who finds the repository can use the key as you, which can lead to quota theft, unexpected bills, or your key being revoked by the provider. Rotate the key immediately in the provider's dashboard, delete it from the git history, and move future keys into environment variables or a secrets manager.
Do API keys expire?
Some providers issue keys that never expire, while others require periodic rotation or auto-expire after a set period. Treat every key as long-lived by default and build rotation into your workflow so that revoking one does not break production.
Asked out loud
spoken, not typedThe same term in the words somebody uses speaking to an assistant rather than typing into a box — written from the situation, which is why each one carries the situation it came from.
Yes, but you still have to rotate the key. Revoke it in your provider's dashboard right now, replace it in your environment variables or secrets manager, and then purge it from git history with a tool like git filter-repo before force pushing. After that, push the cleaned history and tell your team to re-clone so nobody keeps the old key on their machine.
Check four things in order: the key is the one from the right project, the header name matches the provider's docs exactly, you are hitting the base URL for the environment that key belongs to, and you have not hit the rate limit. If all four look fine, regenerate the key once and test with a fresh curl before changing any application code.
No, generate a separate key for them with the smallest scope the provider allows, and set an expiry or a calendar reminder to delete it when the work ends. Sharing your main key ties their usage to your billing and makes revocation a much bigger incident if it leaks.