Credentials

Credentials are reusable, project-owned secrets for external services. A project member saves a provider key once, then grants the Credential to plugin installations without copying the secret into plugin settings or plugin code.

Open Credentials from the project sidebar to create and manage them. Choose a provider, enter a name and secret, set owners and contexts, and decide whether other project members may use or maintain the Credential. The secret is write-only: it can be replaced, but it is never displayed after saving.

Ownership and access

A Credential belongs to the project, not to the member who created it. The creator is recorded for audit and becomes the first owner, but removing that member from the project does not disable the Credential or stop consumers that already use it. At least one owner must remain.

Owners and Project Admins can manage the Credential. The Shared for use and Shared for maintenance settings add access for other eligible project members, subject to their role scope and assigned contexts. Consumers re-check access, status, and definition compatibility whenever they use a Credential.

Plugin use

A plugin release declares each Credential capability it needs. During installation, the member explicitly selects a compatible project Credential for every required capability and may choose not to grant an optional one. The plugin receives a handle that can make approved requests; the raw secret never enters its frame.

The Used by section shows active consumer bindings and when each binding last succeeded. The Credential list also shows aggregate last use. A Credential with active bindings cannot be deleted; disable it to stop use immediately, or first remove or replace the consumer bindings. Replacing a secret keeps the bindings and consumers use the new value on their next request.

Google Service Account

A Google Service Account Credential lets a plugin call Google APIs, such as Google Docs and Google Sheets, as a service account:

1. In Google Cloud, create a service account and a JSON key for it; see Create and delete service account keys. Organizations created on or after May 3, 2024 block key creation by default with iam.managed.disableServiceAccountKeyCreation; an organization admin has to allow it.
2. Enable the API the plugin uses, such as the Google Docs API or the Google Sheets API, in the project the key belongs to.
3. Create a Credential with the Google Service Account provider and paste the key or drop the JSON file. OWOX Data Marts asks Google for a token before saving and refuses a key Google rejects. A new key can take about a minute to start working.
4. Share each document or spreadsheet the plugin should change with the service account address shown on the Credential, as Editor.

Use a dedicated service account with no project roles: a plugin reaches whatever the account can reach within the scopes it declares. A replacement key must belong to the same service account; create another Credential for a different one. Access tokens Google already issued stay valid for up to an hour after a key is disabled or deleted; disable the service account to revoke them.

AI mappings

An AI-capable Credential maps logical fast, reasoning, and embedding capabilities to provider model IDs. A mapping can follow the definition’s recommended model or override it with a fixed provider model ID. Recommended mappings follow compatible definition updates automatically; overrides stay unchanged. If an override selected from the definition catalog later disappears, consumers that require it need setup again. An advanced manual model ID remains a deliberate manual override and does not depend on catalog membership.

External definitions

Built-in definitions cover common providers. A maintainer may also add a declarative Credential definition from a public or deployment-accessible private GitHub repository. Private definitions use the same configured GitHub access as private plugins. OWOX reads immutable release versions and checks for updates daily. See Credential definitions for the authoring contract.

Compatible updates within the accepted version line become current automatically. A new compatibility line requires explicit maintainer consent before runtime use resumes. If GitHub is unavailable or a release is invalid, the last accepted version remains active.

Provider validation is optional and informational. A definite authentication rejection prevents a new or replacement secret from being saved; an unavailable or inconclusive probe does not.

Credentials use the same product database and behavior in OWOX Cloud and self-managed deployments; there is no separate Credential encryption or vault configuration in this feature.