Sitelet https://funapi.dev/guide

Getting started

Everything here is a simulated sandbox — no real server, no signup, nothing to break. Five minutes and you are testing.

Step 1: Pick an API and open its docs

From the homepage, click any API card. You land on a Swagger-style page listing every endpoint, grouped by tag. Green is GET, blue is POST, orange is PUT, red is DELETE.

The catalog is grouped four ways — fandoms, everyday business domains, original worlds and pure testing scenarios — because the domain is the part you should not have to think about. If you already know how a pizza order or a flight booking behaves, the only new thing on the page is the HTTP.

Step 2: Send your first request

Expand an endpoint, click Try it out, fill the parameters, choose Browser sandbox, then click Run request. You get a real status code, a JSON body, response headers and a ready-to-copy curl command. A good first one:

GET /friends/v1/quotes/random

Browser sandbox runs the whole API engine locally — no network, no rate limits, nothing to wait for. Switch the environment picker to Live API when you want the same endpoint over the real network, served by a Cloud Function against Firestore.

Step 3: Authorize for protected endpoints

Endpoints marked with a lock need a Bearer token. Click Authorize at the top of any docs page and use one of these:

qa-admin-token
full access — everything works
qa-viewer-token
read + write, but DELETE returns 403
anything else
always 401 Unauthorized

One exception: the Cargo API's write endpoints use API-key auth instead — send the header X-API-Key: cargo-key-123. It is there precisely because not every API you will ever test uses Bearer.

For a real token lifecycle rather than a static string, POST /auth/v1/login issues a genuine signed JWT, and the OAuth 2.0 endpoints run the authorization-code, client-credentials and refresh-token flows end to end.

Step 4: Practice negative testing

Every error code is one request away:

400
send page=abc, an invalid JSON body, or a rating of 11
401 / 403
wrong token / viewer token on a DELETE
404
ask for id 999, or a page past the last one
418
GET /coffee/v1/teapot — it is, in fact, a teapot
402
GET /bank/v1/premium/statements — the paywall says hi
500
GET /pizza/v1/oven/status — always fails, by design
503 / 504
GET /protocol/v1/maintenance and /gateway-timeout — outages on demand
413 / 415
POST /movies/v1/movies/{id}/poster — oversized or wrong-type file upload

The point of provoking these deliberately is that each one should make your client do something different. A 429 means wait and retry; a 403 means never retry; a 503 means retry the whole request later; a 400 means fix the request first. A client that treats all four as "the call failed" is a client that will retry its way into an outage.

Step 5: Take it into your own tools

Each docs page has a download button for an OpenAPI 3.1 spec and a Postman collection — import either into Postman, Insomnia, Bruno or Swagger Editor and build your test collections there. Every executed request also shows its equivalent in nine languages: curl, fetch, axios, Python, HTTPie, Playwright, RestAssured, C# and k6.

There is a merged spec covering all the APIs at once, next to the per-API downloads, if you want one file to point a contract tester at.

Step 6: Test concurrency and idempotency

PUT and DELETE on characters, heroes and movies accept an optional If-Match header — send a stale ETag to get 412 Precondition Failed, which is what stops two clients silently overwriting each other. POST endpoints accept an Idempotency-Key header — repeat the same key and you get the original response back instead of a duplicate.

Both are worth rehearsing because both fail quietly in production: an ignored ETag loses an edit nobody notices for a week, and a missing idempotency key turns one network retry into two charges.

Step 7: Automate it

Turn on Deterministic mode in Test settings for repeatable random values — quotes, scores, latency — which is what makes an assertion safe to run in CI. Call window.__funApiReset() from your test runner to reset data without touching the UI.

Feed the OpenAPI spec into a contract tester such as Dredd or Schemathesis to check real responses against the spec, and try GET /pizza/v1/oven/preheat — it always takes about three seconds, which is exactly what you need to prove your client's timeout works.

Against the live API, every caller is isolated by an X-Sandbox-ID header, so a suite that creates and deletes records cannot collide with anybody else running the same suite.

Good to know

POST, PUT and DELETE really change the sandbox data — create a character, then GET it back. Reloading the page or clicking Reset sandbox data restores the original seed.

Where to go next

Jump straight into an API: Friends API · Pokémon API · Star Wars API · Bank API · Auth Playground API · Webhooks API

Go deeper on one technique: Pagination testing · Rate limit testing · Idempotency key testing · ETag and If-Match testing · Webhook signature testing · OAuth and JWT testing · Negative testing · Async job testing

Or look up a status code: all 53 of them

Browse all 39 APIs

Last updated