Providers And Modes

Use this page when you need the current provider matrix without reading runtime code.

For registry-wide status, including planned entries without runtime support, use All Connectors and Planned Connectors.

Modes

live: query the provider directly at runtime
indexed: sync provider data into the platform as extracted chunk text, vectors, and permission/provenance metadata for retrieval

Current Provider Matrix

Provider	Auth provider id	Default modes	Current live status	Current indexed status	Notes
Google Drive	`google`	`live`	Implemented (`file-resource-live-query`, `connector-resource-list`)	Implemented	Live file search is default; indexed mode is optional and recommended for faster, broader semantic document recall
Google Calendar	`google`	`live`	Implemented (`calendar-live-query`)	Not implemented	Google Calendar is live-only event list/search/recent lookup through Google Calendar API; no indexed calendar storage
Google Contacts	`google`	`live`	Implemented (`contact-live-query`)	Not implemented	Google Contacts is live-only saved-contact search/list through Google People API; Workspace Directory people are out of scope
GitHub Repositories	`github`	`live`	Implemented (`code-repository-live-query`)	Not implemented	Live repository, code file, bounded file-read, and commit access through GitHub REST; no indexed GitHub storage
GitHub Issues	`github`	`live`	Implemented (`work-item-live-query`)	Not implemented	Live GitHub issue search/list/detail and comments through the shared work-item domain
GitHub Pull Requests	`github`	`live`	Implemented (`work-item-live-query`)	Not implemented	Live GitHub PR search/list/detail, reviews, review comments, requested reviewers, and changed files through work-item
OneDrive	`microsoft`	`live`	Implemented (`file-resource-live-query`, `connector-resource-list`)	Implemented	Live file search is default; indexed mode is optional and recommended for faster, broader semantic document recall
Odoo	user or deployment API key	`live`	Implemented (`business-record-live-query`)	Not implemented	Live Odoo JSON-2 business-record access; user keys are encrypted by API, while deployment credentials are configured in customer CMS
Microsoft Calendar	`microsoft`	`live`	Implemented (`calendar-live-query`)	Not implemented	Microsoft Calendar is live-only Graph calendarView/search access; it does not broaden the Outlook mail connector
Microsoft Contacts	`microsoft`	`live`	Implemented (`contact-live-query`)	Not implemented	Microsoft Contacts is live-only Microsoft 365 people search plus saved-contact listing; it does not broaden the Outlook mail connector
SharePoint	`microsoft`	`live`	Implemented (`knowledge-page`, `file-resource`, `business-record`)	Not implemented	Live selected-site pages, document libraries, files/folders, lists, list items, columns, and bounded reads through Microsoft Graph
OneNote	`microsoft`	`live`	Implemented (`knowledge-page-live-query`)	Not implemented	Live selected-notebook notebooks, sections, hierarchy, pages, and bounded page content reads through Microsoft Graph
Gmail	`google`	`live`	Implemented (`search`)	Implemented	Gmail can run live-first and also support indexed retrieval
Outlook	`microsoft`	`live`	Implemented (`search`)	Implemented	Outlook can run live-first and also support indexed retrieval
Slack	`slack`	`live`	Implemented (`search`)	Not implemented	Slack uses RTS-backed live search only; results stay non-persistent and org-ready support is follow-up
Jira	`atlassian` or PAT	`live`	Implemented (`work-item-live-query`)	Deferred	Jira is live-only in V1; OAuth uses one selected site, while Data Center PAT access can be user-managed or company-managed
Confluence	`atlassian` or PAT	`live`	Implemented (`knowledge-page-live-query`)	Deferred	Confluence is live-only in V1; Cloud OAuth uses one selected site, while Data Center PAT access can be user-managed or company-managed

Resource Defaults And Scope Selection

Provider	Default resource behavior	Scoped selection policy	Notes
Google Drive	Files are selected by default	`none`	File/folder scoping is not exposed in the connector create flow today
Google Calendar	Calendars and events are selected by default	`none`	User-visible calendar lists are checked live; no resource picker is required today
Google Contacts	Contacts are selected by default	`none`	Saved-contact search/list is live-only; no indexed contact scope is exposed
GitHub Repositories	Repositories are selected by default	`optional`	Repository selection is optional; when omitted, live queries use bounded accessible-repo search
GitHub Issues	Repositories are selected by default	`optional`	Optional repository selection scopes live issue search/list/detail
GitHub Pull Requests	Repositories are selected by default	`optional`	Optional repository selection scopes live PR search/list/detail
OneDrive	Files are selected by default	`none`	File/folder scoping is not exposed in the connector create flow today
Odoo	Business records are selected by default	`none`	Model access comes from user-managed setup or deployment profile configuration, not scoped resource selection
Microsoft Calendar	Calendars and events are selected by default	`none`	Calendar discovery and event lookup are live-only; shared/delegated calendars are out of scope
Microsoft Contacts	People and contacts are selected by default	`none`	Microsoft Graph people search and saved contacts are live-only; Outlook mail is separate
SharePoint	Sites, pages, files, and lists are selected by default	`required`	Selected `sites` are required; lists, drives/libraries, and folders can further narrow the selected-site boundary
OneNote	Notebooks and pages are selected by default	`required`	Selected `notebooks` are required; sections can further narrow the selected-notebook boundary
Gmail	Messages are selected by default	`none`	Mailbox query is provider config, not scoped resource selection
Outlook	Messages are selected by default	`none`	Mailbox query is provider config, not scoped resource selection
Slack	Workspace-chat resources default from registry	`none`	Live-only; no indexed all-off workaround is allowed
Jira	Projects are selected by default	`required`	Site selection comes first; project selection is scoped to that site
Confluence	Spaces and pages are selected by default	`required`	Site or base URL selection comes first; saved spaces selection is required and may be all or selected spaces

These values are exposed through catalog/config contracts as defaultResourceTypes and resourceSelectionPolicy. The registry also exposes connectionScope, which tells the web create flow whether a connector can be added once per linked account or needs configuration-derived identity before the final duplicate check. The web UI uses those fields generically: single-resource connectors cannot be turned off, multi-resource connectors cannot be saved with all resources off, scope controls are hidden when the provider has nothing selectable, and account-scoped duplicate rows are not shown in the add-connector picker.

Some providers also declare requiredScopedResourceTypes. This is how SharePoint requires selected sites and OneNote requires selected notebooks without adding provider-specific UI branches. Dependent provider options receive the current draft resourceSelection, so SharePoint lists, drives/libraries, and folders can load from selected sites, and OneNote sections can load from selected notebooks. Provider-family resource scopes are separate and must be explicit manifest opt-ins; Microsoft connectors do not infer account-level resource scopes merely because they share the microsoft OAuth provider.

Account Binding Model

Every built-in connector supports more than one linked account per signed-in user.
The shared connector configure flow is the canonical place where users choose which linked account to bind, even when they arrived from a provider OAuth callback.
Duplicate prevention is shared and scope-based:
- canonical connector identity is user + provider + linked account + scopeKey
- most providers use an empty scopeKey
- Jira stores siteId as scopeKey, so one Atlassian account can support multiple connectors as long as each connector targets a different site
GitHub uses an empty scopeKey; the three GitHub connector keys can share the same linked GitHub account while each connector record owns its own optional repository selection config.
Account-scoped connectors are hidden from the account-level add flow once that connector already exists under the linked account. Configuration-scoped connectors, currently Jira, remain addable until the user chooses the disambiguating config and the service can validate the final scopeKey.
When a configuration-scoped connector remains addable under the same linked account, the web add choice should say that the user is adding another configured scope, connected rows should display the selected scope using the shared connectionScope.configKeys plus config-field labels, and provider-backed option labels should be used when available. For Jira OAuth this appears as another Jira site and a Jira Site detail showing the site name on connected rows. Auto-fill must not select a scope value that is already connected for the same linked account.
User-managed API-key/PAT connectors, currently Odoo, Jira Data Center, and Confluence Data Center PAT access, do not bind to Better Auth linked accounts for provider access. The web add flow validates the user’s own credential, and API derives the owner-scoped credential identity.
Deployment-scoped connectors, currently Odoo, Jira Data Center, and Confluence Data Center company-managed access, do not bind to Better Auth linked accounts. The web add flow uses the server-derived deployment identity after cms-customer reports a valid credential profile.
Company-managed Jira and Confluence Data Center PAT paths use dedicated customer-controlled service/bot users. The provider sees that service/bot account, not the signed-in web user, so personal prompts such as “my pages” must not be answered as if the user’s own provider identity was queried.
Linked-account ownership across different app users still fails closed in Better Auth; the same external provider account must not be linked to more than one app user.
If product requirements ever need one external provider account shared across multiple app users, that must become an app-level sharing model above Better Auth linked accounts, not a silent loosening of the current ownership invariant.

How To Read This

A connector definition existing in the registry does not mean its runtime path is production-ready.
default modes describe the product default, not every possible future behavior.
Declarative connector truth is centralized in the shared connector registry; executable runtime truth is centralized in API runtime extensions.
Connector enable/disable for an existing connection is not implemented. Do not model “disabled” by clearing resources; use disconnect/delete until a full lifecycle feature exists.

Live Vs Indexed In Practice

Choose live when the provider can answer the user request directly and that runtime path is available.
Choose indexed when the platform needs durable synced data for retrieval, history, or search.
Indexed mode stores extracted chunk text with vectors for low-latency RAG. Live-only mode avoids embedding sync and indexed artifact retention when the provider exposes that option.
Some providers support both, but the quality and availability of each path differ by provider.
Google Drive and OneDrive expose file-resource-live-query for live document content search and connector-resource-list for browse/list. Live file search is provider full-text/keyword search plus bounded transient extraction; it is not semantic embedding parity.
Drive and OneDrive default to live-only. Indexed mode is optional and recommended for faster, broader semantic file answers over larger or historical corpora, and it stores eligible extracted chunks and vectors.
Drive live and indexed coverage includes My Drive, direct shared-with-me files/folders, and accessible Shared Drives. OneDrive live and indexed coverage uses Microsoft Graph shared-with-me/remoteItem handling and Files.Read.All so shared files and shared-folder children are eligible.
Live-only Drive/OneDrive connections can answer before indexing completes or when indexing is unhealthy. If indexed evidence is stale, weak, empty, or conflicts with live evidence for a current/latest/recent file question, chat should prefer live file evidence and use user-safe freshness or coverage language.
Google Calendar and Microsoft Calendar expose calendar-live-query list/search behavior as the live capability. Their results are transient chat grounding only; there is no indexed calendar mode.
Google Contacts and Microsoft Contacts expose contact-live-query search/list behavior as the live capability. Their results are transient chat grounding only; there is no indexed contact mode.
SharePoint exposes knowledge-page-live-query for selected sites/site pages, file-resource-live-query for document-library files/folders and bounded file reads, and business-record-live-query for lists, columns, list items, custom fields, and bounded aggregates where safe. It is live-only and read-only; no SharePoint indexed sync, upload/write, REST/CSOM path, or retained page/list/file text is implemented.
OneNote exposes knowledge-page-live-query for selected notebooks, section groups, sections, pages, hierarchy, page detail, and bounded page HTML/text reads. It is live-only and read-only; no OneNote indexed sync, app-only auth, deprecated OneNote search endpoint, media extraction, or create/update behavior is implemented.
Slack is live-only in V1; assistant.search.context powers runtime grounding, the top grounded message may get one bounded conversations.replies or conversations.history follow-up for extra context, and Slack data must not be copied into indexed storage.
Jira currently uses only live; adding or removing Jira projects changes live scope, not embeddings. Jira can use OAuth-backed Atlassian Cloud-style access, Jira Data Center user-managed PAT access, or Jira Data Center company-managed service/bot PAT access on the same work-item live domain.
GitHub Repositories exposes code-repository-live-query for repository list/search/detail, code search, bounded file reads, and recent commits. GitHub file contents and snippets are transient grounding only.
GitHub Issues and GitHub Pull Requests expose work-item-live-query with GitHub-neutral optional fields such as repo full name, number, labels, author, reviewers, branch refs, review state, and changed files.
The current GitHub OAuth App profile uses repo, read:user, and user:email. GitHub’s OAuth repo scope is write-capable for private repositories, so this app enforces read-only behavior in runtime policy, tools, adapters, and docs.
Future GitHub App installation auth is planned for least-privilege private repository read-only access. When implemented, switching between OAuth App and GitHub App profiles must run the matching auth/install flow instead of silently changing a setting.
Odoo exposes business-record-live-query for model list, field list, record search/list/detail, and aggregate only when discovered as available. Odoo user-managed API-key and deployment API-key paths share the same live domain; Odoo data is transient grounding only and is not indexed.
Confluence exposes knowledge-page-live-query for bounded space discovery, page search/list/detail, recent pages, labels, comments, page-tree relationships, and attachment metadata. Page snippets, comments, labels, and metadata remain transient private live evidence; Cloud API-token Basic auth, writes, attachment content extraction, indexed sync, and semantic whole-wiki recall are not implemented.

For the sync/storage details behind indexed mode, see Indexed Ingestion.

Planned / Not Yet Implemented

The shared runtime model still reserves mcp-server for future literal MCP server integrations.
No current built-in runtime extension uses mcp-server; the current built-in live connectors use first-party provider APIs.
Future custom or literal MCP connector work is tracked separately from the current built-in provider matrix.
Planned registry entries such as Google Chat, Salesforce, and HubSpot connectors are documented in Planned Connectors.

File	Why you would open it
`packages/domain/src/connectors/connectorRegistry.ts`	Connector keys, OAuth binding, scopes, modes, and resources
`apps/api/src/connectors/connectorRuntimeExtensions.ts`	Runtime indexed/live/resource-list/smoke support
`packages/contracts/src/connectors/contracts.ts`	Public connector mode and recovery contracts
`docs/features/connectors/spec.md`	Full connectors behavior, lifecycle, and rollout constraints
`docs/features/connectors/spec-mcp-extensions.md`	Planned future custom/literal MCP connector direction
`infra/helm/customer-cluster/`	Customer-cluster Secret mount and CMS RBAC for deployment API-key credentials