2. Understanding API keys

An API key is a long random string that identifies your application to a service. It's not a password protecting your account; it's a membership card saying "this request is coming from application X, owned by developer Y." That distinction matters: passwords you guard because they unlock things; keys you guard because they bill things.

Understanding what keys are, and aren't, helps you handle them correctly. They're not secret encryption keys. They're not user passwords. They're application identifiers that grant specific permissions and carry specific usage limits.

What an API key actually does

When you include a key in a request, the service runs through four checks before it decides whether to answer:

  • Identification. The service looks the key up in its database. That lookup connects your request to your account: subscription tier, usage history, permissions, billing details. The key itself doesn't contain any of that; it's a reference, like a membership number.
  • Authorization. Once the service knows who you are, it checks what you're allowed to do. A read-only key might work for GET but fail for POST. A development key might have stricter rate limits than a production one. Permission is checked per-operation, not per-account.
  • Usage tracking. Your request is counted against your quota. Free-tier 1,000-per-month plans increment a monthly counter. Paid tiers track by minute, by hour, by day, or by dollar value. This is how billing and abuse prevention work.
  • Rate limiting. The service checks how fast you've been calling recently. Most APIs enforce a ceiling like "60 per minute" or "1,000 per hour." Within the ceiling, the request proceeds. Over it, you get a 429 Too Many Requests instead of your data.

Keys are long, random, and case-sensitive. The randomness isn't cosmetic: sequential keys (key-0001, key-0002) would be trivially guessable, so real services use 32, 64, or 128 characters of cryptographic noise. Some services prefix their keys, sk_test_abc123 or pk_live_xyz789, to tag the key's type or environment at a glance. Stripe's sk_live_ prefix, for instance, is a constant reminder that this one bills real cards.

How keys travel with requests

A key has to ride along with your HTTP request, but there's no single convention for where it rides. The API's documentation will specify, and most services pick one of three patterns:

Three ways to send an API key
Method How it works Common use cases Security level
Query parameter Appended to the URL after ? Simple APIs, weather services, mapping APIs Lower (visible in browser history, server logs)
Request header Sent in HTTP headers, separate from the URL Professional APIs, REST services, modern default Higher (not logged in standard web server logs)
URL path segment Embedded in the endpoint URL itself Some legacy systems, specialised APIs Lower (visible in every request log)

How do you know which one a given service uses? The documentation. Look for sections titled "Authentication", "Getting Started", or "API Keys", and you'll usually find a curl example showing exactly where the key goes. When in doubt, copy the curl command from the docs, run it from your terminal, and only translate to Python once it answers.

In this chapter, we'll use OpenWeatherMap as our worked example. It uses query-parameter authentication, the simplest and most common form, but the credential-management patterns you'll learn apply equally to header-based and path-based keys. The mechanics of where the key goes vary; the discipline around keeping it secret doesn't.

Getting your first API key

Time to get a real key in your hands. We'll use OpenWeatherMap because it offers a genuinely free tier with no credit card and has clear documentation. The registration flow is typical of most services you'll encounter later.

  • Create an account. Visit openweathermap.org and click "Sign Up". You'll need a valid email address. The service sends a verification email, check your spam folder if it doesn't arrive within a few minutes. Verification proves you're a real person and gives the service a way to reach you about usage.
  • Generate your key. After verifying, head to your account dashboard and find the "API Keys" section. Many services provide a default key automatically; others ask you to click "Generate New Key". Give it a descriptive name like learning-project or weather-dashboard, future-you will thank present-you when there are ten keys in the list.
  • Wait for activation. A new OpenWeatherMap key can take anywhere from a few minutes to a couple of hours to activate while the service provisions it across its systems. If you try the key and get 401, don't panic: that almost always means the key is still activating, not that you mistyped it. Give it time and retry later. Activation delays are common and aren't a sign you did anything wrong.
  • Test the key. Before writing Python, confirm the key works with a browser request or curl. OpenWeatherMap's docs include sample URLs, paste your key in, and see if it returns JSON. If it still fails after a couple of hours, re-check you copied the key correctly: keys are case-sensitive and easy to mistype.

Once the key works, pause before you go further. Where you put it in the next sixty seconds sets the pattern for the rest of the chapter, and the rest of your career. Paste it into a password manager (1Password, Bitwarden, your OS keychain, any of them). Don't leave it in your downloads folder. Don't save it in a file called keys.txt on the desktop. Don't email it to yourself. Treat it like a credit-card number: you wouldn't write one on a sticky note, and you wouldn't save it in a plain-text file called credit-cards.txt, so don't do either with keys.

You now have a working key, stored somewhere safe. The next section walks through the tempting but dangerous shortcut almost every developer tries first, pasting the key straight into the code, so you can see exactly how that pattern breaks before we show you the professional alternative.