Mock JSON endpoint returning HTTP 400
https://demo-json-400.supercrontab.com/ answers every request with HTTP 400 Bad Request and a small JSON body. No signup, CORS enabled, nothing logged. Use it to see how your client, retry logic or cron job behaves on a 400 before it happens in production.
Live demo endpoint
Any method, any path. Returns 400 Bad Request with Content-Type: application/json. OPTIONS returns 204 with CORS headers.
Call it with curl
curl -i https://demo-json-400.supercrontab.com/
Call it with fetch
const res = await fetch("https://demo-json-400.supercrontab.com/");
console.log(res.status); // 400
const body = await res.json();What HTTP 400 Bad Request means
- When you see it
- The server could not understand the request: malformed JSON, a missing field or a wrong parameter type.
- What a client should do
- Fix the request before sending it again. Log the response body, it usually names the bad field.
- Retry?
- No
Sample response body
{"ok":true,"id":42,"items":["alpha","beta","gamma"]}The default for REST APIs. Parse it with response.json() and check the ok field.
Questions
Does this endpoint really return HTTP 400 every time?
Yes. Every GET, POST, PUT, PATCH or DELETE to https://demo-json-400.supercrontab.com/ gets status 400 Bad Request with a small JSON body, whatever the path, query or headers. OPTIONS gets 204 with CORS headers so browsers can preflight.
Should my client retry a 400?
No. Retrying the same request cannot change the outcome. Fix the request before sending it again. Log the response body, it usually names the bad field.
Can I get a different format, a delay or a custom body?
The same status is available in XML, Text, CSV, HTML, YAML, RSS, JavaScript. Delays, custom headers, error rates, request logging and your own body need a personal endpoint: sign up and create one at /endpoints in a minute, free.