Skip to main content
4xx Client Error

424 Failed Dependency

The request failed because it depended on another request that previously failed.

Meaning & Description

The HTTP 424 Failed Dependency status code is part of the WebDAV extension (RFC 4918). It indicates that the method could not be performed on the resource because the requested action depended on another action, and that other action failed. This is most commonly seen in batch processing or multi-resource operations where the failure of one component prevents the successful execution of subsequent components.

Common Causes

  • A prerequisite action in a batch request returned an error (like 403 or 409).
  • A client attempted to update multiple properties atomically, but one property was read-only.
  • A workflow dependency chain was broken by validation failures.

How to fix a 424 error

  1. Inspect the response body, which usually contains a 'multistatus' XML or JSON array detailing which specific dependency failed.
  2. Identify the root cause of the initial failure (e.g., a 403 Forbidden on a specific resource).
  3. Correct the failing sub-request and resubmit the entire batch.
  4. Ensure your batch payloads are correctly ordered if operations have sequential dependencies.

Browser & SEO Behaviour

Browser Behavior

Browsers do not natively interpret 424 errors during normal navigation, treating them as generic client errors and displaying the server's response body.

SEO Impact

Search engines are unaffected by 424 errors as they do not perform batch POST or PROPPATCH requests.

CDN Behavior

CDNs will typically not cache 424 responses, as they represent the failure of a non-idempotent batch or patch operation.

Code Examples

HTTP
PROPPATCH /workspace/file.txt HTTP/1.1
Host: api.example.com
Content-Type: application/xml

<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:">
  <D:set>
    <D:prop>
      <D:displayname>New Name</D:displayname>
    </D:prop>
  </D:set>
</D:propertyupdate>
Node.js (Express)
app.post('/api/batch', async (req, res) => {
  const { createFolder, uploadFile } = req.body;
  const folderResult = await processFolder(createFolder);
  if (!folderResult.success) {
    return res.status(400).json({ error: "Folder creation failed" });
  }
  const fileResult = await processUpload(uploadFile);
  if (!fileResult.success) {
    // If the file upload fails, we might roll back and say the whole dependency failed
    return res.status(424).json({ error: "File upload failed dependency on folder" });
  }
  res.status(200).send("Batch complete");
});
Python (FastAPI)
@app.post("/api/transactions")
def run_transaction(steps: List[Step]):
    for i, step in enumerate(steps):
        if not execute_step(step):
            # Return 424 for subsequent steps that depended on this
            raise HTTPException(status_code=424, detail=f"Step {i} failed, aborting transaction")
    return {"status": "success"}
Go (net/http)
func batchHandler(w http.ResponseWriter, r *http.Request) {
    err := performStep1()
    if err != nil {
        http.Error(w, "Step 1 failed", http.StatusBadRequest)
        return
    }
    err = performStep2()
    if err != nil {
        http.Error(w, "Step 2 failed dependency", 424)
        return
    }
    w.WriteHeader(http.StatusOK)
}
C# (ASP.NET Core)
[HttpPost("batch")]
public IActionResult ProcessBatch([FromBody] BatchRequest request) {
    var res1 = Service.DoFirst(request.Task1);
    if (!res1.IsSuccess) return BadRequest(res1.Error);
    
    var res2 = Service.DoSecond(request.Task2);
    if (!res2.IsSuccess) return StatusCode(424, "Task 2 failed due to prior failures.");
    
    return Ok();
}
curl
curl -X POST https://api.example.com/batch \
  -H "Content-Type: application/json" \
  -d '{"tasks": ["task1", "task2"]}' \
  -i

Raw HTTP Response Example

HTTP Response
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset=utf-8

<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:">
  <d:response>
    <d:href>/docs/report.pdf</d:href>
    <d:propstat>
      <d:prop><d:authors/></d:prop>
      <d:status>HTTP/1.1 403 Forbidden</d:status>
    </d:propstat>
    <d:propstat>
      <d:prop><d:displayname/></d:prop>
      <d:status>HTTP/1.1 424 Failed Dependency</d:status>
    </d:propstat>
  </d:response>
</d:multistatus>

Real-world Examples

WebDAV Servers: Returns 424 during a PROPPATCH if a single property update is rejected, causing the entire atomic operation to fail.
OData APIs: Can return 424 in batch request processing when a change set fails, causing dependent requests in the same batch to be aborted.
GraphQL Servers: Sometimes maps nested resolver failures to a 424 equivalent when a parent node fails to fetch, nullifying child queries.

Frequently Asked Questions

Is 424 Failed Dependency only for WebDAV?

Officially, yes. It was defined in the WebDAV specification. However, many modern REST APIs use it to indicate failures in batch processing or transactional pipelines.

How do I fix a 424 error?

You must identify which primary action failed (usually indicated alongside the 424 error in a multi-status response), fix the underlying issue for that action, and retry the batch request.

What is a 207 Multi-Status response?

A 207 response allows a server to return multiple status codes in a single XML/JSON body. 424 is often found embedded within a 207 response to describe the fate of dependent sub-requests.

Can a GET request return 424?

It is highly unusual. 424 is meant for operations that alter state in a transactional or dependent manner, such as POST, PUT, PATCH, or PROPPATCH.

Why use 424 instead of 400 Bad Request?

400 Bad Request implies the request syntax itself was malformed. 424 implies the syntax was fine, but a logical sequence of execution was broken by an earlier failure.

Did You Know?

424 Failed Dependency is one of the few HTTP status codes specifically designed to describe 'collateral damage' in API requests.

In a WebDAV PROPPATCH, operations are atomic. If one property cannot be set (e.g., it is read-only), all other property sets fail with 424.

The concept of batching and dependencies led to the creation of the 207 Multi-Status code to encapsulate 424 errors.

Developer Tips

  • When building batch APIs, carefully consider whether you want partial success or atomic transactions. Use 424 only if you enforce atomic rollback.
  • Always provide a structured response body (like JSON or XML) when returning 424, so the client knows exactly which dependency triggered the failure.
  • If your API isn't strictly following WebDAV, you might prefer returning a 400 or 422 with a detailed JSON error object for batch failures, as 424 is relatively obscure.

Interview Questions

These are questions you might face in a backend or API design interview that touch on HTTP 424.

What does the 424 Failed Dependency status code signify?

It signifies that a requested action could not be completed because it relied on another action in the same request, and that prerequisite action failed.

In what scenario is 424 most commonly encountered?

It is most common in WebDAV PROPPATCH requests or API batch operations where tasks are executed atomically and a single failure aborts the rest.

How does 424 relate to the 207 Multi-Status code?

A 207 response can encapsulate multiple individual status codes. When a batch fails, the root cause might return a 403, while subsequent aborted steps return 424, all packaged inside a single 207 response.

Common Interview Mistakes

  • Thinking 424 is related to missing NPM or package dependencies.
  • Assuming 424 is a server error (5xx) rather than a client error resulting from a flawed batch request.
  • Failing to mention the context of batch operations, atomic transactions, or WebDAV.