10 Best Public & Dummy APIs for Testing (2026)

In this guide

1. Public test APIs comparison table
2. Fake CRUD Data APIs
3. HTTP Behavior Simulation
4. Real Public APIs
5. Built for Test-Automation Practice
6. How to Choose
7. What actually breaks when you depend on one
8. Simulating failure locally instead
9. Matching the sandbox to what you are teaching
10. Common mistakes with public test APIs
11. Frequently asked questions about public test APIs
12. Hitting the sandboxes from a test
13. Rules for using someone else's API in your suite
14. Building your own sandbox from a spec

Public test APIs comparison table

Fake CRUD Data APIs

• JSONPlaceholder — the default choice used throughout most current API testing tutorials, including every framework tutorial on this site. No auth, predictable resources (/users, /posts, /comments, /albums, /photos, /todos), and stable, well-documented behavior.
• ReqRes — user-management-shaped resources with realistic pagination, useful when your test cases specifically need to exercise paginated list endpoints.
• Fake Store API — e-commerce-themed data (products, carts, users), useful for practicing test cases shaped like a shopping-cart or catalog domain rather than generic posts/comments.
• DummyJSON — a larger dataset across products, carts, users, posts, comments, quotes, and recipes, with a simulated login flow for practicing authenticated request patterns.

Important for all four: writes don't persist. A POST returns a realistic 201 with what looks like a newly created resource, but nothing is actually stored — a follow-up GET for that same ID won't return it. This is fine for learning framework syntax; it's not a substitute for testing against a real backend with real state.

HTTP Behavior Simulation

• httpbin.org — not a fake business domain, but a tool for simulating exact HTTP behaviors: /status/404 returns a specific status code on demand, /delay/3 responds after a defined number of seconds, /headers echoes back what your client actually sent, /redirect/3 chains through a defined number of redirects. This is the tool to reach for when you need to verify your own test framework's timeout, retry, or redirect-following behavior actually works — see the common pitfalls sections in our framework tutorials for why an unhandled timeout is a recurring real bug.

Real Public APIs

• PokeAPI — a real, free, no-auth public API with genuinely deep, nested response data, useful specifically for practicing schema validation and nested-field assertions against realistic complexity a flat fake-data API doesn't provide.
• GitHub REST API — real production infrastructure with generous unauthenticated rate limits (higher with a token), useful for practicing against real pagination headers, real rate-limit responses, and a genuinely well-documented, versioned API contract.
• OpenWeatherMap — a real API requiring a free-tier API key, useful specifically for practicing API-key-based authentication and handling a third-party service with its own rate limits and quota behavior.

Built for Test-Automation Practice

• restful-booker — a demo API created specifically for the test-automation community to practice against, including a token-based auth flow, making it a common choice specifically for learning authenticated request patterns beyond what the simpler fake-CRUD APIs above cover.

How to Choose

• Learning a new framework's basic syntax → JSONPlaceholder — the most predictable, most-documented default.
• Need pagination in your example test cases → ReqRes.
• Need auth-flow practice specifically → DummyJSON or restful-booker, alongside authentication and authorization testing for APIs.
• Need to verify your own framework handles timeouts/retries/redirects correctly → httpbin.org.
• Need deeply nested response data for schema validation practice → PokeAPI.
• Need real rate-limiting and pagination behavior, not simulated → the GitHub REST API.

What actually breaks when you depend on one

The rules above are easier to follow once you have seen the specific ways a public sandbox fails a suite. None of these are hypothetical, and all of them present as "the tests are flaky" rather than as an outage.

The common thread is that the failure is invisible in your version control history. That is what makes a public dependency expensive: the normal debugging instinct — look at what changed — leads nowhere.

Simulating failure locally instead

Most of what teams reach for a public API to do is failure simulation, and that is the part you can run yourself. httpbin covers the common cases and runs in a container, so it is available offline, unlimited and instant:

docker run -d --name httpbin -p 8080:80 kennethreitz/httpbin

# every status code you need to handle
curl -i http://localhost:8080/status/500
curl -i http://localhost:8080/status/429

# a slow response, for timeout and retry logic
curl -i http://localhost:8080/delay/10

# payload echoed back, for verifying what your client actually sent
curl -s -X POST http://localhost:8080/post \
  -H 'Content-Type: application/json' \
  -d '{"sku":"A-1","qty":2}' | jq '.json, .headers'

That last one deserves a mention on its own. When a client library is doing something unexpected — a header you did not set, a body serialised differently than you assumed — an echo endpoint is the fastest way to see the request as the server sees it. It is worth keeping one running locally for that alone.

For anything stateful, a generated mock from your own OpenAPI document beats any public API, because it answers questions about your contract rather than someone else's — the best API mocking tools covers the options.

Matching the sandbox to what you are teaching

The four categories are not interchangeable, and picking the wrong one makes an exercise harder than the skill it is meant to teach.

Learning HTTP verbs and status codes — a fake CRUD API. The value is that responses are predictable and the data resets, so a learner can make a mistake and start over.

Learning client behaviour: retries, timeouts, redirects, auth headers — a behaviour-simulation service. These let you request the failure you want to handle, which no realistic API will do on demand.

Learning to read an unfamiliar contract — a real public API. Messy pagination, inconsistent naming and genuine documentation gaps are the point, not a defect.

Learning a framework's mechanics — a purpose-built practice API, or a local container. Anything whose availability varies adds noise to an exercise about syntax.

Common mistakes with public test APIs

Putting one in a merge gate. Worth repeating, because it is the mistake with the highest cost: a red build caused by someone else's free service is a build nobody trusts, and a suite nobody trusts gets bypassed.

Load testing against a free endpoint. This is abuse of a shared resource, it gets your IP blocked, and it measures the sandbox's capacity rather than anything about your code.

Asserting on data instead of shape. assert response.json()["name"] == "Leanne Graham" passes until the maintainer edits a fixture. Assert the field exists and has the right type; assert exact values only against data you control.

Storing real credentials for a real public API. Sandbox keys are still keys. They belong in a secret manager on the same terms as any other credential, not in a tutorial repository — see JWT secret leakage in test files.

Not recording which sandbox a test depends on. When a service disappears, you want to find every affected test in one search. A shared constant or fixture makes that a one-line change; a URL pasted into forty tests does not.

Treating a sandbox as a substitute for your own contract. Public APIs are excellent for learning HTTP and for demonstrating a technique in documentation. They tell you nothing about whether your API matches its specification, which is the question a real suite exists to answer. Use them to learn the tool, then point the tool at your own OpenAPI document — how to generate API tests from an OpenAPI spec covers that step.

Frequently asked questions about public test APIs

What is the best free dummy API for testing? JSONPlaceholder — free, no auth, predictable fake CRUD data, used throughout most current API testing tutorials.

What is httpbin.org used for? Testing your own tooling against specific HTTP conditions — status codes, delays, redirects, header echoing — rather than simulating a fake business domain.

Do writes to a dummy API like JSONPlaceholder actually persist? No — they simulate a realistic response without actually storing the change.

What is restful-booker and why was it built? A demo API purpose-built for the test-automation community to practice against, including token-based auth.

Should I test against a real public API or a dummy one? Dummy APIs for learning a framework or writing examples; real public APIs when you want to practice against genuine rate limiting, pagination, and auth.

Can I use these APIs to test my own test framework's timeout and retry handling? Yes — httpbin.org's /delay/{n} endpoint is built exactly for this.

Hitting the sandboxes from a test

These are the endpoints worth wiring into a tutorial or a smoke test — no key, no rate-limit surprises, stable shapes:

# JSONPlaceholder — fake REST resources, accepts writes (returns them, stores nothing)
curl -s https://jsonplaceholder.typicode.com/posts/1 | jq
curl -s -XPOST https://jsonplaceholder.typicode.com/posts \
  -H 'Content-Type: application/json' -d '{"title":"t","body":"b","userId":1}' | jq .id

# httpbin — echoes the request back, which is what you want for header/auth tests
curl -s https://httpbin.org/headers -H 'X-Trace: abc' | jq .headers
curl -s https://httpbin.org/status/429 -o /dev/null -w '%{http_code}\n'
curl -s https://httpbin.org/delay/3 -o /dev/null -w '%{time_total}s\n'

# Star Wars API and REST Countries — deep, read-only data for pagination tests
curl -s 'https://swapi.dev/api/people/?page=2' | jq '.results | length'
curl -s https://restcountries.com/v3.1/name/japan | jq '.[0].capital'

Point a generated suite at one of them to see the whole workflow end to end before you aim it at your own API:

# httpbin publishes its own OpenAPI document
curl -s https://httpbin.org/spec.json -o httpbin.json
schemathesis run httpbin.json --url https://httpbin.org --checks status_code_conformance

Rules for using someone else's API in your suite

A public sandbox is other people's infrastructure. Four rules keep a tutorial or smoke test from becoming a support ticket for them and a flaky test for you.

Never put one in a gate. A public API you do not control is an availability dependency you cannot fix. Use them in tutorials, in local experiments and in documentation examples — not in a job that blocks a merge. API quality gates: what to measure covers what does belong there.

Rate-limit yourself. A load test against a free public API is abuse, not testing. If you need throughput, run the target locally.

Pin what you assert on. Public datasets change. Assert on shape and status rather than on the specific values a response happened to contain last year.

Have a local fallback. The most robust version of a tutorial runs against a container by default and a public API only when asked:

# docker-compose.yml — a local stand-in that never rate-limits or disappears
services:
  jsonserver:
    image: clue/json-server
    command: --watch /data/db.json --host 0.0.0.0
    volumes: ['./fixtures:/data:ro']
    ports: ['3000:3000']

  httpbin:
    image: kennethreitz/httpbin
    ports: ['8080:80']

# the same test, against local containers instead of the internet
API=http://localhost:3000 pytest tests/
API=http://localhost:8080 pytest tests/test_http_behaviour.py

Building your own sandbox from a spec

The most useful practice target is your own API, mocked. It has your shapes, your auth model and your edge cases, and it never rate-limits you:

# a complete practice API from an OpenAPI document, in one command
npx @stoplight/prism-cli mock openapi.yaml --port 4010 --dynamic

# every operation the spec declares, with schema-valid random responses
curl -s http://localhost:4010/v1/orders/42 | jq
curl -s -o /dev/null -w '%{http_code}\n' http://localhost:4010/v1/does-not-exist   # 404

Prism validates requests against the spec too, so it doubles as a way to learn what your own contract actually requires:

# sending something the spec forbids gets a spec-shaped error, not a silent 200
curl -s -XPOST http://localhost:4010/v1/orders \
  -H 'Content-Type: application/json' -d '{"qty":-1}' | jq '.title, .detail'

For teams writing tutorials or onboarding material, this is the pattern worth standardising on: a checked-in spec, a one-line mock, and examples that work offline on day one. Public sandboxes are for the first ten minutes; a mock of your own contract is for everything after that.

Sources and further reading

• RFC 9110 — HTTP Semantics — the normative definition of methods, status codes and headers.
• OpenAPI Specification — the normative spec for describing HTTP APIs.
• Schemathesis documentation — property-based testing driven straight from an OpenAPI spec.

Key takeaways

• JSONPlaceholder is the default for a reason — stable, documented, no-auth, and used throughout this site's own tutorials.
• Writes to fake-data APIs never persist — don't mistake a realistic 201 response for actual stored state.
• httpbin.org tests your tooling, not a fake domain — reach for it specifically to verify timeout/retry/redirect handling.
• Real public APIs (PokeAPI, GitHub) are worth using when you need genuine rate-limiting and pagination behavior, not a simulation of it.
• restful-booker exists specifically for test-automation practice, including auth flows the simpler fake-CRUD APIs don't cover.