HTTP 400 — Bad Request
HTTP 400 means the server cannot process the request because something about it is malformed — invalid JSON, a missing required field, a value in the wrong shape. The request should not be repeated unchanged.
When 400 shows up
- Clients posting payloads that fail schema validation.
- Malformed query strings or headers that break request parsing.
Mocking a 400 response
A response with this status can be faked end to end with a local mock rule — no backend changes needed. The configuration below mirrors the rule fields the ApiSimul editor uses (method, path, status, delay in milliseconds, response body):
{
"method": "GET",
"path": "/api/users",
"status": 400,
"delay": 180,
"enabled": true,
"body": {
"error": "validation_failed",
"fields": { "email": "must be a valid address" }
}
}Dynamic placeholders such as {{random.name}}, {{string.uuid}} or {{number.int 1 100}} can appear inside the body to vary each response, which keeps client-side list rendering and retry logic honest during development.
Frequently asked questions
What does HTTP 400 mean?
The request itself is broken; fixing it requires changing the request, not retrying it. Good responses describe the validation failure in the body.
How can I test a 400 response without a real backend?
Define a mock rule with the method and path your client requests and set the status to 400. The example configuration above returns this response after the listed delay, so the client exercises its 400 handling exactly as it would against a live server.
Related status codes
Need the response in your own project? Spin up rules for any status with the ApiSimul mock server, or browse every status code page.