## TL;DR
EDIT_LOCK_NOT_LOCKED means your template update arrived without a valid edit lock. DocuSign locks a template while it is being edited so two writers cannot clobber each other; the lock expires, and an update sent after expiry - or from a session that never held the lock - is rejected. Find out who holds the lock, release the stale one, re-acquire it, and retry the update immediately. If two systems edit the same template, serialize them; the lock is doing its job.

## The query
```text
DocuSign 'EDIT_LOCK_NOT_LOCKED' when updating a template  -  how to fix
```

## Use this when
- Updating a template via API returns EDIT_LOCK_NOT_LOCKED
- A template edited in the web console cannot be updated by your integration right after
- Two services or teammates edit the same template and updates intermittently fail

## Not for
- Envelope (not template) update failures - envelopes have their own lock resource
- Permission errors on templates you do not own - those are authorization failures, not lock failures
- Template creation failures - locks only exist on templates that already exist

## Steps
### 1. Inspect who holds the lock
Fetch the template with its lock information. The lock record names the holder and the lock timestamp. If the holder is a teammate's browser session or a crashed script, the lock is stale and safe to release. If the holder is an active editor, wait for them to finish instead of forcing it.
Expected output: a lock record showing the holder identity and when the lock was taken.

### 2. Release the stale lock
Delete the lock on the template through the eSignature API's template lock resource. This is the supported way to clear a lock left behind by a crashed session or a closed browser tab. Do this once, deliberately - not in a retry loop.
```bash
curl -X DELETE "$BASE/templates/[TEMPLATE_ID]/lock" -H "your auth header
```
Expected output: a 200 response and a subsequent lock-status read showing no active lock.

### 3. Re-acquire the lock and retry the update in the same session
Take a fresh lock, perform your template update immediately, then release it. The window between acquiring the lock and sending the update should be seconds, not minutes: long gaps let the lock expire and bring back the same error.
Expected output: the template update returns 200 and the template shows your changes.

### 4. Serialize template writers
If two integrations edit the same template, put a mutex around the lock-acquire, update, lock-release sequence in your own code, or designate one writer. Competing writers will keep expiring each other's locks no matter how fast each one is.
Expected output: no more intermittent EDIT_LOCK_NOT_LOCKED once a single writer owns the sequence.

## Tool compatibility
DocuSign eSignature REST API v2.1 template resources, plus the web console for inspecting locks manually. Same behavior on demo and production.

## Variant phrasings
- DocuSign EDIT_LOCK_NOT_LOCKED updating template
- template update failed edit lock not locked DocuSign
- DocuSign template locked by another user API update
- release template edit lock DocuSign API

## Why it happens
Templates are shared mutable objects: the web console, the API, and bulk operations can all edit one. The edit lock is a cooperative mutex that prevents lost updates. EDIT_LOCK_NOT_LOCKED is the API telling you the mutex was not held when you wrote - either it expired while you prepared the update, or another session holds it. Rejecting the write is correct; silently merging template edits would corrupt signing workflows.

## Edge cases / pitfalls
- Browser tabs left open on the template editor hold locks - closing the tab releases them.
- The lock has a timeout; a slow multi-step update script should refresh or re-acquire the lock between steps.
- Service-account integrations should use their own user identity so lock holders are identifiable in the audit log.
- Deleting a lock held by an active human editor discards their unsaved work - check the holder first.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3R8yvnzLK29X-NVdg2Uh4g