## TL;DR
Archived tickets are read-only by design: Zendesk freezes them after a set period, and every write API call against them fails with "archived ticket cannot be updated." Never attempt the update anyway. Check the archived flag before writing, and when an archived ticket needs action, create a follow-up ticket linked to the original instead of mutating history.

## The query

```text
zendesk "archived ticket cannot be updated" api error
```

## Use this when

- PUT or POST calls to a ticket fail with the archived error
- An agent needs to add a note to an old ticket
- You are building Zendesk write integrations
- Backfill scripts hit archived tickets

## Not for

- Changing how long before tickets archive
- Restoring deleted tickets
- Zendesk data retention policy
- Updating active tickets

## Steps

### 1. Read the error as a state problem, not a permissions problem

"Archived ticket cannot be updated" means the ticket passed the archive threshold, not that your credentials lack scope. Retrying with more permissions will never work. Reframe: this ticket is history now.

Expected output: no wasted retries on permission fixes.

### 2. Check the archived flag before every write

Read the ticket first and inspect its archived status. Gate all update paths on it: if archived, route to the follow-up pattern instead of attempting the write. This one check prevents the whole error class.

Expected output: write paths branch on archived state before calling the API.

### 3. Create a follow-up ticket linked to the original

When action is needed, open a new ticket with a link or reference to the archived one, and copy the essential context into it. The new ticket is fully writable and keeps the audit trail intact. Archiving is why this pattern exists.

Expected output: actionable follow-up ticket linked to the archived original.

### 4. Handle archive races in long-running jobs

A ticket can archive mid-run: it was active when your job listed it, archived by the time your update lands. Treat this error as expected in batch jobs and route those items to the follow-up path, not to a failure queue.

Expected output: batch jobs degrade to follow-ups instead of failing.

### 5. Surface the archive state to agents and users

When an agent tries to update an archived ticket, say plainly: "This ticket is archived and read-only; I created follow-up ticket [id] instead." Silent follow-up creation confuses; the message makes it legible.

Expected output: clear messaging on every archived-write attempt.

## Template: the checklist

```text
Archived ticket writes:
[ ] Archived flag checked before every write call
[ ] Follow-up ticket created and linked when action is needed
[ ] Batch jobs treat the error as expected, not fatal
[ ] Agents told plainly when a ticket is archived
[ ] Essential context copied into the follow-up
```

## Variant phrasings

### cannot update archived zendesk ticket

Steps 1 and 3. It is read-only; make a follow-up.

### archived ticket update api fails

Steps 2 and 4. Check first, handle races in batches.

### reopen archived ticket via api

Step 3. You cannot reopen it; the follow-up ticket is the reopen.

## Why it happens

Zendesk archives closed tickets after a retention window to keep the active dataset fast, and archived tickets become immutable records. The API enforces immutability with this error. It feels like a bug when you hit it mid-automation, but it is the archive doing its job: old tickets are history, and history does not get edited.

## Edge cases

- Tickets approaching the archive window: if your workflow touches tickets near the threshold, expect races and pre-check.
- Side conversations on archived tickets: these fail too. Same follow-up pattern.
- Search returning archived tickets: filter them out of write-target lists at query time.
- Compliance needs to annotate old tickets: the follow-up ticket with a link satisfies most audit needs without mutating the record.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_CICKFrWfLMB9wmysEHaMhw