How to use this public APIs list
Pick one API and one skill. Write three cases: the happy path, one edge case, and one case where you expect a failure and assert that the failure is shaped correctly. That third one is the one most people skip and the one that separates a suite that catches bugs from a suite that confirms the service is online.
A note before you start. These are shared services run by volunteers or by companies as a courtesy. Keep your volume low, do not point a load generator at them, and cache responses where you can.
For learning request and response basics
JSONPlaceholder. A fake REST API with posts, comments, users and todos. Accepts writes and pretends to persist them. Practice: CRUD verbs, status codes, and the difference between a request that succeeded and a change that persisted. The fact that writes are not really saved makes it an unusually good lesson in asserting on outcomes rather than on responses.
HTTPBin. An endpoint that echoes back whatever you send, plus routes that return any status code you ask for, delay on purpose, or return malformed payloads. Practice: timeouts, retries, redirect handling, and header behavior. If you want to see how your suite reacts to a 503, you can produce one on demand.
REST Countries. Country data with a stable, well documented shape and no key required. Practice: schema assertions and field-level validation on a payload that is large enough to be interesting but small enough to read.
For pagination and large collections
PokéAPI
A large, deeply linked dataset with standard offset and limit pagination.
Practice: walking pages, asserting that a full traversal returns the count the collection claims, and catching off-by-one errors at page boundaries.
Open Library
Book and author records with search, and plenty of records with missing or inconsistent fields.
Practice: tolerating optional fields. Real data is messy, and a suite that assumes every record is complete will break on contact with production.
GitHub REST API
Works unauthenticated at low volume and authenticated with a token.
Practice: link-header pagination, conditional requests, and the difference in behavior before and after you authenticate.
For authentication and rate limits
GitHub, authenticated
Practice: token handling, scope errors, and asserting that a request without permission fails in the right way rather than failing generically.
Open-Meteo
Weather forecasts, no key, with a published fair-use policy.
Practice: query parameter combinations and time-based data, where the correct answer changes between runs. Good training for assertions that cannot be exact matches.
HTTPBin again
Practice: basic auth and bearer token flows against endpoints built specifically to exercise them, without risking someone else's quota.
Three assertions worth practicing on any public API
Whichever service you pick, these are the habits that transfer to your own API.
Assert on the body, not only the status. A 200 carrying an empty list where a record should be is a bug that a status-code assertion will happily call a pass. This single habit catches more real defects than any other.
Assert that failures fail correctly. Request something that does not exist and check you get the right code and a usable error shape. Services that return 200 with an error object inside are common, and a suite that does not know that will report green forever.
Assert on relationships, not just fields. If a post references a user, fetch the user and check it exists. Most interesting bugs live between two endpoints rather than inside one.
Pointing an agent at one
If you want to see what generated coverage looks like before trying it on your own service, a public API is a safe place to do it. There is no data to pollute and no environment to break.
Point a project at the base URL and let discovery enumerate the endpoints, then read the generated plan before running anything. The plan is the interesting part. Two things are worth watching as you go.
Does it capture values instead of hardcoding them? A create call returns an identifier and the next call should use it. Hardcoded identifiers are the usual reason a suite works once.
Does it order dependent calls correctly? You cannot fetch a comment on a post that was never created. Watch whether the plan understands that or just lists endpoints alphabetically.
Then run it and read the failures. On a public API most failures will be your assumptions rather than the service, which is exactly the lesson.
If you would rather own the test code, the CLI takes a different route for backend work: you write the calls and assertions yourself in Python, declare what each test needs and produces, and mark cleanup as its own test. That is more work up front and it puts the suite in your repository, which some teams want and others do not.
Moving from practice to your own service
The gap between practicing on a public API and testing your own is bigger than it looks, and knowing where the difficulty jumps saves some frustration.
Public APIs are stateless from your perspective: you read, and whatever you write does not persist or does not matter. Your own service is the opposite. The moment you test something real you inherit authentication that expires, records that have to exist before other records, values that only exist at runtime, and the obligation to clean up after yourself.
None of those appear in a tutorial and all of them appear in week one. So treat the public-API phase as learning assertions, which transfers completely, and expect the state handling to be a separate thing you learn afterwards rather than a continuation of the same skill.
What not to do with these
Do not use them for load testing. They are free, shared, and someone pays the bill.
Do not build a production dependency on one. Terms change, projects get archived, and volunteers get tired.
Do not treat a passing suite against JSONPlaceholder as evidence your own API is correct. It tells you your test setup works, which is a genuinely useful but much smaller claim.
Trying this against a real service
Once the assertion habits are comfortable, the jump to your own API is where the state problems start, and that is the part TestSprite handles as product. Auto-Authentication keeps sessions alive across a run. Dynamic Variables carry an identifier from a create call into the delete call. Dependency Chains work out what has to happen first. Auto-Cleanup removes what the run created.
Getting started against your own service looks like the public-API exercise above: point a project at the base URL, let discovery enumerate the endpoints, and read the generated plan before anything runs. The difference is that the plan now covers authorization and boundary cases, and the run leaves nothing behind.
It is a safe thing to try on a public API first, since there is no data to pollute, and the plan tells you more about the tool than the results will.
Which one should I start with?
JSONPlaceholder for the first hour, because nothing can go wrong. HTTPBin next, because it lets you produce failures deliberately, and practising against failures is where the learning is.
Do any of these need an API key?
Most in this list work without one. GitHub works unauthenticated at low volume, and getting a token is worth doing precisely because it lets you practice authenticated flows.
Can I use these in a CI pipeline?
For a small tutorial suite, yes. For anything running on every commit, run against a local mock instead. Pointing CI at a volunteer-run service is how a useful free resource stops being free.
How is this different from a Postman collection of public APIs?
A collection gives you requests. This list is organised around what each service teaches, which matters more when the goal is to get better at testing rather than to make one call succeed.
What is the fastest way to see generated coverage?
Point a project at a public base URL, let discovery enumerate the endpoints, and read the plan before running anything. The plan tells you more about the tool than the results do.
Pick one API, practice one skill, always write the failing case.
Public APIs are the safest place to learn what good coverage looks like, because there is nothing to break. When you are ready, point the same approach at your own service and keep the habit of asserting on bodies, failures and relationships.