open-connector
oomol-lab · oomol-lab/open-connector
This open-source gateway connects AI agents to over 1500 SaaS providers, enabling broad automation and data exchange.
Open-source auth gateway connecting 1500+ SaaS providers to AI agents through SDK, CLI, MCP, HTTP, and OpenAPI.
Preview
What you can do with it
- Automate tasks in GitHub, Gmail, or Notion directly from an AI agent.
- Integrate AI agent workflows with various databases like Supabase or Airtable.
- Connect to Google Analytics or other data sources for agent-driven data retrieval and analysis.
Safety check
Usable, but read the notes first.
- ●npm package runs a script automatically on install.
package.json
Automated scan of the repo files. Always review code you run.
From the README
English | 简体中文 | 繁體中文 | 日本語 | 한국어 | Русский | Français | Español
OpenConnector is an open-source connector gateway for AI agents and an alternative to Pipedream/Composio. Connect user app accounts once, then expose a shared catalog of 1,000+ providers and 10,000+ prebuilt Actions to agents and applications.
Managed OAuth and hosted runtime, ready to use. No deployment or OAuth app setup.
Run locally or on your own infrastructure with Docker or Node.js. You manage storage and OAuth apps.
<strong>Cloudflare</strong>, <strong>Fly.io</strong>, <strong>RepoCloud</strong>, <strong>nibrun</strong>, <strong>NEXUS AI</strong>, and more.
🚀 <strong>OOMOL Hosted</strong>
<strong>Self-host</strong>
<strong>More platforms</strong>
Use the Connector SDK from app code, oo CLI as the local-agent relay, MCP from agent hosts, HTTP/OpenAPI from custom clients, and the Web Console for administration and debugging.
- Keep credentials, scopes, schemas, policies, and run logs inside an inspectable runtime.
- Run locally, on your own infrastructure, or through OOMOL's hosted runtime.
- Use the same provider ids, Action ids, schemas, and contracts across open-source and commercial SaaS deployments.
What It Provides
- A working connector catalog across products such as GitHub, Gmail, Notion, BigQuery, Google Analytics, Supabase, Airtable, Slack, and more.
- 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, plus OOMOL's hosted runtime. Additional managed platforms are listed in deployment options.
Where It Fits
OpenConnector fits products where agents need durable access to the tools users already use, without handing provider credentials to the agent process.
- Agent products that need reusable access across work apps, developer tools, data systems, communication platforms, and AI services.
- 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.
Developer Tools
| Tool | Purpose |
|---|---|
| Connector SDK | Thin TypeScript HTTP client. Use OpenConnector for self-hosted runtimes, or Connector / ProjectConnector for OOMOL-hosted personal and SaaS end-user connections. |
| oo CLI | Local agent relay for connector Actions. oo connector can search, inspect, and run Actions against OOMOL-hosted or self-hosted OpenConnector runtimes. |
| MCP | Expose app Actions to MCP-capable agent hosts through http://localhost:3000/mcp. |
| HTTP / OpenAPI | Call /v1/actions/* directly or inspect the generated /openapi.json document. |
Endpoint details, response envelopes, auth headers, MCP tools, and Action guide examples are in docs/runtime-api.md.
Dashboard Preview
OpenConnector ships with a local Dashboard for browsing connectors, configuring credentials, creating runtime tokens, and inspecting runtime usage.
Connector Catalog
Use the connector catalog to see available services, search for providers, and open their Actions and credential setup from one place.
Usage Overview
Use the Overview page after deployment to monitor runtime readiness, available providers, executable Actions, recent failures, tool call trends, and recent calls.
Provider names and trademarks belong to their respective owners and are used only for identification and interoperability.
How It Works
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
Apps and agents discover Actions, inspect schemas and scopes, select a connection alias, and execute through the gateway. Provider secrets stay behind the runtime boundary; agents receive the metadata, safe account labels, and execution results needed for the run.
Usage Paths
| Path | Best for | Includes