The concept, in one paragraph
Imagine a service that anyone on the internet can call. It needs some way to tell one caller from another — to know whose account to charge, whose rate limit to count against, and whose permissions apply. An API key is the simplest possible answer: a long random string the service gives you, which you attach to every request. The service looks it up, finds your account, and proceeds.
That is the entire idea. Everything else on this page is consequences of that simplicity.
What one looks like, and where it goes
Keys are usually long, random, and prefixed so you can recognise the service at a glance — OpenAI keys begin sk-, and most providers use a similar convention. You attach it to a request in one of three places:
| Placement | Looks like | Notes |
|---|---|---|
| Authorization header | Authorization: Bearer YOUR_KEY | The modern default; used by OpenAI, Anthropic and most AI APIs |
| Custom header | x-api-key: YOUR_KEY | Common on older and self-hosted services |
| Query string | ?api_key=YOUR_KEY | Convenient and the worst option — keys end up in server logs and browser history |
If a service offers a header and a query parameter, use the header. Query strings get logged by every proxy, load balancer and analytics tool between you and the destination.
API key vs password vs token — the difference that matters
These three get used interchangeably in tutorials, and they are not the same thing:
| Identifies | Expires | Used by | |
|---|---|---|---|
| Password | A human | Rarely, by policy | A person logging in |
| API key | An application or account | Usually never, until you revoke it | Code calling a service |
| Access token (OAuth) | A user, via an app they authorised | Yes — minutes or hours | Apps acting on someone's behalf |
The practical implication: because an API key normally does not expire and identifies an account rather than a person, a leaked key is usable by anyone who finds it, indefinitely, until you notice and revoke it. Tokens limit the damage window by design; keys do not.
How to get one — the AI APIs specifically
The flow is nearly identical everywhere: create an account, open the developer or API section, click to create a key, and copy it immediately — most providers show the full value exactly once and only store a hash afterwards. If you lose it, you create a new one; nobody can recover the original.
- OpenAI — keys in the platform dashboard, prefixed
sk-, billed per token against your account. - Google Gemini — keys from AI Studio, with a genuinely usable free tier, which is why access rather than payment is the main obstacle for many developers.
- Anthropic Claude — keys from the console; see our Claude API guide.
- DeepSeek — keys from its own platform at commodity per-token prices, covered on the DeepSeek page.
One thing worth knowing before you start: several of these providers gate account creation and API calls by region, not by payment. If signup fails from where you are, the key is not the problem — the origin of your connection is.
The five security rules that actually matter
- Never put a key in frontend code. Anything in a browser or a mobile app can be read by the user, no matter how it is minified or obfuscated. If your web page calls an AI API directly, your key is public — route the call through your own backend instead.
- Never commit a key to git. Automated scanners crawl public repositories constantly and abuse found keys within minutes. Use environment variables and a
.gitignored config file. - Set spending limits. Every serious provider offers a hard monthly cap. This is the difference between a leaked key costing you twenty dollars and costing you thousands.
- Use one key per application. When something goes wrong you want to revoke one thing, not everything you own.
- Rotate on suspicion, not on certainty. Creating a new key takes seconds; keys are cheap and unbounded liability is not.
What to do if a key leaks
In order, immediately: revoke the key in the provider dashboard — this kills it instantly and nothing else you do matters until it is done. Then create a replacement and deploy it. Then check your usage and billing history for calls you did not make, and if there is unexpected spend, contact the provider before paying, since most will discuss abuse charges. Finally, find how it escaped: a public repository, a client-side bundle, a log file, or a screenshot in a support ticket are the four usual answers.
Do not attempt to “delete” a key from git history and consider it handled. If it was ever pushed to a public remote, treat it as compromised permanently — the scanners were faster than you.
A note on relays and shared keys
Because keys are simply strings, a whole industry exists around reselling access to somebody else's: relay services that hand you an endpoint and a key of their own, charging a markup on tokens. It is convenient and the trade is real — you are giving an unidentified operator every prompt you send, depending on them to add new models, and holding a balance that dies with their business. That is not theoretical; it is what happened to the service this domain used to be.
The alternative is your own account and your own key, with a clean IP handling the region question. Slightly more setup, and nobody else holds the string that identifies you.