HTTP 423 vs 409 — Locked vs Conflict Status Code Comparison
http 423 vs 409: 423 Locked specifically signals an explicit lock on the resource, while 409 Conflict is a generic state conflict. WebDAV, file editing, and admin lock examples.
Quick Cheat Sheet
| Aspect | 423 Locked | 409 Conflict |
|---|---|---|
| RFC | 4918 (WebDAV) | 9110 |
| Semantic | Explicit lock held on resource | Generic state conflict |
| Lock semantics required? | Yes — implies a lock owner | No |
| HTTP common usage | Rare outside WebDAV | Very common |
Origins and Scope
423 Locked comes from WebDAV (RFC 4918 § 11.3) and was designed for systems that have an explicit lock concept — a resource is checked out, exclusively reserved, or otherwise blocked from modification by some agent. It implies that an unlock operation exists.
409 Conflict (RFC 9110 § 15.5.10) is the general-purpose "the request can't be completed because the resource is in an incompatible state" code. No locking semantics implied.
When 423 Is Appropriate
Use 423 when a lock — not just a state — is the cause:
- A user account is admin-locked / soft-suspended, but the resource is otherwise valid
- A document is checked out exclusively in a versioned filesystem (SVN, Perforce, WebDAV)
- An admin has frozen a resource for moderation review
- Two-phase commit / saga step has reserved the resource
The response should typically include enough information for the client to know who/why holds the lock, and ideally how to request unlock.
When 409 Is Appropriate
Use 409 for everything else where the operation can't proceed because of a state clash:
- Trying to merge a PR with conflicts
- Creating a resource that already exists (duplicate key)
- Deleting a parent that still has children
- Modifying an order that's already shipped
Real-World Adoption
Most modern REST APIs never use 423 because they don't model explicit locks at the protocol level. GitHub, Stripe, AWS — all use 409 (or 412 for ETag mismatches) and avoid 423 entirely.
You'll see 423 mostly in:
- WebDAV servers (Nextcloud, Apache mod_dav)
- Office productivity APIs (SharePoint, Dropbox lock APIs)
- Some banking/insurance systems with explicit case-locking
Practical Recommendation
If your API doesn't have explicit lock semantics, just use 409. 423 communicates additional information (a lock exists, can be released) that you may not actually support. Misusing 423 confuses clients that expect to find an unlock mechanism.
If you do have locks, 423 is the correct, precise choice — and you should pair it with a documented unlock endpoint and a way to inspect lock owners.
Real-World Use Case
A document collaboration app where admins can put a doc in 'frozen for review' mode should return 423 on edit attempts, with a JSON body indicating the freezer's user ID and the unlock workflow. For a PR-merge endpoint where the branch has merge conflicts, return 409 — there's no lock involved, just an irreconcilable state.
Look Up Any Status Code
Related Comparisons
HTTP 409 vs 412 — Conflict vs Precondition Failed Comparison
http 409 vs 412: both signal state conflicts, but Conflict is for resource-level clashes while Precondition Failed is triggered by If-Match / If-None-Match headers. ETag examples included.
HTTP 401 vs 403 — Unauthorized vs Forbidden Status Code Comparison
Confused about http 401 vs 403? Learn the exact difference between Unauthorized and Forbidden, when each is returned, and how Express, Stripe, and GitHub APIs use them.
HTTP 400 vs 422 — Bad Request vs Unprocessable Entity Comparison
http 400 vs 422 explained: when to return Bad Request for malformed syntax versus Unprocessable Entity for valid syntax that fails business validation. Includes API examples.
HTTP 404 vs 410 — Not Found vs Gone Status Code Comparison
http 404 vs 410: Not Found means the resource may exist later, while Gone signals permanent deletion. Learn how Google indexing, CDN caching, and SEO are affected.