Integrations

Integrations connect codev to the external tools and services your team already uses — starting with your source control provider. They tell codev how to authenticate when it reads your repositories, opens pull requests, posts check results, and links each contributor's identity for Git operations.

You manage integrations under Settings > Organization > Integrations. Only organization owners can view or change them.

What you can connect

Provider	What it powers
GitHub	Source control, pull requests, and CI/CD integration. See GitHub.
Azure DevOps	Source control and Azure Boards work items. See Azure DevOps.
Jira	Issue tracking — surfaces the work items in your commits and, optionally, reports deployment and build status back to Jira. See Jira.
npm Registry	Authenticated access to a private npm registry so workflows can install and publish packages. See npm Registry.
JFrog Artifactory	Authenticated access to an Artifactory npm registry. See JFrog Artifactory.
AI Providers	Connect Anthropic, OpenAI, Amazon Bedrock, or GitHub Copilot to power AI insight reports, architecture analysis, and error analysis. See AI Providers.
Slack	Build and release notifications posted to a Slack channel via an incoming webhook. See Slack.

More providers appear on the Integrations page as they become available. The concepts below — scoping, defaults, and credential precedence — apply to every provider.

How scoping works

Every integration you add has an availability that decides which projects it applies to:

Scope	What it means
Global (all projects)	The credential is available to every project. Optionally mark it Set as default for this provider so it is used as the fallback whenever a project has no integration of its own.
Specific project	The credential applies to one project only and overrides any global credential for that project.

When codev needs to authenticate for a project, it resolves the most specific credential first:

1. An integration scoped to that project
2. The default integration for the provider
3. A global integration for the provider
4. The credential the instance itself manages

The last step is what makes the cloud instance work out of the box — see GitHub for what the managed credential is and when your own integration takes over.

Signing in to codev is separate from your integrations. How you log into codev (for example, signing in with GitHub or Microsoft) is handled by the instance, not by the integrations you register here. Adding your own credentials below changes how codev talks to your provider on your behalf — it does not change how anyone signs in. The GitHub page explains this in detail.

Cloud vs. self-hosted

• On the cloud instance, codev already ships with a managed connection to your provider, so most teams can start without configuring anything. You add your own integration only when you want codev to act through your own app or token — for example, to scope a credential to a single project, or to use your organization's own GitHub App.
• On a self-hosted instance, you supply the provider credentials yourself. The provider-level credentials are configured on the server. See the sfp server documentation for self-hosting setup.