About Fun API Playground

Fun API Playground is a sandbox for practising REST API testing. It exists because the realistic parts of API work — the 429 you have to back off from, the 412 that means someone else wrote first, the POST that timed out and may or may not have gone through — are exactly the parts you cannot rehearse against a real production API without consequences.

Who it is for

QA engineers writing their first API test suite, developers learning what the headers in an HTTP exchange are actually for, students who need an endpoint that answers immediately, and anyone building a client who wants to see it meet a failure before a customer does.

No account, no API key, no quota to apply for. The documented Bearer tokens are printed on every docs page because they are demo credentials, not secrets.

How it actually works

There are two of everything. The web playground runs the entire API engine inside your browser, with no backend involved at all — that is why "Try it out" answers instantly and keeps working offline. The same catalog is also served over the real network by a single Express application on Firebase Cloud Functions, backed by Firestore, for when you need a genuine HTTP round trip from curl, Postman or CI.

Both are generated from one catalog definition, so the docs, the OpenAPI 3.1 spec, the Postman collection and the live endpoints cannot describe different APIs.

What is real and what is pretend

The data is invented. The characters, orders, flights and transfers are fiction, and no endpoint here is a proxy for a real service.

The HTTP behaviour is not invented. Rate limits are counted in a shared store over a live window. Webhook deliveries are signed with a real HMAC you can verify. Tokens are genuinely signed and genuinely expire. Optimistic concurrency compares real version tokens, and writes run inside real transactions. That distinction is the entire point: practising against a mock that only pretends to fail teaches you nothing about the client you are writing.

Your data

Requests are isolated per caller by a sandbox id, so anything you create, edit or delete is yours and resets on demand. There is nothing to sign up with, so there is no account to leak.

Analytics load only after an explicit opt-in — decline and no third-party tag is ever fetched.

Related playgrounds

All 39 mock REST APIs · Getting started guide · Testing techniques