TL;DR: Regenerate the Lever API key as a Lever user who can actually see that requisition, or get the key's user added to it. A Lever API key inherits the permissions of the user who created it, so a key minted by someone without access to a confidential posting gets 403 on exactly that posting while working fine everywhere else. The fix is on the user side, not in the request.

```text
403 "You do not have access to this resource"
```

1. Find which Lever user owns the API key the agent is using (check the key's label in Lever settings). Expected: you can name the user the key belongs to.
2. Log into Lever as that user and open the requisition; confirm it is invisible or read-only for them. Expected: the same 403 the agent sees is reproducible in the UI.
3. Check whether the posting is confidential or restricted to a specific team. Expected: you find the access setting that excludes the key's user.
4. Either add the key's user to the posting's access list, or generate a fresh API key as a user (often a super admin or the hiring manager) who already has access. Expected: the chosen user can open the posting in the UI without restriction.
5. Point the agent at the new key and retry the exact call that 403'd. Expected: a 200 or 201 and the candidate or note appears on the requisition.

## Use this when
- Lever returns 403 on one specific requisition while other postings work with the same key
- The posting was recently made confidential or moved teams
- The agent's key was minted by a former employee or a limited-role user

## Not for this skill when
- Every Lever call 403s (the key itself is wrong or revoked - check auth first)
- The error is 404 posting not found (the posting is archived, not access-restricted)
- The error is 401 invalid token (credential problem, not a permissions problem)

## Variant phrasings
- Lever API 403 forbidden on requisition
- Lever API key permissions for confidential postings
- agent gets access denied posting to Lever requisition

## Why it happens
Lever scopes every API key to the user who generated it - the key is that user in API form. Confidential postings and team-restricted requisitions are invisible to users outside the access list, so the key inherits that invisibility. The API call is well-formed; the identity behind it just is not allowed in.

## Edge cases
- Keys minted by deactivated users keep failing even after you fix posting access; regenerate the key under an active user.
- Super admin keys see everything, which fixes the 403 but widens what the agent can touch; prefer a key from a user with access to only the postings the agent needs.
- Posting access can change when a req is transferred between teams; re-check access after re-orgs, not just at setup.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_x-CPrM83kNtI7WjIz7ec5w