TL;DR: Refresh the agent's posting cache and re-resolve the requisition before writing. The 404 means the posting ID the agent is using no longer exists in Lever - usually because the req was archived, closed, or reposted under a new ID overnight. Treat a 404 on a posting as a signal to re-list postings, not to retry the same call.

```text
404 "posting not found"
```

1. List current postings from the Lever API and check whether the ID the agent used is still there. Expected: the ID is missing from the live list.
2. Find what happened to the req: search Lever for the job title and check whether it was archived, closed, or reposted under a new ID. Expected: you can name the req's current state and its replacement ID if it was reposted.
3. Update the agent's posting cache or mapping with the current ID (or mark the req closed if it was archived with no replacement). Expected: the cache no longer references the dead ID.
4. Decide where the candidate should go: if the req was reposted, write to the new posting; if it was archived, stop and surface the candidate to a recruiter instead of attaching them to a random open req. Expected: a deliberate routing decision, not a silent default.
5. Re-run the failed write against the resolved posting. Expected: a 200 or 201 and the candidate lands on the right requisition.

## Use this when
- Lever returns 404 posting not found on writes that worked yesterday
- Reqs get archived, closed, or reposted on a regular cycle
- The agent caches posting IDs for longer than a day

## Not for this skill when
- The 404 is on a candidate or opportunity endpoint (different resource, different fix)
- The error is 403 (the posting exists but the key's user cannot see it)
- The posting ID is one the agent invented or truncated - check the ID construction first

## Variant phrasings
- Lever API posting not found after archive
- Lever 404 on requisition write
- agent writing to stale Lever posting ID

## Why it happens
Lever posting IDs are not stable across a req's lifecycle: archiving removes the posting, and reposting creates a new one with a new ID. An agent holding yesterday's ID is writing to a resource that no longer exists, and Lever correctly answers 404. The cache is the bug, not the API.

## Edge cases
- Auto-archived reqs (Lever can archive postings on a schedule) cause 404s with no human action; refresh posting lists on every sync run, not just at deploy time.
- Do not silently reassign the candidate to whatever posting is open; attaching someone to the wrong req is worse than a failed write.
- If the agent creates postings as well as writing to them, check whether it is racing its own archive job.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_CgzH3-g_3KO_faPzFPDEig