What an API key is, and why it is a password

When you make an image in Google AI Studio, as the first module's exercises do, you are signed in to a Google account and a person is sitting at the screen. An API is the same service offered to programs, and a program cannot sign in or tick a box, so the service gives you a long string of characters to send with every request instead. Google calls it an API key. Hugging Face calls it an access token and Replicate calls it an API token, but they are one idea with three names.

An API lets a program ask for work without anybody clicking, so a short script can request forty variations of a product shot overnight, render a storyboard frame by frame, or hand the whole job to a coding agent while you do something else. A request is a small bundle of text that holds the model's name, your prompt, a few settings such as the length or the aspect ratio, and the key. The later parts of this course all work this way, including calling Veo directly, running open models from Hugging Face and briefing Claude Code or Codex to batch a film. Each of those calls has to prove which account it belongs to. The key is that proof.

Each request carries the key in a header, a labelled line of text that travels with the request but is not part of the prompt. Google's is called x-goog-api-key, OpenAI and Replicate use Authorization with the word Bearer in front, and fal uses Authorization with the word Key. The service reads the string, finds the project it belongs to, checks what that key is allowed to do, runs the job and adds the cost to that project's bill. The request never says who typed it.

Every key is tied to a bill. Google says every Gemini API key is associated with a Google Cloud project, and that project holds the billing, the collaborators and the permissions; other providers attach keys to an account, a team or a project in much the same way. Many keys can also be narrowed. Google lets you restrict a key to the Gemini API alone and to particular websites, apps or IP addresses, Hugging Face offers read, write and fine-grained tokens, the last limited to specific models or organisations, and OpenAI recommends giving every project key an expiry date. A narrow key does less damage when it escapes, which is why a careful studio makes the narrowest key the job allows.

Every official library looks for its key under a fixed name, held in an environment variable, which is a named value your terminal hands to every program it starts. Spell the names exactly. The Google GenAI SDK reads GEMINI_API_KEY, OpenAI's reads OPENAI_API_KEY, Hugging Face's reads HF_TOKEN, Replicate's reads REPLICATE_API_TOKEN and fal's reads FAL_KEY. Google's SDK also reads GOOGLE_API_KEY, and if both are set that one wins, which can make a brand-new key seem to be ignored. That is why no code in this course ever contains a key, only a name, and the value itself lives in a file or a vault on your own machine, which a later lesson in this module sets up.

Some providers show you a key only once. fal says its keys cannot be retrieved after they are created, so a new key has to go straight into safe storage, and the habit is a good one everywhere. A careful studio treats each key as a small asset with a record kept beside it, noting what the key is for, which project pays, where it is stored, when it expires and who can see it. That record takes two minutes to write. It is also what makes a leak quick to deal with, because you know exactly which key to switch off and what will stop working when you do.