No. HTTP 207 is not cached by default. The response reflects the outcome of a specific multi-operation request and contains sub-status codes that vary per resource, so caching would not be appropriate.

HTTP 207 Multi-Status

Q: What does HTTP 207 Multi-Status mean?

HTTP 207 Multi-Status is a WebDAV status code (RFC 4918) that indicates a request performed multiple operations and each operation has its own status code. The response body is XML containing a multistatus element with individual response elements, each with their own href and status child elements.

Q: When should I use 207 outside of WebDAV?

207 can be used for any bulk operation API where a single request performs multiple independent operations that can individually succeed or fail. For example, a bulk user creation endpoint or batch email send. The caller needs to inspect each sub-response to know which operations succeeded.

Q: What does a 207 response body look like?

A 207 response body is XML with a multistatus root element containing one response element per operation. Each response element has an href (the resource URL), a status (like HTTP/1.1 200 OK or HTTP/1.1 404 Not Found), and optionally a propstat element for WebDAV property results.

HTTP 207 Multi-Status is a WebDAV extension code defined in RFC 4918 that allows a single HTTP response to convey multiple status codes for multiple independent operations. Rather than returning a single outcome, 207 delivers an XML body containing per-resource results — each with its own URL, status, and optional property information. It is the standard response format for WebDAV methods like PROPFIND, PROPPATCH, COPY, MOVE, LOCK, and DELETE when those operations affect multiple resources simultaneously.

Quick reference

Code	207
Name	Multi-Status
Category	2xx Success
Specification	RFC 4918 §11.1
IANA status	Assigned
Cacheable	No — not cached by default
Response body	Required — XML multistatus document
Primary use	WebDAV bulk operations; batch API responses

What HTTP 207 means

The 207 status code tells the client: "The request was processed, but results differ per resource — read the body." The outer HTTP status is 207 regardless of whether individual sub-operations succeeded or failed. A 207 response can contain a mix of 200, 201, 204, 403, 404, and 423 outcomes within the same XML body.

RFC 4918 specifies the body as a DAV:multistatus XML document. Each DAV:response element within it identifies one resource via DAV:href and its outcome via either DAV:status (a full HTTP status line) or DAV:propstat (property-level results). A single response element can have multiple propstat children when different properties have different statuses.

The 207 code is in the 2xx range, which means the HTTP request itself was understood and processed — the server is not reporting a request-level failure. Individual resource-level failures are reported inside the XML body, not through the outer HTTP status code.

The XML response body

A 207 response body always has Content-Type: application/xml or text/xml. The structure is a DAV:multistatus root element containing one or more DAV:response elements. The WebDAV namespace is declared as xmlns:D="DAV:".

Example: PROPFIND request on a collection returning property results for two resources:

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>https://dav.example.com/files/report.pdf</D:href>
    <D:propstat>
      <D:prop>
        <D:displayname>report.pdf</D:displayname>
        <D:getcontentlength>204800</D:getcontentlength>
        <D:getlastmodified>Fri, 25 Apr 2026 09:00:00 GMT</D:getlastmodified>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:response>
    <D:href>https://dav.example.com/files/archive/</D:href>
    <D:propstat>
      <D:prop>
        <D:displayname>archive</D:displayname>
      </D:prop>
      <D:status>HTTP/1.1 403 Forbidden</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>

The first resource returned property data successfully (200). The second resource returned 403 — properties were not accessible. The outer response is 207 in both cases. The client must parse each D:response element to determine what succeeded.

WebDAV methods that use 207

PROPFIND

PROPFIND retrieves properties from one or more resources. When applied to a collection with Depth: 1 or Depth: infinity, it returns a 207 with a response element for the collection itself and each member resource. This is how WebDAV clients (file managers, calendar apps, CardDAV clients) enumerate resources and their metadata.

PROPPATCH

PROPPATCH sets or removes properties on a resource. If the request attempts to set multiple properties and some succeed while others fail (for example, setting a read-only property), the server returns 207 with per-property status codes inside propstat elements. The entire PROPPATCH is atomic per RFC 4918 — if any property modification fails, all modifications must be rolled back and each property is reported with the same failure status.

COPY and MOVE on collections

When COPY or MOVE operates on a collection, the server attempts the operation on the collection and each member. If any member-level error occurs, the server reports 207 with per-resource statuses. A successful COPY or MOVE on the entire collection returns 201 or 204 — 207 is only used when partial errors occur.

DELETE on collections

A DELETE on a collection that encounters member-level errors (such as a locked resource inside the collection) returns 207. RFC 4918 §9.6.1 specifies that if an error prevents deletion of a collection member, the server must not delete the parent collection and must report the conflict in a 207 body.

LOCK

When a LOCK operation on a collection encounters resources it cannot lock, it returns 207 with per-resource status codes. Resources that were successfully locked appear with 200; resources that failed appear with 409 or 423.

Using 207 outside of WebDAV

RFC 4918 defines 207 in the context of WebDAV, but nothing prevents REST APIs from using it for bulk operations where results differ per item. The pattern is common in APIs that accept a batch of resources to create, update, or delete in a single request.

Example use cases outside WebDAV: a bulk user creation endpoint that processes 50 users and reports which succeeded and which failed validation; an email send API that attempts delivery to multiple addresses and reports per-address results; a batch document index API that processes records independently.

When using 207 in a non-WebDAV REST API, the response body is typically JSON rather than XML. The structure maps conceptually to the XML model: an array of result objects, each with an identifier (ID or URL), a status code, and an optional message. There is no formal RFC for JSON 207 bodies, so the schema is API-defined. Document it clearly in your API specification.

The alternative to 207 for batch APIs is returning 200 with a body that contains a mixture of successes and errors. The advantage of 207 is that the HTTP status code itself signals "mixed results" to intermediaries and clients before they parse the body. The disadvantage is that 207 is less universally understood than 200, and some clients treat any non-200 2xx code as unexpected.

207 vs related status codes

Code	Name	Use when
200	OK	Single operation succeeded; or bulk operation where all items succeed uniformly
207	Multi-Status	Multiple operations with mixed per-resource outcomes; WebDAV collection operations
208	Already Reported	Member of a DAV binding already reported in earlier 207 response element
202	Accepted	Bulk operation accepted but not yet processed; processing is asynchronous
400	Bad Request	The request itself was malformed — not applicable to per-resource errors within a valid request

FAQ

What does HTTP 207 Multi-Status mean?

HTTP 207 means the server processed a request involving multiple operations and is returning individual status codes for each operation inside an XML body. It is defined in RFC 4918 for WebDAV but can be used in any API that processes batch operations with mixed outcomes.

When should I use 207 outside of WebDAV?

Use 207 when a single request performs multiple independent operations and the client needs to know which succeeded and which failed. If all operations must succeed or fail together (a transaction), use a single success or error code instead. 207 is appropriate only when partial success is a valid outcome.

What does a 207 response body look like?

In WebDAV, a 207 body is XML with a DAV:multistatus root containing DAV:response elements, each with an href and status. In non-WebDAV REST APIs, the body is typically JSON — an array of result objects each containing an identifier, a status code, and an optional error message.

Is 207 cacheable?

No. HTTP 207 is not cached by default. The response reflects the outcomes of a specific multi-operation request and cannot be meaningfully reused.

Related resources

On this site: HTTP 200 OK · HTTP 202 Accepted · HTTP 208 Already Reported · All 2xx success codes

Standards: RFC 4918 §11.1 — HTTP Extensions for Web Distributed Authoring and Versioning · IANA HTTP Status Code Registry · MDN Web Docs: 207