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, Google AI, Amazon Bedrock, GitHub Copilot, or Claude on Google Vertex 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:
- An integration scoped to that project
- The default integration for the provider
- A global integration for the provider
- 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.
Acting as the organization vs. acting as you
The integrations on this page are the identity codev authenticates as the organization — the GitHub App or Azure DevOps Service Principal that reads repositories, receives webhooks, and posts bot results. Separately, each person can link their own provider identity so that actions they take run under their name instead of the bot's.
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.