Last month I was writing a client for a partner API and wanted to check what happens when they return a 503. Simple question. The honest answer was "I don't know, I'd have to fake it", and faking it meant either monkeypatching fetch or spinning up an express server that returns 503, which I've done about forty times in my life and never kept.
So this time I kept it, and put it on a domain:
curl -i https://demo-json-503.supercrontab.com/
HTTP/2 503
content-type: application/json
{"ok":true,"id":42,"items":["alpha","beta","gamma"]}
The hostname is the whole API. demo-{format}-{status}.supercrontab.com, where format is one of json, xml, txt, csv, html, yaml, rss, js and status is one of 200, 201, 204, 400, 401, 403, 404, 409, 422, 429, 500, 502, 503, 504. That's 112 URLs. CORS is wide open so you can hit them from a browser tab too.
There's an index page with the sample body, curl and fetch snippets for each one, and a note about whether a client should retry that particular status: https://supercrontab.com/mock
Things I've actually used them for this week
Retry logic, mostly. Point the client at demo-json-503, watch it back off and retry. Then point it at demo-json-400 and make sure it doesn't retry, because a 400 won't get better on its own. The second case is where I've seen the most bugs in real code, including my own.
The CSV and XML ones are nice for parser tests. A tiny well-formed body, so you can have one integration test that touches the network and the rest can be unit tests with the same fixture.
And error screens. fetch('https://demo-json-429.supercrontab.com/') from the frontend, see the rate-limit banner, done. No backend changes, no feature flag.
If the static ones aren't enough
They're static on purpose, but sometimes you need a URL that returns your body, or is slow, or fails only some of the time. With a free account you get an endpoint at yourslug.supercrontab.com where you set the status, the content type, the body (up to 64 KB), a delay in ms, and an error rate. 10% error rate is a surprisingly good imitation of a flaky vendor.
You can also put auth on it (Basic, Bearer, an API key header, or HMAC over the body) if you want to check that your client actually sends credentials the way you think it does. And it logs every request it receives, headers and body, so it doubles as a webhook receiver.
Free plan limits: 3 endpoints, 30 requests a minute, 500 a day. Enough for tests, useless for production traffic, which is the idea.
httpbin?
I still use httpbin, it's great. It just doesn't do non-JSON formats, and it doesn't give you a URL with your own body and delay that a teammate or a CI job can hit tomorrow. That's the gap.
If there's a status code or format you need and it's not there, say so in the comments, adding one is a five-line change.
Top comments (0)