TL;DR: Find out which environment variable the agent's HTTP client actually reads, and put the Lever API key in that exact variable in the agent's runtime environment. A 401 invalid token with a known-good key almost always means the client is sending an empty or wrong value because it is reading a different variable than the one you populated. Compare the two names character by character.

```text
401 "invalid token"
```

1. Read the agent's code or config to find the exact environment variable name its Lever client reads. Expected: you have the precise variable name the client looks up.
2. List the variables actually set in the agent's runtime environment (the container or process env, not your local shell) and check whether that name is present. Expected: you see the mismatch - the key lives in a similarly-named variable the client never reads.
3. Move the key into the variable the client reads (or change the client config to read the variable you already populated - pick one source of truth). Expected: the runtime env now has the key under the exact name the client looks up.
4. Restart the agent process so it picks up the changed environment. Expected: the process starts with the corrected env (env changes do not apply to already-running processes).
5. Retry a simple Lever read, like listing postings. Expected: a 200 instead of 401.

## Use this when
- Lever returns 401 invalid token but the key works when pasted into a manual test
- The key was recently rotated or moved between environments
- The agent runs in a container or scheduler with its own env, separate from your shell

## Not for this skill when
- The key is genuinely revoked or deleted in Lever (generate a new key instead)
- The error is 403 (the token is valid but the user lacks access)
- Every environment already has the right variable and it still 401s - the key value itself may be truncated or corrupted

## Variant phrasings
- Lever API 401 with correct API key
- Lever invalid token environment variable mismatch
- agent sending wrong Lever API key

## Why it happens
The client and the deployer disagree about where the key lives: the code reads one variable name, the deployment sets another (a typo, a renamed variable after a refactor, or a shell env that never reaches the container). The client then sends an empty or stale value, and Lever correctly calls it an invalid token. The key was never the problem; the plumbing was.

## Edge cases
- Keys with trailing newlines or quotes from copy-paste also 401; trim the value when you move it.
- If the variable is set in a dotenv file, confirm the agent's launcher actually loads that file - many schedulers ignore it.
- Do not log the key value while debugging this; log the variable name and whether it is set, never the secret itself.

## Provenance

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