Real-looking data at real URLs, like every other fake API. The difference: you decide how it behaves. Force a 503, add two seconds of latency, make a third of requests fail — on any endpoint, from the query string.
Press Send.
They work on every endpoint, including nested routes and sandboxes. Combine them freely.
# a slow endpoint — test your loading state GET /v1/posts?_delay=3000 # a hard failure — test your error boundary GET /v1/posts?_status=503 # an intermittent one — test your retry logic GET /v1/posts?_fail_rate=0.3 # slow AND flaky, because that is what production is GET /v1/products?_delay=1500&_fail_rate=0.2
| Resource | Rows | Nested |
|---|---|---|
| Loading… | ||
GET /v1/todos?userId=3&completed=true # filter by any field GET /v1/posts?_q=voluptate # full-text search GET /v1/products?_sort=price&_order=desc # sort GET /v1/photos?_page=2&_limit=50 # paginate GET /v1/posts/1/comments # nested
POST, PUT, PATCH and DELETE are echoed, not stored — same as every other
mock API, and the response says so in an x-mock-write header so nobody
loses an afternoon to it. When you need writes that persist, take a sandbox.
# 1. a free key (no confirmation email) curl -X POST https://flaky.dev/v1/keys \ -H 'content-type: application/json' \ -d '{"email":"you@example.com"}' # 2. a sandbox — your own writable copy, 24 hours curl -X POST https://flaky.dev/v1/sandbox \ -H 'authorization: Bearer flk_...' # 3. write to it. this one is real. curl -X POST https://flaky.dev/v1/sandbox/<id>/posts \ -H 'content-type: application/json' \ -d '{"title":"this persists"}'
A sandbox is an overlay, not a copy — only records you change are stored, so the shared dataset stays cached at the edge and your sandbox stays fast.
| Tier | Requests/day | Max page | Sandboxes |
|---|---|---|---|
| Anonymous | 1,000 | 100 | — |
| Free key | 10,000 | 250 | 1 |
| Pro | 1,000,000 | 1,000 | 25 |
Limits reset at 00:00 UTC. Every response carries x-ratelimit-remaining.
Machine-readable description of all of this at /v1/meta.