What Is Status Code: 207 Multi-Status? The Bulk Operation Report

You're building an admin panel for a content management system. You need to delete 100 articles at once. You could send 100 separate DELETE requests, but that would be incredibly inefficient, slow, and hard to manage. What if you could send just one request to perform this bulk operation and get back a detailed report on the success or failure of each individual item?

This is the complex, powerful problem that the 207 Multi-Status HTTP status code is designed to solve.

In the world of web development and APIs, HTTP status codes are essential tools that help clients and servers communicate clearly. While many developers are familiar with common status codes like 200 OK or 404 Not Found, there are several niche codes designed for very specific scenarios that you might not have encountered yet. One of these is the 207 Multi-Status status code.

One such status code is 207 Multi-Status. Unlike the everyday codes, this one doesn’t appear everywhere but when it does, it’s incredibly powerful, especially in WebDAV (Web Distributed Authoring and Versioning) and APIs that need to report multiple results in a single response.

In this in-depth blog post, we will explore the 207 Multi-Status code from the ground up. We’ll cover its meaning, how it works, real-world use cases, and why it is particularly useful in certain API contexts such as WebDAV. And, to help you test and document APIs efficiently including those that use 207 Multi-Status make sure to download Apidog for free. If you want to simulate, mock, and test status codes like 207 Multi-Status, you don’t have to spin up a custom server. Instead, try Apidog. It’s an all-in-one API platform where you can design, document, and test APIs. With Apidog, you can create a mocked 207 response in seconds to see how your client handles it. And yes it’s free to download!

button

Now, let’s roll up our sleeves and explore what 207 Multi-Status really means, why it exists, and how you can use it effectively in your projects.

Where Does 207 Multi-Status Come From?

The 207 status code comes from the Web Distributed Authoring and Versioning protocol better known as WebDAV. WebDAV extends HTTP to allow clients to perform remote web content authoring operations.

In particular, WebDAV supports batch operations on collections (folders containing multiple files/resources), and these operations often have complex, per-resource response statuses. To communicate this complexity, 207 Multi-Status was introduced.

When performing actions like copying, moving, or deleting multiple files, a single HTTP status code isn’t enough. Some files may succeed, while others fail.

That’s where 207 Multi-Status comes in it allows granular reporting of each resource’s outcome within one response. The 207 status code was invented to provide a detailed account of the outcome of these bulk operations.

What Does HTTP 207 Multi-Status Actually Mean?

The 207 Multi-Status status code is a WebDAV-specific extension of HTTP. It indicates that the server is returning multiple status codes for different parts of a request. At its core, the HTTP 207 Multi-Status status code is a way for a server to return multiple status codes in a single HTTP response. Unlike typical HTTP codes which provide a single response status for a single request, 207 provides a separate status for multiple independent operations within the same response.

This is especially useful when dealing with operations on multiple resources at once, where the responses for individual items might differ (some might succeed, others might fail).

The 207 response usually contains an XML or JSON body detailing the status of each individual resource or operation, making it a multi-faceted response.

In simple terms: One request, many results.

A typical 207 response looks something like this:

HTTP/1.1 207 Multi-StatusContent-Type: application/xml; charset="utf-8"

<?xml version="1.0" encoding="utf-8"?>
<multistatus xmlns="DAV:">
  <response>
    <href>/files/report.pdf</href>
    <status>HTTP/1.1 200 OK</status>
  </response>
  <response>
    <href>/files/archive.zip</href>
    <status>HTTP/1.1 423 Locked</status>
  </response>
  <response>
    <href>/files/photo.jpg</href>
    <status>HTTP/1.1 404 Not Found</status>
  </response>
</multistatus>

This response tells us that a bulk operation on three files had three different outcomes:

report.pdf was successfully processed (200 OK).
archive.zip could not be processed because it's locked (423 Locked – a WebDAV-specific code).
photo.jpg could not be found (404 Not Found).

In other words, instead of returning a single result like 200 OK, the server bundles multiple outcomes into one response. This is useful when the request targets multiple resources or when different operations succeed or fail differently.

Example:

Some files in a batch upload succeed.
Others fail due to permission errors.
Instead of sending multiple HTTP responses, the server packs everything into one 207 Multi-Status response.

The Anatomy of a 207 Response

The power and complexity of 207 lie in its response body, which is always in XML format.

<multistatus>: The root element that wraps all the individual results.
<response>: A container for the result of each individual resource involved in the bulk operation.
<href>: Contains the path to the specific resource.
<status>: Contains the HTTP status line (HTTP/1.1 [CODE] [PHRASE]) that describes the outcome for that specific resource. This is the most important part.

This structure allows for an incredibly detailed and granular report.

A typical 207 Multi-Status response looks like this:

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

<multistatus xmlns="DAV:">
  <response>
    <href>/file1.txt</href>
    <status>HTTP/1.1 200 OK</status>
  </response>
  <response>
    <href>/file2.txt</href>
    <status>HTTP/1.1 403 Forbidden</status>
  </response>
</multistatus>

This means:

/file1.txt → Success.
/file2.txt → Failed due to forbidden access.

Notice how each resource has its own status. That’s the essence of 207.

How Does 207 Multi-Status Work?

When a client sends a single request that involves multiple resources say, a batch delete or batch update the server processes each individual operation separately. The 207 response aggregates these individual statuses and returns them as a consolidated report.

For example, if a client asks to delete three files and two were successfully deleted but one failed due to permissions, the server doesn’t just return a generic error or success. Instead, it sends a 207 Multi-Status response with detailed status information for each file.

The response body typically contains XML (or JSON in newer implementations) that looks like this:

This clearly tells the client which operations succeeded and which failed, enabling smarter error handling and responses.

Why Multi-Status Responses Are Needed

Without 207, here’s what would happen:

You send a request to delete 10 files.
The server responds with 200 OK.
But wait what if 3 files failed due to permissions? You wouldn’t know.

Or worse:

The server responds with 500 Internal Server Error.
But in reality, only 2 files failed, and the rest were deleted successfully.

Both situations are ambiguous and inefficient. With 207, the server can clearly report:

File A → Deleted (200 OK)
File B → Permission Denied (403 Forbidden)
File C → Not Found (404 Not Found)

All inside one structured XML or JSON body.

Why Is 207 Important?

The 207 Multi-Status status code is critical for APIs and systems that manage collections of resources. Here’s why:

Granular feedback: Gives detailed information on success or failure for each resource involved.
Better error handling: Clients don’t have to guess or handle ambiguous responses.
Efficient communication: One HTTP request and response can handle multiple operations at once.
Supports batch operations: Enables bulk processing which is fundamental in content management, cloud storage, and file synchronization.

Without 207, APIs would have to rely on multiple requests or complex workarounds to convey the status of multi-resource operations.

Key Use Cases for 207 Status Code

Where is 207 used most often?

WebDAV file operations (move, copy, delete, upload multiple files).
Batch API operations (e.g., multiple requests bundled into one).
Partial successes in workflows (some steps succeed, others fail).
Bulk updates in databases or APIs.

Why Use 207 Multi-Status? The Benefits

The alternative to a 207 is much worse:

The "All or Nothing" Approach: The server could fail the entire operation if any single item fails. This is a poor user experience why should one failed file prevent the deletion of 99 others?
The "Silent Partial Failure" Approach: The server could return a generic 200 OK even if some items failed, leaving the client to figure out what worked and what didn't. This is unreliable and dangerous.
The "100 Requests" Approach: The client could send 100 separate requests. This is terribly inefficient, overwhelming the server with network overhead, and it's difficult to manage atomicity.

The 207 provides a perfect middle ground:

Efficiency: Multiple outcomes in one response save bandwidth.
Atomicity: The server can choose to process the items atomically if needed.
Precision: The client gets a clear, itemized report of exactly what succeeded and what failed.
Robustness: Partial success is an acceptable and communicated outcome.
Clarity: Developers know exactly which operations failed.
Granularity: Helps with debugging and error handling.
Consistency: Avoids misleading single-code responses.

Common Use Cases for 207 Multi-Status

Though most prominent in WebDAV, use cases extend into any API or system that performs batch operations:

Batch delete or update in file storage APIs
Bulk metadata updates on resources
Synchronizing large sets of files between client and server
Batch processing in RESTful APIs for enabling atomic multi-resource transactions

If you’re designing an API that supports batch operations, considering the use of 207 Multi-Status can improve client-server communication.

Real-World Use Cases Beyond WebDAV

While born from WebDAV, the concept of a multi-status response is incredibly useful in modern API design for any bulk operation:

Bulk DELETEs: "Delete all these posts." Some might succeed, others might fail due to permissions or because they're already gone.
Bulk POSTs/Creates: "Create these 10 users." Some usernames might already be taken.
Bulk UPDATES: "Update the prices of these products." Some product IDs might be invalid.
Validation Endpoints: "Validate these 50 data records." Each record can have its own validation errors.

How Clients Handle 207 Responses

When a client receives a 207 Multi-Status response, it should:

Parse the response body (usually XML or JSON) to extract individual statuses.
Process each resource result independently, handling errors with precision.
Provide meaningful feedback to the end user where applicable.
Optionally retry failed operations based on the status details.

This nuanced handling allows clients to maintain synchronization and integrity across complex operations. This means developers must handle 207 explicitly in their code.

The Modern JSON Alternative

While 207 is tied to XML, the pattern it establishes is timeless. Many modern APIs implement the concept of a multi-status response using JSON instead of XML, often with a 200 OK status code.

A modernized version of the previous example might look like this:

HTTP/1.1 200 OKContent-Type: application/json
{
  "results": [
    {
      "href": "/files/report.pdf",
      "status": 200,
      "message": "OK"
    },
    {
      "href": "/files/archive.zip",
      "status": 423,
      "message": "Locked"
    },
    {
      "href": "/files/photo.jpg",
      "status": 404,
      "message": "Not Found"
    }
  ]
}

This approach is often more palatable to developers working in a JSON-centric world. However, using the official 207 status code is more semantically correct if you're sticking strictly to HTTP standards.

How APIs Use 207 Responses

Modern APIs can adopt 207 Multi-Status in batch operations:

REST APIs: Return multi-status results when processing bulk user updates.
GraphQL APIs: Bundle multiple field responses, each with success/failure info.
File storage APIs: Report per-file upload results.

Using 207 makes APIs more transparent and avoids confusion.

Testing 207 Responses with Apidog

Testing an API that returns 207 is more complex than testing a simple endpoint. You need to validate the structure of the XML and the status codes for each individual item. Handling a 207 Multi-Status response can be tricky because of its complex payload. Apidog is an ideal tool for this task.

With Apidog, you can:

Craft Bulk Requests: Easily set up a request that will trigger a bulk operation on the server.
Parse XML Responses: Apidog can display the XML response in a structured, easy-to-read format, allowing you to quickly see each <response> block.
Write Advanced Assertions: You can write test scripts in Apidog that:

Assert the overall status code is 207.
Loop through each item in the <multistatus> response.
Check that specific resources have the expected individual status codes (e.g., "assert that /files/photo.jpg has a 404 status").

4. Handle Errors: Test how your client application logic should handle the mixed bag of successes and failures contained in a 207 response.

button

This level of testing is crucial for building reliable clients that can react intelligently to partial success. Download Apidog for free today and simplify your experience with multi-status and other HTTP codes. Unlike Swagger or Postman, Apidog goes beyond testing it’s about designing and documenting real-world workflows.

Common Mistakes with 207

Returning vague errors → defeats the purpose of 207.
Mixing formats → stick with XML (WebDAV) or JSON (modern APIs).
Not documenting usage → clients won’t know how to parse the response.

Implementing 207 Multi-Status: Best Practices

If you’re a developer building APIs that use 207, keep these points in mind:

Follow WebDAV specifications for response formatting (if applicable).
Use clear and consistent status codes for each resource response.
Ensure response bodies are well-formed XML or JSON for easy parsing.
Document your batch operation endpoints and the structure of 207 responses clearly.
Use tools like Apidog to test batch endpoints and inspect 207 responses in detail.

Challenges and Considerations

Client Complexity: The client must be "207-aware." It can't just check the main status code and be done; it must parse the response body and handle each result individually. This adds complexity to the client-side code.
Atomicity: Should the entire operation fail if one item fails, or should it be partial? The server design must decide this. A 207 response implies a partial, "best-effort" approach.
Performance: Processing a large number of items in a single request can be taxing on the server. It's important to implement timeouts and limits.

Despite these, when batch processing is required, 207 is well worth adopting.

Conclusion: Why the 207 Multi-Status Status Code Should Be in Your Toolbox

The HTTP 207 Multi-Status code is an essential tool when working with multi-resource operations, batch processing, and complex APIs. It empowers servers to provide detailed, structured feedback about individual outcomes in a single response something that simpler status codes cannot handle well. While its XML-based WebDAV roots can feel dated, the underlying pattern is more relevant than ever in a world of complex web applications that need to manage collections of data efficiently. The 207 Multi-Status code may not show up in everyday browsing, but for developers working with WebDAV, batch operations, or APIs that return multiple results, it’s a game changer.

It allows a server to communicate multiple outcomes clearly and efficiently within a single response something a simple 200 OK or 500 Internal Server Error can’t handle. For most common API needs, you'll likely use simpler status codes. But for the specific niche of bulk operations, understanding 207 provides a blueprint for how to do it right. It teaches the importance of providing clients with granular feedback, enabling them to build resilient and user-friendly applications that can handle the complexities of partial success.

If you’re designing or testing APIs that might need multi-status behavior, don’t struggle with ad-hoc mock servers, the 207 status code is your friend. And when you're ready to build or integrate with APIs that require this level of sophistication, a tool like Apidog provides the necessary features to debug, test, and validate these complex interactions, ensuring your application handles every single status in a multi-status response correctly. It’s the perfect tool for testing APIs that utilize complex HTTP status codes like 207 Multi-Status, helping you build better APIs faster. You’ll be able to design, mock, and test 207 Multi-Status responses effortlessly, while also generating clean API documentation for your team.

In a world where APIs are increasingly complex and interconnected, understanding and leveraging codes like 207 Multi-Status can save time, reduce errors, and improve developer experience.

button