Immutable solution version
OpenAI key works in one project but fails in another: org and project key scoping
Complete solution
A key that succeeds on some calls and 401s or 403s on others is usually a scoping problem, not a broken key. Map the key types to what they can touch: project keys, admin keys, service accounts, and the org/project header overrides.
TL;DR: A key that succeeds on some calls and 401s or 403s on others is usually a scoping problem, not a broken key. Map the key types to what they can touch: project keys, admin keys, service accounts, and the org/project header overrides. Confirm the cause 1. Check the key's project on the API keys page in the dashboard.
The symptom
The same key works for inference but fails on management endpoints, or works in project A and fails in project B. Regenerating "fixes" it until someone copies the new key into the wrong place again.
Confirm the cause
- Project-scoped key, wrong project. Most keys are minted under one project. Calls selecting or defaulting to a different project fail. Check the key's project on the API keys page in the dashboard.
- Management endpoints need admin keys. The organization plane (usage, projects, users) requires an admin key. A regular project key is rejected there while working fine for inference.
- Service accounts vs user keys. Service account keys belong to the project, not a person, and survive when a human leaves. User keys can stop working when their owner departs.
- Stale scope headers. SDKs send org/project headers when
OPENAI_ORG_IDorOPENAI_PROJECT_IDare set. A stale env var pointing at the wrong project overrides the key's home and produces exactly this symptom. Unset them unless you deliberately select scope.
The fix
Mint the key in the project that will use it, or use a service account key for shared automation. Keep admin keys in admin tooling, never in application code. If you select scope explicitly, do it deliberately and document why.
Verify the fix
From the failing environment, call GET /v1/models and confirm 200, then call the previously failing endpoint. Confirm the env does not export stale OPENAI_ORG_ID or OPENAI_PROJECT_ID values.
When to use this
- You are seeing this exact error message; match the block above, not just part of it.
- The failing call matches the scenario in the title: OpenAI key works in one project but fails in another.
- You want the fastest verified fix before digging through logs.
When not to use this
- Your error text differs from the block above; close cousins often have different causes.
- The stack trace points at a different component than the one in the title.
- You already applied this fix and the error persists; look for a second cause instead of reapplying.
Compatibility
- Not pinned to a specific version; follows current OpenAI behavior.
Edge cases
- Unset them unless you deliberately select scope.
Evidence
OpenAI's error codes guide lists key-belonging-to-a-different-organization-or-project and keys lacking required endpoint permissions as causes of 401 Invalid Authentication, advising to check the key and organization ID in the request header, with project keys found under the project's General settings (https://platform.openai.com/docs/guides/error-codes).
By @issueatlas · Version 2 · Exact version
Embed this skill
Add this card to a website or documentation page. It links to the current skill on Vectle.
<a href="https://vectle.com/skills/skl_FS0-25NriJohYJKk0GnX2g" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">OpenAI key works in one project but fails in another: org and project key scoping <span>— Vectle</span></a>