Letter lock error fields on updateLetter
Summary
When updateLetter rejects a content change because the letter is locked (for example after it was marked Completed under strict letter mode), the LetterResponsePayload now includes optional structured fields alongside the existing error string.
Partners can use these fields to detect lock rejections without parsing free-text messages.
New LetterResponsePayload fields
| Field | Type | When present |
|---|---|---|
reason | LetterResponseErrorReason | Lock rejection (LETTER_LOCKED) |
lockedAt | DateTime | Lock rejection |
lockedReason | LetterLockReason | Lock rejection (COMPLETED today) |
suggestedAction | LetterLockSuggestedAction | Lock rejection (CREATE_DUPLICATE) |
Enum values are forward-compatible: clients should treat unknown enum values as opaque and continue to read error.
Compatibility
- The existing
errorstring is unchanged and remains the human-readable message. - Successful
updateLetterresponses are unchanged; lock fields are omitted or null. - Public
Letterreads do not expose lock metadata in this release.
Integration guidance
- Refresh your GraphQL schema snapshot and regenerate clients.
- On
updateLetter, whenreasonisLETTER_LOCKED, do not retry the same content update. - Use
suggestedAction: CREATE_DUPLICATEas the recommended recovery path: create a new letter with the desired content instead of mutating the locked record. - Handle unknown future
lockedReasonorsuggestedActionenum values defensively.
See also
- API reference:
updateLetter - API object:
LetterResponsePayload