207 Multi-Status 2xx

What does 207 mean?

A 207 Multi-Status response means a single request resulted in multiple independent operations, each with its own outcome — and rather than collapsing all those outcomes into one overall status code, the response body contains a structured list reporting the status of each individual operation separately. The "207" itself just signals "look inside the body for the real per-item results" — it's a wrapper, not a verdict.

This solves a real problem: if a single request triggers operations on, say, ten different resources, and seven succeed while three fail for different reasons (one's a 404, one's a 403, one's a 409), no single status code (200? 207's whole reason for existing is that 200 wouldn't be accurate, and any single error code would misrepresent the seven that succeeded) can represent that outcome — 207 sidesteps this by saying "the envelope succeeded; here's what happened to each thing inside it."

How a 207 behaves

• The response body contains a structured list of per-item results, each with its own status code, in WebDAV's case using XML (<d:multistatus> containing multiple <d:response> elements, each with its own <d:status>)
• 207 itself doesn't indicate success or failure of the underlying operations — it indicates "the request was processed and here are the individual results," which could be all successes, all failures, or a mix
• It's not cacheable in any straightforward sense, given its compound nature
• The client must parse the body to know what actually happened — unlike most status codes, where the code itself largely tells you the outcome, 207 requires inspecting the body for any meaningful information about success/failure

Common scenarios

If you're building the API or website:

• A batch/bulk operation endpoint processes multiple items (e.g., "delete these 10 files," "update these 5 records") where each item can succeed or fail independently — 207 with a structured per-item result list communicates this accurately
• A WebDAV PROPFIND operation retrieves properties for multiple resources (e.g., everything in a directory) — 207 reports the properties (or errors) for each resource individually

If you're calling an API:

• After a batch operation returns 207, parse the response body to determine which individual items succeeded and which failed (and why) — don't assume 207 means "everything worked" or "everything failed"
• Handle partial success gracefully in your application logic — a batch of 10 items might have 8 successes and 2 failures, and your code needs to act on both groups appropriately

If you're a website visitor:

• Not applicable directly — 207 is an API/protocol-level detail for batch operations

207 vs single status codes

Real-world examples

WebDAV's PROPFIND method — used to retrieve metadata/properties for one or many resources, potentially an entire directory tree — commonly returns 207, with the body listing each resource and its properties (or an error if that specific resource's properties couldn't be retrieved). Some modern bulk/batch REST APIs use 207 (or a custom JSON structure conveying the same idea — an array of per-item results, each with its own status) for operations like "process these N items," where partial success is a normal, expected outcome rather than an edge case.

SEO implications

None — 207 is exclusively relevant to batch/multi-resource API operations.

FAQ

Does 207 mean my request succeeded or failed?

Neither, exactly — 207 means "your request was processed, and here are the individual results for each part of it," which you need to inspect in the response body. The overall request was handled, but individual operations within it could have succeeded or failed independently.

How do I know if any items in a 207 response failed?

You have to parse the response body — each item/resource in the multi-status response has its own status indicator. There's no shortcut at the HTTP-status-code level; 207 doesn't tell you "all good" or "some failed" by itself.

Is 207 only used in WebDAV?

Its origins are in WebDAV (RFC 4918), where it's used with XML-structured responses. The concept — a single response representing multiple independent outcomes — has been adopted by some modern batch/bulk REST APIs too, sometimes using 207 directly, sometimes using a custom response structure conveying the same idea without literally returning HTTP status 207.

What's the relationship between 207 and 422?

They're not directly related in meaning, but both originate from WebDAV's relatively detailed approach to multi-resource operations — 422 is about a single operation's data failing validation, while 207 is about reporting outcomes across multiple operations within one request.

Can a 207 response contain a mix of 2xx and 4xx/5xx results for different items?

Yes — that's precisely the scenario 207 is designed for. Different items in the same batch can have entirely different individual outcomes (some 200s, some 404s, some 403s, etc.), all reported within the single 207 response's body.

Fun fact

207 is one of the few status codes that's explicitly "meta" by design — its entire job is to say "the real information is one level down, in the body, where multiple other status-code-like values live" — making it a kind of status code about status codes, a structural pattern that became increasingly relevant as APIs moved toward supporting bulk operations on multiple resources within a single request.