How to connect an API to your project — 5 steps, and where it usually breaks

Most beginners think "connecting an API" is something for real programmers. In fact it's five short steps, and almost all the pain lives in two of them: the key and the headers. Let's go in order, on a real example — we'll connect a free weather API. If you'd rather grasp the idea first, here's what an API is in plain words.

Step 1: find the docs and the endpoint

Every API starts with its docs — the page where the service explains what you can ask for. Look for an "API" or "Docs" section on the service's site. You need two things:

• The endpoint — the address to send the request to. E.g. https://api.weather.com/v1/now.
• The parameters — what you can specify. E.g. ?city=London (city) and &units=metric (Celsius).

Open the docs and find an example request — it's usually right there. That's your starting point: don't invent the address, copy it from the docs.

Step 2: get an access key

Almost every API is locked behind a key — your personal pass. Sign up on the service's site, find the "API Keys" section, and create a key. It looks like a long string such as a3f9c2e1b8....

Copy it and for now just put it somewhere safe — don't hardcode it into your code (why — in step 5). Many services give a free tier: say, a thousand requests a day. For a side project that's plenty.

Step 3: make your first request by hand

Before writing code, check it works straight from the terminal with curl:

curl "https://api.weather.com/v1/now?city=London" -H "Authorization: Bearer YOUR_KEY"

What's here:

• the address with the parameters from step 1;
• the -H flag adds the Authorization header — that's how you present the key. This is exactly where beginners trip most: each API's header format is its own, so check the docs for the exact wording.

If a JSON with weather comes back — victory, you're connected. If it's an error — read it, it usually tells you plainly what's wrong (most often a bad key or header).

Step 4: parse the response in code

Now the same thing from code. In JavaScript it's literally a few lines:

const res = await fetch("https://api.weather.com/v1/now?city=London", {
  headers: { Authorization: "Bearer " + key }
});
const data = await res.json();
console.log(data.temp);   // 17

fetch sends the request, res.json() turns the answer into a plain object, then you pull the field you need — e.g. data.temp. Peek at the response shape in the docs or in what curl returned in step 3. An AI agent will happily write this code for you today — but now you understand every line.

Step 5: hide the key

The most important step, and the one most often skipped. You must not leave a key sitting in your code, especially if you push the project to GitHub — bots scan repos and steal keys within minutes. Solve it like this:

• move the key into an environment variable — a separate .env file that never enters the repo;
• in your code read it from there (process.env.WEATHER_KEY) instead of writing it as a string.

That's security basics — more in the guide on storing keys safely.

What you end up with

After these five steps your project has real, live data — weather, rates, maps, an answer from an AI. And crucially: you've learned a universal pattern. The next API connects exactly the same way — only the address and the response shape change. That's the skill that turns "I want an app" into "here it is, working."

FAQ: why does my request return a 401 error?

401 means "no entry, you didn't identify yourself." It's almost always the key: it's missing from the header, it was copied with a stray space, or the header format isn't what the API requires. Go back to step 3 and check the Authorization header against the docs word for word.

FAQ: do I need a server to call an API?

For most public APIs — no, you can send the request straight from your app's code. But if the API requires a secret key, it's safer to call it from a server, not the browser: otherwise the key is visible to anyone who opens your site. Not critical for first practice projects, but remember it for later.