OpenConnector: Give AI Agents Access to 1,000+ SaaS Providers

Building an AI agent that can chat or write code is no longer the hard part. The real friction starts when that agent must connect to Gmail, Notion, Slack, GitHub, Google Sheets, and internal systems.

Every service brings a different API, OAuth flow, token-refresh mechanism, permission model, parameter schema, retry policy, and logging requirement. Once the number of integrations grows from a few to dozens, spreading that logic across agents and scripts becomes expensive to maintain and increases the risk of credential exposure.

OpenConnector, released as open source by OOMOL Lab, is designed for this integration layer.

One-sentence positioning

OpenConnector is an open-source connector gateway for AI agents. A user connects an application account once, and agents can invoke standardized SaaS Actions through an SDK, CLI, MCP, HTTP, or OpenAPI.

It centralizes credentials, OAuth configuration, permissions, Action contracts, and run logs in an inspectable runtime. Agents decide which tools to use, but they do not need direct access to the raw Gmail, GitHub, or Notion tokens.

Basic information

The project describes itself as an open-source alternative to Composio. Its catalog covers services such as GitHub, Gmail, Notion, BigQuery, Google Analytics, Supabase, Airtable, and Slack.

What problem does it solve?

1. Agents should not hold every account credential

The simplest way to integrate a tool is to give an agent an API key or OAuth token. That approach exposes sensitive credentials to model processes, plugins, and scripts, while making it difficult to control which service or account each agent may use.

OpenConnector keeps provider secrets behind the runtime boundary. The agent sees available Actions, parameter schemas, required scopes, safe account labels, and execution results—not the raw token.

2. SaaS APIs differ too much

Services differ in authentication, request parameters, response formats, OAuth app registration, callback URLs, scopes, and token-refresh behavior.

OpenConnector describes those differences through a shared Provider Catalog and Action contracts. An agent can discover an Action, inspect its input/output schema and required permissions, then execute it through a consistent interface. Adding another service no longer requires the agent layer to implement a complete adapter from scratch.

3. Tool access must be inspectable and governable

When an agent can send email, edit documents, query analytics, or operate production systems, being able to call an API is only the first requirement. Teams also need to know which connection was used, which Action ran, whether it was allowed, whether it failed, and whether the call can be traced.

OpenConnector provides runtime tokens, scopes, Action allow/block policies, separate provider-proxy policies, temporary file transit, and redacted run logs. This turns scattered tool scripts into a more centralized control plane.

Core capabilities

A shared catalog of 1,000+ providers

The official catalog contains more than 1,000 providers and 10,000 prebuilt Actions across work applications, developer tools, data platforms, marketing systems, communications, and AI services.

Each provider can declare API-key, OAuth2, custom-credential, or no-auth connection methods. Action metadata exposes request parameters, response schemas, and permission requirements.

Five integration paths

OpenConnector does not force every agent to use the same protocol:

• Application code can use the Connector SDK.
• Local agents can relay requests through oo CLI.
• MCP-capable agent hosts can connect to /mcp.
• Custom services can call the HTTP API directly.
• Other clients can consume the generated OpenAPI document.

The same provider IDs, Action IDs, and schemas are shared between the open-source self-hosted runtime and OOMOL’s hosted service.

Local web console

The bundled Web Console lets operators browse providers, search Actions, configure API keys or OAuth clients, create runtime tokens, inspect Action schemas, debug calls, and review recent runs.

For teams operating and troubleshooting agent tools, this is more practical than maintaining every connection only in configuration files.

Multiple deployment options

OpenConnector can run locally with Docker or Node.js. It also supports Fly.io and Cloudflare, where Workers run the gateway, D1 stores state, R2 handles transit files, and Static Assets serve the console.

Teams that do not want to register and maintain OAuth applications for every provider can use OOMOL-hosted connectors. The self-hosted version includes the OAuth flow, credential storage, and token refresh, but operators must still register their own OAuth applications with each provider.

Security boundaries must be configured

OpenConnector handles account credentials and real business data. Its local-development defaults should not be exposed directly to the public internet.

At minimum, configure these controls:

1. Set OOMOL_CONNECT_ENCRYPTION_KEY so credentials, OAuth client configuration, and selected sensitive responses are encrypted with AES-256-GCM.
2. Set OOMOL_CONNECT_ADMIN_TOKEN to protect the Web Console, administrative API, and documentation.
3. Use runtime tokens, Action allow/block rules, and provider-proxy policies to give each agent only the services it needs.

Without an encryption key, the runtime still works for local development, but credentials and related sensitive records are stored in plaintext in SQLite or D1. OpenConnector does not store the encryption key for you; losing it makes encrypted records unrecoverable.

Who is it for?

Teams building agent products can use it to centralize user authorization for Gmail, Slack, Notion, GitHub, and other services.

Organizations requiring private deployment can keep credentials, run logs, and permission policies on infrastructure they control.

Developers using MCP can expose one shared SaaS Action catalog to multiple agent hosts instead of maintaining a separate MCP server for every service.

Teams evaluating connector platforms such as Composio can use OpenConnector to test whether a self-hosted gateway fits their cost, compliance, and extensibility requirements.

Quick start

The simplest path uses the official prebuilt image:

git clone https://github.com/oomol-lab/open-connector.git
cd open-connector
docker compose up

Then open:

http://localhost:3000
http://localhost:3000/docs

Run a no-auth Hacker News Action to verify the runtime:

curl -s -X POST http://localhost:3000/v1/actions/hackernews.get_top_stories \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

After the runtime works, configure the encryption key and admin token, then start with a provider such as GitHub that supports personal access tokens. For OAuth2 providers, first register an OAuth application on the provider platform, then add the client ID, client secret, and callback URL to OpenConnector.

Conclusion

OpenConnector’s main value is not only the size of its connector catalog. It centralizes the parts of agent-to-SaaS access that are easiest to lose control of: credentials, OAuth, permissions, Action contracts, and run records.

As a project grows from a few fixed APIs to multiple services, an independent gateway lets several agents reuse the same integration layer while giving security policy and operational troubleshooting a clear home.

If you are building an agent that must work across many external services, OpenConnector is worth evaluating in a local Docker environment. Verify a no-auth Action first, connect a test account next, and enable encryption, authentication, and least-privilege rules before using it with real business data.

Project: https://github.com/oomol-lab/open-connector