424 Failed Dependency 4xx
The request failed because it depended on another request that failed.
What does 424 mean?
A 424 Failed Dependency response means the current request couldn't be completed because it depended on the outcome of a different request or operation, and that other operation failed. The request being responded to might be entirely valid on its own — the problem is that something it relies on didn't succeed.
Like 422 and 423, this code originated in WebDAV (RFC 4918), specifically in the context of operations that involve multiple sub-operations (e.g., a single client request that translates into several server-side actions on multiple resources) — if one sub-operation fails, any subsequent operations that depended on it can't proceed, and 424 communicates this dependency relationship explicitly.
How a 424 behaves
- It implies a relationship between multiple operations — the response isn't really about this request's own validity, but about something else it depended on
- It can carry a body explaining which dependency failed and why, ideally
- It's most relevant to batch/compound operations — a single client action that triggers multiple server-side steps, where steps can have dependencies on each other
Common causes
If you're building the API or website:
- A batch operation involves multiple steps where later steps depend on earlier ones succeeding — if an early step fails, later dependent steps return 424 rather than being attempted (and failing in a less informative way)
- A WebDAV-style operation (e.g., moving/copying a collection of resources) where moving the "parent" failed, so operations on "children" that depended on the parent's new location can't proceed
If you're calling an API:
- You're using a batch/bulk API where one operation in the batch failed, and subsequent operations that depended on it are reported as 424 rather than being executed
- A multi-step workflow (create resource A, then use A's ID to create resource B) failed at step A, so step B is reported as 424 rather than attempted with an invalid/missing dependency
If you're a website visitor:
- Essentially never encountered directly — 424 is a low-level API/protocol detail relevant to batch operations, not typical page navigation
How to fix it
As an API/website builder:
- In batch/compound operations, clearly report which operation failed (likely with its own specific error code — 400, 422, 409, etc.) and then mark dependent operations as 424, ideally referencing the operation they depended on
- Consider whether your batch API design could benefit from returning a structured response that maps each requested operation to its outcome (success, specific failure, or 424-due-to-dependency), helping clients understand the full picture in one response
As an API consumer:
- When you see 424, look for information about which dependency failed — the actual root cause is elsewhere, and fixing that underlying issue is what will resolve the 424
- For multi-step workflows, check the result of each step before proceeding — if step A fails, don't attempt step B (which the API might report as 424 anyway, but catching it earlier in your own logic is more efficient)
As a website visitor:
- Not applicable directly — if an application surfaces this, the underlying issue is with a different part of a multi-step operation, not something to address at this specific step
424 vs 423 vs 422
| Code | Meaning | WebDAV origin context |
|---|---|---|
| 422 Unprocessable Entity | The request itself is well-formed but fails validation | A single operation's data doesn't pass validation |
| 423 Locked | The resource has an explicit lock preventing this operation | A single resource is locked, blocking this specific operation |
| 424 Failed Dependency | This operation depends on another operation that failed | Part of a compound/batch operation where one step's failure affects dependent steps |
Real-world examples
WebDAV operations like COPY or MOVE on a collection (essentially a folder) involve operating on multiple resources (the folder and everything inside it) as part of one client request — if copying/moving one of the contained resources fails (perhaps due to a lock, returning 423), other operations that depended on the overall move succeeding might be reported as 424. Some batch/bulk REST APIs that process multiple operations in a single request use 424-equivalent reporting (sometimes via custom response structures rather than literal HTTP status codes per item) to indicate that certain items in a batch couldn't be processed because earlier items they depended on failed.
SEO implications
None — 424 is exclusively relevant to compound/batch API operations and has no bearing on page-level content or SEO.
FAQ
What's the difference between 424 and other 4xx errors?
Most 4xx errors describe a problem with this specific request (its format, validation, permissions, etc.). 424 specifically says "this request itself might be fine, but something it depends on failed" — the root cause is elsewhere.
Is 424 common in typical REST APIs?
Less common than in its original WebDAV context — many modern batch APIs handle "this depends on that, and that failed" scenarios through custom response structures (e.g., a JSON array mapping each batch item to its own success/failure status) rather than the literal 424 status code, though the underlying concept (dependency failure) is the same.
If I get a 424, where should I look for the actual problem?
Look for information about the operation this one depended on — the 424 itself is more of a "ripple effect" notification than the root cause. The actual failure (a validation error, a lock, a conflict) occurred in that other operation.
Can a single client action result in multiple 424s?
In principle, yes — if a compound operation has a chain of dependencies (A → B → C) and A fails, both B and C could be reported as 424 (each depending, directly or indirectly, on A's success), though the exact reporting depends on the specific API/protocol implementation.
Is there a way to avoid triggering 424?
Generally, by checking the results of prerequisite operations before attempting dependent ones in your own client logic — if you control the sequencing, you can avoid sending requests that you already know will fail due to a known earlier failure, rather than relying on the server to tell you via 424.
Fun fact
424 completes a trio with 422 and 423 as status codes born from WebDAV's relatively sophisticated (for the late 1990s) approach to handling complex, multi-resource operations over HTTP — concepts like "this specific value is invalid" (422), "this resource is locked" (423), and "this depended on something that failed" (424) represent a level of operational nuance that most simple CRUD APIs don't need, but that becomes relevant the moment a single client action can ripple across multiple resources with interdependencies.