Personal or Tenant. The access level controls who the connection belongs to and who can use it. Only API key credentials can change level after they are created.
This is separate from a Gateway’s own
Personal or Tenant visibility. Credential access level decides who can use a connection; Gateway visibility decides who can see the Gateway. A Tenant Gateway can use a Personal credential, and a Personal Gateway can use a Tenant-shared one. See Tenant vs. Personal Level Gateway Configs.The two levels
| Level | Who can use it | Typical use case |
|---|---|---|
| Personal | Only you | Your own accounts, individual API keys, anything tied to your identity |
| Tenant | Everyone in your organization | Shared service accounts, a single organization-wide API key, apps everyone should access the same way |
Personal is the default for a new connection. An admin has to explicitly share a configuration at the Tenant level.How each authentication method handles levels
Access levels don’t work identically across every authentication method. What actually gets shared at theTenant level depends on how the app authenticates.
| Authentication method | What can be shared at Tenant level | What always stays Personal |
|---|---|---|
| OAuth (DCR) | Nothing, always Personal | Your sign-in and access token |
| OAuth (Manual) | The OAuth app registration itself | Each user’s individual sign-in and access token |
| API Key | A single organization-wide key | Individual keys, until an admin provides a tenant-level key |
| Pass-Through | Not applicable | Not applicable, since nothing is stored |
Personal by definition.
Other apps require an admin to register an OAuth app first (providing a client ID and secret, for example). That registration is created at the Tenant level so it only has to be done once, but each person still clicks Connect and signs in with their own account. Nobody’s access is shared just because the app registration is.
For API key based apps, an admin gets an explicit choice:
- Share across tenant: Enter one key that every user in the organization uses.
- Leave it personal: Each user provides their own key when they connect.
Choosing a level
| Choose Tenant when… | Choose Personal when… |
|---|---|
| The app represents a shared resource (a team Slack workspace, a shared database) | The app is tied to an individual’s identity or permissions |
| You want every user to have access without individually connecting | Different users should have different levels of access to the underlying app |
| You’re managing a service account or bot credential | You want to audit actions back to a specific person |
Managing access
Who can create, change, or remove a connection depends on its level and your role:- Tenant-level connections can only be created, changed, or removed by an admin (Platform Admin, Admin, or a custom role with the appropriate permission). Any user in the organization can use one once it exists.
- Personal-level connections can only be seen and managed by the user who created them. Not even an admin can see or use another user’s personal connection.
Removing your own personal connection or disconnecting your account never affects the underlying
Tenant-level app registration. It stays in place for everyone else.Changing an existing connection’s level
You can move an API key between levels after it’s created, with a few guardrails:- Promoting
PersonaltoTenantmakes the connection available to everyone in your organization going forward. - Demoting
TenanttoPersonalremoves access for every other user who was relying on it.
Related Resources
Supported Credential Types
How each app authenticates, from API keys to OAuth
Tenant vs. Personal Gateway Configs
Set who can see and use a Gateway
Gateway/Deployment Creation
Connect an app’s credentials and tools
Editing a Gateway
Change apps, credentials, and tools after setup