OpenConnector is an open-source auth gateway that connects more than a thousand SaaS providers to AI agents through a Connector SDK, the oo CLI, MCP, HTTP/OpenAPI, and a Web Console, and it is built for developers and teams wiring durable app access into agent products.

What it is

OpenConnector is a connector gateway: it holds user app accounts and credentials in one runtime and exposes a shared catalog of providers and prebuilt Actions to agents and applications. It lives in the TypeScript/Node.js ecosystem and targets Node.js 22+, with a Cloudflare-compatible deployment path. Users connect their app accounts once; agents then call Actions by stable ids and schemas rather than holding provider credentials themselves.

The concrete problem it solves is credential sprawl and OAuth app setup in agent products. Instead of each agent process receiving provider credentials, or each team registering its own OAuth applications per provider, OpenConnector centralizes credential handling, scope requirements, Action contracts, and run logs in an inspectable runtime. It is positioned as an open-source alternative to Pipedream and Composio, and it replaces that class of closed connector service with a gateway that can run locally or on infrastructure you own.

Key capabilities

• A working connector catalog across products such as GitHub, Gmail, Notion, BigQuery, Google Analytics, Supabase, Airtable, and Slack, described in the README as 1,000+ providers and 10,000+ prebuilt Actions.
• Credential handling for API keys, OAuth2, custom credentials, and no-auth providers.
• Inspectable Action contracts: request/response schemas, required scopes, and lazy-loaded executor source.
• Runtime controls for connection identity, scopes, runtime tokens, action allow/block policies, temporary file transit, and redacted run logs.
• Deployment options for local Docker or Node.js with SQLite or PostgreSQL state and local or S3-compatible transit storage.
• MCP exposure of app Actions to MCP-capable agent hosts through http://localhost:3000/mcp.
• Direct HTTP access via /v1/actions/* and a generated /openapi.json document, plus a Web Console for administration and debugging.

Who uses it and how

• Agent products that need reusable access across work apps, developer tools, data systems, communication platforms, and AI services, without handing provider credentials to the agent process.
• Products adding agent workflows that need stable, inspectable Action contracts for user app access.
• Teams that want hosted auth for speed while keeping a path to private or self-hosted runtime control.
• Developers using the Connector SDK from app code: OpenConnector for self-hosted runtimes, or Connector / ProjectConnector for OOMOL-hosted personal and SaaS end-user connections.
• Local-agent workflows through oo connector, which searches, inspects, and runs Actions against either OOMOL-hosted or self-hosted OpenConnector runtimes.

Getting started

Run it locally or on infrastructure you own with Docker or Node.js, or use OOMOL's hosted runtime, which requires no deployment or OAuth app setup. Deployment recipes cover Cloudflare, Fly.io, RepoCloud, and nibrun, with additional managed platforms listed in the deployment options docs.

How it compares

The README names Pipedream and Composio as the products OpenConnector is an alternative to. Those are commercial connector services where the gateway and its credential handling are operated by the vendor, while OpenConnector is Apache-2.0 licensed and can run locally or on your own infrastructure. The trade is that self-hosting shifts storage, OAuth app registration, and runtime operation onto your team, whereas the hosted OOMOL runtime removes that work at the cost of running outside your control.

When to use it — and when not to

A self-hoster must operate state storage (SQLite or PostgreSQL), transit storage (local or S3-compatible), and their own OAuth applications, and must run Node.js 22+. Teams that want zero operational surface should use the hosted OOMOL runtime rather than self-hosting. The README is dense and badge-heavy, with the provider count stated as 1,000+ in the body and 1,500+ in the registry tagline, so anyone depending on an exact catalog size should verify it against the live /v1/catalog endpoint.

flowchart LR
  Agent["AI Agent / App"] -->|"SDK / CLI / MCP / HTTP"| Gateway["OpenConnector Gateway"]
  Gateway --> Auth["Credential & OAuth Boundary"]
  Gateway --> Catalog["Provider Catalog"]
  Gateway --> Actions["Open-source Action Executors"]
  Gateway --> Policy["Tokens, Scopes, Allow/Block Policy"]
  Gateway --> Logs["Run Logs"]
  Actions --> Providers["1,000+ Providers"]
  Console["Web Console"] --> Gateway
  Cloudflare["Cloudflare Workers, D1, R2"] -. deploy .-> Gateway