Skip to content

Glossary

API key

An API key is a secret string that identifies your account to a service, and because holding it is the whole of the proof, anyone who obtains a copy can use it exactly as you would.

In plain terms

A long secret string a service gives you so it knows the requests are yours. It works like a key rather than like a password, because nothing checks who is holding it: whoever has a copy can open the same door and the bill arrives with you. That is why it turns up in so many accidents, and why replacing it is the only fix that actually works.

01

Why it matters

Because it is usually the first real credential a non-engineer handles, and it behaves unlike the passwords they are used to. There is no second factor, no login screen and no prompt when it is used from somewhere new, so all the safety habits people already have simply do not apply. What replaces them has to be deliberate.

02

How it works

It proves possession rather than identity, which is the property everything else follows from. The service checks that the string is valid and does not ask who sent it or from where, so a copy is not a clue that something is wrong but a fully working credential. Anything that can read the string has the access it carries.

Scope and limits are set when the key is created, and this is where most of the available safety lives. Many services allow a key restricted to certain operations, certain resources or a spending ceiling, so a key that can only read one thing is a much smaller problem than one that can do everything the account can. Creating narrow keys per use is unglamorous and disproportionately effective.

Leaks happen through ordinary carelessness rather than attacks. Keys end up committed to repositories, pasted into chats, embedded in something that ships to a browser, or sitting in a screenshot in a support ticket, and each of those is a normal working action that nobody thought of as handling a credential. The pattern is people being helpful, not people being careless.

Rotation is the only genuine remedy, and it works because keys are designed to be replaceable. Revoking the old string and issuing a new one ends the exposure immediately, which is why services let you hold several at once and why keys should be treated as things that get replaced rather than things that get protected forever. Planning the replacement before you need it is what makes it a ten-minute job.

Usage is attributed to the key rather than to a person, which matters for both bills and investigations. Everything done with it looks identical in the record, so a shared key makes it impossible to say who did what, and one key per system or per person turns an unanswerable question into a lookup. That is worth more the moment anything goes wrong.

Why the habits you already have do not transfer

Why the habits you already have do not transferWhat makes this a genuine trap rather than an obvious one is that the people handling keys most often are the ones furthest from that machinery. An engineer meets keys in a context that already has secret storage, review and rotation practices around it. A marketer wiring an assistant into a spreadsheet, or an operations lead connecting two systems on a Friday afternoon, meets exactly the same credential with none of that, and reasonably applies the mental model they have, which is the one they use for passwords. That model says a secret is something you keep and change if something goes wrong, and it is wrong here in both halves: the string cannot be kept once it has been pasted anywhere, and changing it after something goes wrong is the only step that ever helps. The two habits worth teaching before anything else are narrow keys per use and knowing where the revoke button is, because the first bounds the damage and the second ends it.A passwordA second factor usually guardsit.A login screen notices a newplace.You are told about oddsign-ins.Changing it is routine.A keyHolding it is the whole of theproof.Nothing notices where it camefrom.Use is silent by design.Replacing it needs a plan youmade earlier.Everything protecting a passwordis machinery around it ratherthan the password itself, andnone of that machinery comeswith a key. The habits have tobe built deliberately instead.
What makes this a genuine trap rather than an obvious one is that the people handling keys most often are the ones furthest from that machinery. An engineer meets keys in a context that already has secret storage, review and rotation practices around it. A marketer wiring an assistant into a spreadsheet, or an operations lead connecting two systems on a Friday afternoon, meets exactly the same credential with none of that, and reasonably applies the mental model they have, which is the one they use for passwords. That model says a secret is something you keep and change if something goes wrong, and it is wrong here in both halves: the string cannot be kept once it has been pasted anywhere, and changing it after something goes wrong is the only step that ever helps. The two habits worth teaching before anything else are narrow keys per use and knowing where the revoke button is, because the first bounds the damage and the second ends it.
03

Seen in the wild

  • A routing service where a single key reaches many providers at once, so one string carries far more reach than it appears to.

    OpenRouter

  • An agent platform inviting you to bring your own provider keys, which keeps spending visible to you as the work scales up.

    Relevance AI

  • A self-hosted automation platform where the keys for every connected service sit in an installation you operate yourself.

    n8n
04

Common misconceptions

People assume

It is basically a password.

In fact

It behaves like a physical key instead, and the difference matters in practice. A password is usually defended by a second factor and a login screen that notices an unfamiliar location, while a key carries no such machinery, so a copy is immediately and silently usable by whoever holds it.

People assume

A leaked key can be secured once you notice.

In fact

It can only be replaced, and the exposure runs from the leak to the revocation rather than to the discovery. Nothing about the old string can be made safe again, which is why the useful preparation is knowing how to rotate quickly rather than hoping to keep it hidden.

People assume

One key for the team is simpler.

In fact

It is simpler right up to the moment you need to answer a question about it. A shared key makes every action look the same in the record, so who ran the expensive job and which system caused the spike become unanswerable, and revoking it to contain one problem breaks everybody at once.

05

Telling them apart

API key vs Connector

API key

The credential that proves the request is yours.

Connector

The prebuilt link that saves you writing the plumbing.

One is what you hold and the other is what somebody built for you, and a connector usually asks for a key to work at all.

06

Questions

What do I do if one leaks?
Revoke it and issue a new one, in that order, before working out how it happened. The exposure lasts until revocation rather than until discovery, so speed matters more than diagnosis, and services support holding several keys precisely so a replacement can be in place before the old one dies. The post-mortem is worth doing afterwards.
How should we store them?
In whatever secret store your organisation already uses, and specifically not in a repository, a spreadsheet or a chat message. The ordinary hazards are helpfulness rather than malice, which is why the storage decision matters less than establishing that pasting a key to unblock a colleague is never the right move.
Should each person or system have its own?
Yes, and the reason is attribution rather than security theatre. Separate keys let you see which system caused a cost spike, revoke one without breaking everything else, and answer questions about who did what. A shared key converts all three of those into guesswork at exactly the moment they matter.
Can I limit what one can do?
Frequently, and it is the most under-used control available. Many services offer keys restricted to particular operations or resources, and several allow a spending ceiling as well, which turns a worst case from unlimited into bounded. Creating a narrow key per use takes a minute and is the cheapest protection on this page.
07

Key takeaways

  • It proves possession, not identity, so a copy is a working credential.
  • Narrow scope and a spending ceiling are the cheapest protection available.
  • Leaks come from ordinary helpfulness, not from attacks.
  • Rotation is the only real remedy, and preparation makes it a small job.
  • One key per person or system turns an unanswerable question into a lookup.
08

Related terms

09

Tools that use this

  • OpenRouter

    One key reaching many providers, so one string carries wide reach.

  • Relevance AI

    Bring your own provider keys, keeping spend visible as agents scale.

  • n8n

    Keys for every connected service held in an installation you operate.

Last checked July 2026

All glossary terms