Lever 401 invalid token API key

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.

TL;DR

The 401 means Proxycurl does not recognize the credential you sent. Send the key as a Bearer token in the Authorization header exactly as documented, confirm the key is active in the dashboard, and check it is not scoped away from the person endpoint. A key that works on company lookup but 401s on person lookup is a scoping problem, not a typo.

proxycurl 401 invalid api key on person profile endpoint

Use this when

• The person profile endpoint returns 401.
• The same key works on other endpoints or used to work.
• You just created or rotated the key.

Not for this skill when

• The error is 404. The key is fine; the profile is missing.
• The error is 402. That is credits, not auth.

Steps

1. Send the header exactly as documented: `your auth header with no extra whitespace or quotes. Verify: a curl with the literal header reproduces or clears the 401.
2. Check the dashboard: the key exists, is active, and is not revoked or expired. Verify: status reads active.
3. Confirm the key has person-endpoint scope. Some keys are issued per product. Verify: the dashboard shows person API enabled for the key.
4. After rotation, allow a few minutes for propagation and update every place the old key was stored. Verify: no stale copies in env files or CI secrets.
5. If the header is exact and the key is active and scoped, contact support with the request timestamp. Verify: you have a support thread, not a guessing loop.

Variant phrasings

proxycurl 401 unauthorized

The short search, same header-first fix.

proxycurl api key not working

Symptom phrasing, points at step 2.

proxycurl person endpoint auth failed

Endpoint phrasing, lands on the scoping check.

Compatibility: Proxycurl API, Bearer auth. Header formatting is the number one cause.

Why it happens

API gateways reject the key before any business logic runs, so a 401 never tells you whether the profile exists. The common causes are mundane: the key pasted with a trailing space, sent as a query param instead of a header, revoked during rotation, or issued without the person product scope. The fix is always in the credential plumbing, never in the lookup.

Edge cases / pitfalls

• Never log the full key when debugging 401s. Log the last four characters.
• Keys in client-side code get harvested and revoked. Server-side only.
• A 401 that appears suddenly on a working key usually means rotation or a billing hold. Check both.
• Do not retry 401s in a tight loop; some gateways rate-limit auth failures and you will add a 429 to the 401.

Provenance

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

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

Thread query: proxycurl 401 invalid api key on person profile endpoint

TL;DR: The 401 means Proxycurl does not recognize the credential you sent. Send the key as a Bearer token in the Authorization header exactly as documented, confirm the key is active in the dashboard, and check it is not scoped away from the person endpoint. A key that works on company lookup but 401s on person lookup is a scoping problem, not a typo.