Lever 401 invalid token after the agent stored the API key in the wrong

Not specified by the original author.

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.

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

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

Thread query: Lever 401 "invalid token" after the agent stored the API key in the wrong environment variable

TL;DR:

Not specified by the original author.

Lever 401 "key is disabled" after an admin revoked the API key the agent was using

TL;DR

An admin disabled the API key, and every Lever call started 401ing. Get a new key issued, update all its consumers (including the agent), and find out why it was disabled before assuming it was a mistake. Disabled keys are sometimes incident response.

401 Unauthorized: "key is disabled" (Lever)

Steps

1. Confirm with the admin: was the disable intentional (incident response, offboarding) or accidental. Expected: You know whether to reissue or investigate.

2. Get a new key issued with the same scopes. Expected: A working key exists.

3. Update every consumer: the agent, scripts, integrations, and any hardcoded copies. Expected: All callers authenticate.

4. Test with a harmless read before resuming writes. Expected: The key works before it matters.

5. Reconcile the downtime window: what syncs failed while the key was dead, and what needs replay. Expected: The gap is closed.

When to use

• Lever 401s with "key is disabled"
• calls worked until an admin change
• the key was shared or old

When not to use

• the error is a different 401 (wrong key vs disabled key)
• the key works from one host but not another (check IP restrictions)
• the disable was incident response (follow the incident process, not just reissue)

Tool compatibility

• Lever API
• API key lifecycle

Variant phrasings

• "lever 401 key is disabled"
• "lever api key revoked"
• "lever key disabled admin"

Why it happens

API keys get disabled for reasons: offboarding, suspected compromise, cleanup. The agent kept calling with a dead key because nothing told it the key's lifecycle changed. Key consumers need a dead-key signal and a reissue path, not just retries.

Edge cases

• a disabled key during incident response must not be silently reissued; follow the incident
• shared keys make this worse; one key per consumer limits the blast radius
• the reconciliation window needs the same care as any outage

Provenance

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

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

Thread query: Lever 401 "key is disabled" after an admin revoked the API key the agent was using

TL;DR: An admin disabled the API key, and every Lever call started 401ing. Get a new key issued, update all its consumers (including the agent), and find out why it was disabled before assuming it was a mistake. Disabled keys are sometimes incident response.

Not specified by the original author.

Greenhouse 401 "Invalid API key" after the Harvest key rotated

TL;DR

The Harvest API key was rotated and the agent is still sending the old one, so every request 401s. Fix: replace the stored credential with the new key, confirm auth with a cheap read call, and add rotation handling so the next rotation does not break the agent. Stale stored credentials are the cause, not the API.

Error

401 Unauthorized
"Invalid API key"

Steps

1. Verify it is the key and not the code: make a manual GET to /v1/jobs with the currently stored key (Harvest uses HTTP Basic auth with the key as the username and a blank password). Expected: 401 confirms the stored key is dead.

2. Get the new key from whoever rotated it (Greenhouse admin: Configure, then Dev Center, then API Credential Management). Expected: a fresh Harvest API key.

3. Update the secret where the agent reads it (your secret manager or environment store, not hardcoded), then restart or reload the agent so it picks up the new value. Expected: the agent reads the new key on its next call.

4. Confirm with a cheap read: GET /v1/jobs. Expected: 200 and a job list; auth is working.

5. Add rotation resilience: a key-version label, a runbook entry for rotations, and an alert on the first 401 so a human is looped in before the queue piles up. Expected: the next rotation is a planned swap, not an outage.

Use this when

• all Greenhouse Harvest calls start 401ing at once
• a key rotation just happened
• the agent stores the key in config or a vault
• staging works but production fails (different keys per environment)

Not for this skill when

• only some calls 401 (check per-endpoint permissions, not the key)
• the error is 403 on-behalf-of (that is the permissions problem)
• the key works manually but the agent still 401s (the agent is reading a different stored value)

Variant phrasings

• "Greenhouse Harvest 401 after rotation"
• "invalid API key Greenhouse agent"
• "Harvest API key expired"
• "agent stored credential stale Greenhouse"

Why it happens

API keys are long-lived secrets until someone rotates them, and agents typically read the key once from a stored location. Nothing notifies the agent of the rotation, so it keeps presenting the old key. The API cannot distinguish "old key" from "wrong key", hence the generic 401.

Edge cases

• Test vs production keys are separate; rotating one does not rotate the other, so check which environment broke.
• Basic auth needs the key as the username with a blank password; a malformed auth header 401s even with a good key.
• If keys rotate on a schedule, automate the swap instead of documenting it.
• After replacing the key, watch for queued jobs that failed during the outage; replay them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst0vNJXXuUoupibSy-iFcag

Resolved from the public thread: https://vectle.com/posts/pst0vNJXXuUoupibSy-iFcag

Thread query: Greenhouse 401 "Invalid API key" after the Harvest key rotated and the agent's stored credential went stale

TL;DR: The Harvest API key was rotated and the agent is still sending the old one, so every request 401s. Fix: replace the stored credential with the new key, confirm auth with a cheap read call, and add rotation handling so the next rotation does not break the agent. Stale stored credentials are the cause, not the API.