HTTP status code · Client errors (4xx)
424 Failed Dependency
424 Failed Dependency means the server did not perform an action because it depended on another action in the same request, and that one failed. You find it mostly inside WebDAV 207 Multi-Status responses, next to the entry that caused the real error.
| Class | 4xx, Client errors |
|---|---|
| Defined in | RFC 4918 §11.4 |
| Cacheable by default | Only with explicit Cache-Control or Expires |
| Safe to retry | Only after fixing the action it depended on; resending the batch unchanged fails the same way |
| Relevant headers | None specific to this code |
What 424 means
RFC 4918, section 11.4, gives the canonical example: a PROPPATCH is atomic, so if setting one property fails, every other property change in the same request is reported as 424. The 424 entries are collateral; the one with a different code (403, 409, 507) is the actual problem.
Outside WebDAV, a few batch and workflow APIs use 424 for a step that was skipped because a previous step failed. That is an extension of the idea, not something the RFC defines.
Common causes
If you run the server
- One property in a PROPPATCH is protected or invalid, which makes the whole atomic update fail and marks the rest 424.
- In a batch API, an earlier operation (create the customer) failed, so a dependent one (create the invoice for that customer) was never attempted.
How to fix it
If you run the server
- Ignore the 424 entries at first and find the entry in the 207 body with a different status; fixing that one clears the others.
- When designing a batch endpoint, report the failing step with its own code and the skipped ones with 424, so the client can tell cause from consequence.
How to diagnose 424
You rarely send 424 as the status line. It lives inside a 207 Multi-Status body, one status per resource or property, as in this PROPPATCH response.
curl -X PROPPATCH https://dav.example.com/docs/report.odt \
-H 'Content-Type: application/xml' --data @props.xml
# HTTP/1.1 207 Multi-Status
# <D:propstat>
# <D:prop><D:getetag/></D:prop>
# <D:status>HTTP/1.1 403 Forbidden</D:status> <- the real cause
# </D:propstat>
# <D:propstat>
# <D:prop><Z:author/></D:prop>
# <D:status>HTTP/1.1 424 Failed Dependency</D:status> <- skipped
# </D:propstat>Commonly confused with
- 424 vs 207
- 207 is the envelope that carries one status per item; 424 is one of the statuses that can appear inside it.
- 424 vs 502
- 502 means an upstream server returned a bad response; 424 means another action within the same request failed, not another server.
Frequently asked questions
- Why did every property in my PROPPATCH fail with 424?
- PROPPATCH is all or nothing. One property failed for a real reason, and RFC 4918 requires the server to report the others as 424 because they depended on the whole request succeeding. Find the entry with a different status code.
- Should a REST API use 424?
- It can for batch or multi-step operations where one step was skipped because a previous one failed. For a single failing call to another service, 502 or 503 describes the situation better.
- Is 424 a client or a server problem?
- It is in the 4xx range, so the fix is usually in the request: the action that actually failed was refused because of what the client asked for, such as changing a protected property.
Last reviewed by Arielton Oberek.