Connectors
Connectors gives applications and agents a common way to discover external operations, connect accounts, invoke permitted actions, and receive provider events. It keeps provider credentials inside the service and checks each request against the caller's authority and selected Connection.
Current status: pre-v1. Personal-local and bounded hosted deployments are implemented. Available operations depend on the deployment, provider adapter, Connection, and Grant. Full SaaS and satellite federation remain outside the current support claim.
Read what's new in v0.7.1 for user-facing release highlights and upgrade notes.
See the system
Pan the full-size diagram: swipe or scroll, or focus the canvas and use the arrow keys.
The catalog describes what can be called. A deployment enables an Integration; authorization creates a Connection. Receiver policy and Grants bound what a caller can do through it. Hosted writes require a Grant and any demanded approval. Connectors binds credentials at the execution boundary and records the result. Hosted identity comes from Identity.
Understand the architecture
Start with the system overview to follow one hosted Slack mention through receipt, an authorized consumer, and an approved reply attempt. The same example connects all six chapters.
- System overview — locate the boundaries and the subsystem owners.
- Connections and authority — separate account access, Grants, and approval for one action.
- Commands and interfaces — trace a request from description to dispatch, including refusals.
- Events and durable state — understand what is persisted, acknowledged, replayed, and still uncertain.
- Deployment and runtime — compare local and hosted prerequisites and responsibilities.
- Specification status — distinguish shipped behavior, ESS declarations, generated artifacts, and coverage gaps.
Connect a provider
The provider guides explain the supported connection paths and their credential requirements.
More columns: swipe horizontally, or focus the table and use the arrow keys.
For hosted operation, continue with Integration administration. For installation, configuration, and prerequisites, see Deployment and runtime.
Collect changes over time
Bounded reads support Jira issue changes and comments, Confluence page changes, and GitLab project activity, issues, merge requests, pipelines, deployments and commits. Each operation describes its time filters and continuation fields. Follow every page, retain the same window while paging, and deduplicate overlapping results by their source identity and revision. An empty or partial page does not prove that a whole source has been collected.
Use connectors operation search and a fresh connectors operation describe to check the
operations admitted by your deployment. Before replacing a source-built installation, compare
the operations your application actually uses with the candidate; a working account probe alone
does not establish compatibility. Upgrade the CLI and its local daemon together.
Contracts and implementation
A hosted deployment serves its API reference at {base_path}/docs and its OpenAPI document at
{base_path}/openapi.json. The usual base path is /api/connectors/v1. These describe the deployed
binary; use them when implementing an HTTP client.
The handbook describes current behavior and links to its implementation. The domain design, architecture design, and outbound MCP design retain detailed engineering decisions and dated amendments. Contributors should read AGENTS.md.