Skip to content
Fox photography representing the Public APIs section

Public APIs

Free JSON APIs

JSON endpoints you can call immediately - some with fake data for prototyping, some with real data worth building a project around.

  • 5 endpoints
  • No key needed
  • Prototype friendly

The APIs covered on this page

These are community and public services with no formal uptime commitment. They are excellent for learning and prototypes, and should not be treated as production dependencies without your own caching layer.

JSONPlaceholder

Documentation

The standard fake REST API: posts, comments, users, todos, albums, photos.

Authentication
None
Pricing
Free
Endpoint
GET /users/1/posts

Example request

curl "https://jsonplaceholder.typicode.com/users/1/posts"

Example response

[
  { "userId": 1, "id": 1, "title": "sunt aut facere", "body": "quia et suscipit..." },
  { "userId": 1, "id": 2, "title": "qui est esse", "body": "est rerum tempore..." }
]

Good for

  • Practising fetch, async/await and error handling
  • Building list and detail views before a backend exists
  • Teaching REST conventions

Limitations

  • POST, PUT and DELETE are simulated and never persist
  • Lorem ipsum content only
  • No authentication flows to practise

DummyJSON

Documentation

Richer fake data - products, carts, recipes, users - with pagination and search.

Authentication
None for read endpoints; a mock auth flow is available
Pricing
Free
Endpoint
GET /products/search

Example request

curl "https://dummyjson.com/products/search?q=laptop&limit=2"

Example response

{
  "products": [
    { "id": 6, "title": "MacBook Pro", "price": 1749, "rating": 4.57, "stock": 83 }
  ],
  "total": 1,
  "skip": 0,
  "limit": 2
}

Good for

  • Ecommerce interface prototypes
  • Practising pagination, sorting and filtering
  • Mock login flows for tutorials

Limitations

  • Data is invented
  • Write operations are simulated
  • Shared public service, so be considerate with request volume

REST Countries

Documentation

Real country data suitable for portfolio projects.

Authentication
None
Pricing
Free
Endpoint
GET /region/{region}

Example request

curl "https://restcountries.com/v3.1/region/asia?fields=name,population,flags"

Example response

[
  { "name": { "common": "Japan" }, "population": 125836021, "flags": { "svg": "https://flagcdn.com/jp.svg" } }
]

Good for

  • The classic countries portfolio project
  • Country and currency pickers
  • Data visualisation practice

Limitations

  • Large payloads without the fields parameter
  • Community maintained
  • Population figures are point-in-time estimates

Large, deeply linked dataset that is genuinely fun to build against.

Authentication
None
Pricing
Free, caching explicitly requested
Endpoint
GET /pokemon/{name}

Example request

curl "https://pokeapi.co/api/v2/pokemon/ditto"

Example response

{
  "id": 132,
  "name": "ditto",
  "height": 3,
  "weight": 40,
  "types": [{ "slot": 1, "type": { "name": "normal" } }]
}

Good for

  • Practising nested resource fetching
  • Search, filter and detail-page patterns
  • Learning to cache aggressively

Limitations

  • Heavily nested - many follow-up requests needed
  • Fair-use policy asks you to cache locally
  • Read-only

Open Library

Documentation

Real book, author and cover data from the Internet Archive.

Authentication
None for read endpoints
Pricing
Free
Endpoint
GET /isbn/{isbn}.json

Example request

curl "https://openlibrary.org/isbn/9780132350884.json"

Example response

{
  "title": "Clean Code",
  "number_of_pages": 431,
  "publish_date": "2008",
  "publishers": ["Prentice Hall"]
}

Good for

  • Reading list and library apps
  • ISBN scanner projects
  • Book cover lookups

Limitations

  • Record completeness varies by edition
  • Rate limited for bulk use
  • Some fields are missing on older records

Fake data, real data, and when to use each

Both kinds of endpoint earn their place. Fake data lets you build an interface before anything else exists. Real data makes a portfolio project worth looking at. Using the wrong one at the wrong time wastes a weekend.

When fake data is the right choice

If you are learning how to fetch, how to handle loading and error states, or how to structure components, fake data removes every variable that is not the thing you are practising. The shape is predictable, the response is fast, and nothing breaks because a real record turned out to be missing a field. It is also the right choice when you are building the front end of an application whose backend is not ready - agree the response shape with whoever is building it, mock that shape, and both sides can work in parallel.

When real data is worth the extra friction

Portfolio projects built on lorem ipsum look like tutorials, because they are. Real data forces you to handle the messy cases that make a project interesting: missing fields, unexpected nulls, inconsistent capitalisation, entries that break your layout because the name is forty characters long. Those are exactly the problems a reviewer is looking for evidence that you can handle.

What to practise with these endpoints

  1. 1Loading and error states. Throttle your network in dev tools and make sure the interface is usable at 3G speeds.
  2. 2Pagination. DummyJSON supports skip and limit; implement both page-number and infinite-scroll versions.
  3. 3Search with debouncing. Fire a request on every keystroke once, watch the request count, then add a debounce and watch it drop.
  4. 4Caching. Store results so that going back to a list does not refetch it. PokéAPI explicitly asks you to do this.
  5. 5Nested requests. Fetch a resource, then its related resources, without creating a waterfall that takes four seconds.

Being a good citizen of a free service

These endpoints are run by volunteers or as public goods, and a single misbehaving script can degrade them for everyone. Do not put a fetch call inside a render loop. Do not hammer an endpoint in a development hot-reload cycle without caching. If you need a large dataset, check whether a bulk download exists - most of these projects publish one, and it is faster for you as well as kinder to them.

None of these services offer an uptime guarantee. That is fine for learning and unacceptable for anything with users, so if a project graduates into something real, put your own cache or database in front of it.

Reading a JSON response properly

Before writing any parsing code, call the endpoint in a browser tab or with curl and look at the actual shape. Is the payload an array or an object with an array inside it? Is pagination reported as a total count, a next URL, or a cursor? Are nulls used for missing values or are the keys simply absent? Ten minutes reading a real response prevents a class of bug that only appears on the second page of results.

Related resources

The general evaluation checklist lives in Public APIs for Developers. For projects that need pictures rather than records, see Free Image APIs, and if you are building the server side of an API yourself, the Backend Developer Roadmap covers the design decisions involved.

Frequently asked questions

What is the best free API for practising fetch?

JSONPlaceholder for the basics, because the shape is predictable and the endpoints are stable. Move to DummyJSON when you want pagination and search, and to a real dataset once the mechanics are comfortable.

Can I use these APIs in a production app?

Not directly. They have no uptime commitments and fair-use limits. If a project becomes real, cache the data in your own database and serve it from there.

Keep going

Related resources

Hand-picked pages that pair well with this one.

Public APIs

Public APIs for Developers

Where to find public APIs, how to judge one before you build on it, and five reliable starting points.

Open

Public APIs

Free Image APIs

Photo and placeholder image APIs, with the licensing and attribution rules that come attached.

Open

Roadmaps

React Developer Roadmap

Learn React in the order that prevents the classic mistakes: state design, effects, data fetching, then frameworks.

Open