Quick answer: A 423 Locked means the target resource is currently held under a lock, usually by another client or process, so your write cannot proceed. Find the lock holder and its timeout in the response body, then either wait for release, send the correct lock token if you hold the lock, or ask an administrator to clear a stale lock. Retrying the same request without a change just returns 423 again.

What the status code means

The 423 status comes from WebDAV and describes a resource that is locked. A lock grants one client the right to modify a resource while blocking others, a pattern used in collaborative editing and guarded uploads. The request reaches the right resource and the caller may be authorized, but the lock blocks the write until it is released or the matching token is presented.

This differs from a 409 Conflict. A 409 reports a state mismatch, such as a stale version field, often resolved by re-reading and re-applying. A 423 is about an active lock, so the path is the lock and its token rather than the version.

Why it happens

The common cause is a second client writing to a resource the first client locked. WebDAV clients issue a LOCK request, receive a token, make their change, and release the lock; if your request arrives in that window without the token, the server answers 423. Background jobs collide the same way when they target one path.

A lock can also outlive the client that created it. If the holder crashes before releasing, it stays until its timeout expires or an administrator removes it. A missing or wrong If header produces the same status even when you are the legitimate holder.

How to inspect the response

Read the response body, which usually carries an XML error describing the lock, including the owner and token reference. Note whether the lock is active and its timeout rather than guessing how long to wait. Check whether your own client holds a lock and whether the request includes the If header.

Determine whether every write fails or only one resource fails. A single locked resource points to one holder; a broad failure suggests a job that locks many paths or a cleanup process that never releases.

Symptoms, causes, and fixes

Symptom Likely cause Fix
423 on a write during editing Another client holds the lock Wait and retry after release
423 even though you locked it Missing or wrong If header Send the lock token
Lock never clears Holder crashed before release Wait for timeout or admin removal
Background jobs collide Two jobs target one path Serialize or lock per resource
423 after a reconnect Token lost on the new session Re-lock or re-read the token

Fixing the client

If you are not the holder, do not spin on the request. Wait for release, using the timeout as your bound, and then retry. If you hold the lock, include the token in an If header on the write, and pair LOCK with a release in a finally block so a failure does not leave the resource held.

For automated jobs, serialize writes to the same resource or use a short lock window so two workers never overlap. A stale lock can be removed by an administrator or cleared at its timeout; force-writing around it is not possible.

Verify with a real request

After the change, send the write and assert the status is 200 or 204 rather than 423. A scenario can run the request as an ordered step, assert the status and headers, and keep the evidence. For offline work, a local mock can return 423 without a token and 204 once the correct If header is present while recording requests.

The mock models your client behavior, not the real server's rules, so the final check is still a live request. Powerduck sends these requests through the local main process without browser CORS limits, runs status and header assertions at each step, and can record mock traffic. For more, see the API debugging guide hub.

Honest limits

A green scenario proves that one client now presents a valid token or waits for release; it does not prove a real server clears a stale lock on time, and a mock cannot reproduce a collaborator's session. Keep the live check as the source of truth, and if a verification script is missing, mark that step unverified rather than passed.

Frequently asked questions

What is the difference between 423 and 409? A 423 is an active lock blocking the write; a 409 is a version conflict you resolve by re-reading and re-applying.

How long does a lock last? The server sets a timeout, shown in the response, and a crashed holder's lock clears there or through an administrator.

The bottom line

A 423 is a resource held under a lock, not a malformed request. Identify the holder and timeout, present the correct token if the lock is yours, or wait and retry once it releases, and pair every LOCK with a release. Confirm the fix with a live write, and the 423 stops coming back.