OpenConnector

OpenConnector is a connector gateway that gives agents authenticated access to services their users already use, without handing provider credentials to the agent process. A user connects an app account once, and the gateway exposes a shared catalogue of more than 1,000 providers and 10,000 prebuilt Actions — covering products such as GitHub, Gmail, Notion, BigQuery, Google Analytics, Supabase, Airtable, and Slack — to applications and agents.

Four call paths reach the same runtime: a TypeScript Connector SDK from application code, the oo CLI as a local agent relay, MCP at http://localhost:3000/mcp for agent hosts, and HTTP with a generated OpenAPI 3.1 document for custom clients. A web console browses connectors, configures API keys and OAuth clients, creates runtime tokens, inspects Action schemas, debugs calls, and reviews recent runs. Agents receive Action metadata, safe account labels, and results; provider secrets stay behind the runtime boundary.

Credential handling covers API keys, OAuth2, custom credentials, and no-auth providers, and runtime controls include connection identity, scopes, runtime tokens, action allow and block policies, temporary file transit, and redacted run logs. Self-hosting runs on Node.js 22 or newer or Docker, with SQLite by default or PostgreSQL 15 and newer when a database URL is configured; PostgreSQL migrations are explicit and server startup never applies DDL. Transit files go to local storage or an S3-compatible bucket. Additional targets include a Helm chart for Kubernetes, Cloudflare Workers with D1 and R2, Fly.io, and a hosted runtime from OOMOL that supplies its own OAuth apps.

Features

• Provider catalogue: more than 1,000 providers and 10,000 prebuilt Actions behind one gateway
• Four call paths: TypeScript SDK, oo CLI relay, MCP endpoint, and HTTP with a generated OpenAPI 3.1 document
• Credential boundary: API key, OAuth2, custom, and no-auth credentials stay inside the runtime, never reaching the agent
• Inspectable contracts: request and response schemas, required scopes, and lazy-loaded executor source per Action
• Runtime policy: connection identity, scopes, runtime tokens, allow and block lists, and redacted run logs
• Web console: connector browsing, credential setup, token creation, Action debugging, and run review
• Storage options: SQLite by default or PostgreSQL 15 and newer, with explicit migrations run before startup
• Deployment targets: Docker or Node.js self-hosting, a Helm chart, Cloudflare Workers with D1 and R2, Fly.io, and a hosted runtime
• Portable ids: the same provider ids, Action ids, schemas, and contracts across self-hosted and hosted deployments