HTTP 424 ā Failed Dependency
HTTP 424 (WebDAV, later borrowed by HTTP APIs) reports that the request failed because a request it depended on failed first. Batch chains and multi-step workflows surface it most.
When 424 shows up
- Batch operations where step two collapses because step one failed.
- Orchestration APIs propagating an upstream failure to dependents.
Mocking a 424 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/pipeline/{{param.id}}",
"status": 424,
"delay": 240,
"enabled": true,
"body": {
"error": "dependency_failed",
"failedStep": "provision"
}
}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 424 mean?
This request was abandoned because a prerequisite request failed. Fix the dependency and re-run the chain.
How can I test a 424 response without a real backend?
Define a mock rule with the method and path your client requests and set the status to 424. The example configuration above returns this response after the listed delay, so the client exercises its 424 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.