Best free APIs for beginners to learn with

Most "APIs for beginners" lists are really lists of famous APIs. Half of them need an OAuth flow before they return a single byte, which means your first hour is spent on authentication rather than on the thing you were trying to learn.

These eight were picked on one criterion: how quickly a person who has never called an API can see a real response.

The shortlist

1. Zippopotam.us — your first request

The whole API is one pattern: country code, then postcode, in the path.

curl -s "https://api.zippopotam.us/gb/SW1A"

{
  "post code": "SW1A",
  "country": "United Kingdom",
  "country abbreviation": "GB",
  "places": [
    { "place name": "Westminster", "longitude": "-0.1382", "latitude": "51.5016" }
  ]
}

Why this first: you can read the URL and predict the response. There is no key to get wrong, no parameter to misspell, and the JSON is shallow enough to see whole. The one wrinkle — spaces in the key names — is a genuinely useful early lesson:

const data = await fetch('https://api.zippopotam.us/gb/SW1A').then((r) => r.json());
console.log(data.places[0]['place name']); // bracket notation, not dot

2. Open-Meteo — query parameters

The natural next step, because now the request has options.

curl -s "https://api.open-meteo.com/v1/forecast\
?latitude=51.5&longitude=-0.13&current=temperature_2m&timezone=auto"

const url = new URL('https://api.open-meteo.com/v1/forecast');
url.search = new URLSearchParams({
  latitude: '51.5',
  longitude: '-0.13',
  current: 'temperature_2m',
  timezone: 'auto',
});
 
const { current } = await fetch(url).then((r) => r.json());
document.body.textContent = `${current.temperature_2m}°C`;

Using URL and URLSearchParams rather than string concatenation is a habit worth forming now. It handles encoding for you, which becomes important the moment a parameter contains a space or an ampersand. See query params vs path params for when to use which.

3. RandomUser — arrays and nested objects

Returns fabricated people, which makes it ideal for practising loops and rendering lists without needing a database.

curl -s "https://randomuser.me/api/?results=3&nat=gb"

const { results } = await fetch('https://randomuser.me/api/?results=5')
  .then((r) => r.json());
 
for (const person of results) {
  console.log(`${person.name.first} ${person.name.last} — ${person.email}`);
}

The nesting (person.name.first rather than person.firstName) is representative of real APIs and teaches you to read a response shape before writing code against it.

4. DummyJSON — the other HTTP methods

Everything above is GET. DummyJSON accepts POST, PUT, PATCH and DELETE, and fakes the write so you can practise safely.

curl -s -X POST "https://dummyjson.com/products/add" \
  -H "Content-Type: application/json" \
  -d '{"title":"A test product","price":9.99}'

const created = await fetch('https://dummyjson.com/products/add', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ title: 'A test product', price: 9.99 }),
}).then((r) => r.json());

Two things to notice here, because both are common beginner failures: the Content-Type header is required, and the body must be a JSON string, not an object. Pass the object directly and you will send [object Object].

5. JokeAPI — filtering and error shapes

Useful because it has a rich query interface and a well-designed error response, so you can practise handling failure deliberately.

curl -s "https://v2.jokeapi.dev/joke/Programming?type=single&safe-mode"
curl -s "https://v2.jokeapi.dev/joke/NotACategory"

The second returns a structured error rather than a crash:

{ "error": true, "code": 106, "message": "No matching joke found" }

Getting into the habit of checking a flag like that, and checking response.ok, early will save you a great deal later. Our post on why fetch does not throw on a 404 explains the trap.

6. SWAPI — following links between resources

Star Wars data, where fields contain URLs to other records. That is a real pattern, and working through it teaches you sequential and parallel fetching.

const person = await fetch('https://swapi.dev/api/people/1/').then((r) => r.json());
const films = await Promise.all(
  person.films.map((url) => fetch(url).then((r) => r.json())),
);
 
console.log(person.name, films.map((f) => f.title));

Promise.all over a list of URLs is the moment most people stop fetching things one at a time in a loop.

A suggested order

1. Zippopotam.us — send a request, read a response.
2. Open-Meteo — add parameters, see them change the result.
3. RandomUser — loop over an array, render a list.
4. DummyJSON — POST, and learn what a request body is.
5. JokeAPI — handle an error on purpose.
6. SWAPI — fetch several things at once.

That is a complete tour of REST without ever touching an API key.

The three errors everyone hits first

Almost every beginner runs into the same three failures in roughly the same order. Recognising them saves hours, because each one looks like a mystery and each has a one-line explanation.

Unexpected token '<' in JSON. You called .json() on a response that was HTML. That happens because fetch does not throw on a 404 or a 500 — it resolves happily, your code carries on, and the parser then chokes on an error page. The URL is usually the real problem. Checking response.ok before touching the body turns a baffling parse error into a clear "404 from this URL", and it is the single most valuable habit to form early. The full explanation is here.

"Blocked by CORS policy." Your request succeeded and the browser refused to give you the response, because the API did not say your page was allowed to read it. Nothing is broken on your side and no amount of changing your code will fix it — the permission has to come from the API. Every API in this list sends the required header, which is why they work from a plain page. When you meet one that does not, the answer is a server in between, not a workaround. More on CORS.

"Failed to fetch." The most unhelpful message in JavaScript, because it covers several unrelated causes: no network, a wrong hostname, a blocked mixed-content request, or a CORS rejection. The Network tab distinguishes them in seconds — a request that never left looks different from one that completed and was withheld. The seven real causes.

What these share is that the error message describes a symptom several layers away from the cause. That is not you missing something obvious; it is a genuine weakness in how browsers report these, and knowing the mapping is most of the skill.

Reading a response before you write code against it

The habit that separates smooth integrations from frustrating ones, and it takes about thirty seconds.

Before writing anything, send the request and look at what comes back. Not the documentation's example — the actual response, with your parameters. You are looking for four things: the field names as they really are, how deeply nested they are, what a missing value looks like, and whether numbers arrive as numbers or as strings.

That last one catches people constantly. Plenty of APIs send "price": "9.99" as a string, deliberately, to avoid floating-point issues. Code that adds those together concatenates them instead, and "9.99" + "5.00" becomes "9.995.00" with no error at all.

Nesting is the other thing worth checking first. person.name.first and person.firstName are both common, and guessing wrong gives you undefined rather than an error, which then propagates somewhere unrelated before anything visibly breaks.

In the browser console, expanding the logged object shows all of this immediately. In a terminal, piping through jq does the same. Either way, thirty seconds spent looking at real output prevents the much longer confusion of debugging code written against an imagined shape.

What to build, and what to avoid building

A suggestion, because choosing a first project badly is the most common reason people stall.

Build something that displays one value that changes. A page showing the current temperature. A random joke with a button to get another. The population of whichever country you type. These are small enough to finish in an evening, and finishing matters far more than scope at this stage.

The trap is jumping to a multi-screen application with accounts, saved favourites and routing. Those are real skills, and none of them teach you anything about APIs — you will spend the whole project on state management and never get past the first fetch. A finished trivial thing teaches more than an abandoned ambitious one.

Once the single value works, the natural progression is roughly: render a list instead of one item, add a search box that changes the request, handle the case where the request fails, then add a second API and combine them. Each step is small, each introduces exactly one new idea, and by the end you have covered most of what an API client ever does.

Where to go next

When you want a key-based API, the gentlest step up is one using a simple header key rather than OAuth. Our guide to API authentication types covers the difference, and the no key required collection lists every keyless API we track if you would rather keep practising without one.