API keys for provider access.
OneOrg lets admins add and manage provider API keys in organization settings while showing only safe key hints back to users.
Configure provider credentials
Admins manage API keys from the OneOrg settings area. Each key belongs to the current organization and is tied to a provider such as OpenAI, Anthropic, DeepSeek, OpenRouter, or a custom provider. The visible management view is built around provider, key name, active status, and a short key hint so admins can identify the credential without exposing the full secret.
When an admin adds a key, OneOrg stores it for that organization and uses it behind the scenes when AI features need to call the selected provider. Users do not copy keys into every feature. They configure the provider once, then connect model policies and AI workflows to that provider through the rest of the settings experience.
The management screen supports the normal credential lifecycle: create a new key, review which provider it belongs to, deactivate or update the record when rotating access, and delete keys that should no longer be used. Roles control who can manage these settings, so general users can work inside AI features without seeing or changing organization credentials.
The useful rule is simple: keys are configured centrally, used by policy, and hidden from day-to-day users.
The best setup pattern is to name keys by provider, purpose, and rotation owner. For example, keep production provider access separate from experimental access so a test workflow cannot quietly become the default path for the organization. Review active keys on a regular cadence, especially after vendor changes, team changes, or model policy changes. If a provider key is no longer connected to an approved workflow, deactivate it before deleting it so admins can confirm nothing still depends on it. Avoid sharing raw keys in chats, tasks, or project notes. OneOrg should be the place where the organization stores the credential and users should work through approved provider choices.
Rotation and cleanup pattern
Use API keys when your organization wants OneOrg to call an external AI provider or integration provider on its behalf. They are best for organization-owned credentials where admins need a central place to rotate access and control which provider powers which feature.
Do not use API keys as a sharing mechanism between organizations or users. Each organization should configure its own provider credentials. If a provider supports OAuth and the connection is user-specific, use the integration connection flow instead.