—Connections

Activate release integrations

Axiom opens provider consent with one click, but the service operator must register each OAuth application first. Provider secrets remain in the production secret manager and are never entered into the desktop app.

Two separate responsibilities

The service operator registers the OAuth application, exact callback URL, and server-side secret once. A workspace owner or admin then clicks Connect, reviews the provider consent screen, selects the intended workspace, and returns to Axiom for live validation.

Service operator checklist

Before connecting a provider

Set the production Axiom origin as NEXTAUTH_URL; callback construction fails closed when the origin is not trusted.
Register the exact HTTPS callback shown below. Wildcard callback domains are not supported.
Store client secrets only in the hosting platform's encrypted secret manager—never in NEXT_PUBLIC_*, the desktop app, logs, or Git.
Redeploy the service after adding credentials, then use Plugins & Skills or Settings → Integrations to start consent.
Run the harmless validation step. Axiom does not label a connection active from consent alone.

Repository-scoped code and release evidence

GitHub App

Register the installation callback

texthttps://visionxixlabs.com/api/integrations/github/install-callback

Configure the server-side GitHub App

Set the App slug, App ID, installation-token signing key, and webhook secret using the deployment secret manager. Grant only the repository permissions required by the enabled Axiom workflows.

Install on selected repositories

A workspace admin reviews GitHub's installation screen and selects repositories. Axiom records the installation, then verifies scoped read access before showing it as validated.

Governed release notifications

Slack

Register the callback

texthttps://visionxixlabs.com/api/integrations/slack/callback

Store the OAuth credentials

bashSLACK_CLIENT_ID=<Slack app client ID>
SLACK_CLIENT_SECRET=<secret manager reference>

Review least-privilege consent

The current workflow requests channels:read and chat:write. It does not request direct messages, private-channel history, commands, or broad message history.

Identity validation before messaging

Microsoft tenant / Teams

Register the callback

texthttps://visionxixlabs.com/api/integrations/teams/callback

Store tenant OAuth configuration

bashMICROSOFT_CLIENT_ID=<application client ID>
MICROSOFT_CLIENT_SECRET=<secret manager reference>
MICROSOFT_TENANT_ID=<approved tenant ID>

Validate the boundary

The authorization-code flow uses PKCE and currently requests openid, offline_access, and User.Read. This verifies tenant identity; it does not grant Teams messaging authority.

Issue context and governed follow-up

Linear

Register the callback

texthttps://visionxixlabs.com/api/integrations/linear/callback

Store the OAuth credentials

bashLINEAR_CLIENT_ID=<Linear application client ID>
LINEAR_CLIENT_SECRET=<secret manager reference>

Review scopes and validate

Consent requests read and issues:create. Mutating Agent actions remain separately approval-gated and auditable after the connection is active.

Understand connection states

Setup required: the service is missing an OAuth registration, trusted callback origin, or production secret. A workspace user cannot fix this in the desktop app.

Awaiting validation: provider consent returned successfully, but Axiom has not yet completed a live server-side check.

Active / validated read-only: the scoped provider token or GitHub installation passed live validation.

Needs attention / validation overdue: validation failed or is stale. Revalidate before relying on the connection for release evidence.

Heads up

Never paste a client secret into Agent chat or a repository file. If a secret was exposed, revoke it at the provider, rotate it in the secret manager, and review the Axiom audit trail before reconnecting.

Still blocked?

Include the failed step and error. Never send a password, token, or cloud secret.

Open support request