OpenConnector
A self-hostable gateway for letting AI applications use users’ authorized SaaS accounts.
- Source repo
- oomol-lab/open-connector
- Stars
- ★ 6.2k
- Last updated
- today
- License
- NOASSERTION
- Primary language
- TypeScript
- FA score
- 57/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platform
- Cost
- Free tier plus a paid hosted plan
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A team building an enterprise assistant that must use each user’s authorized GitHub, Gmail, Notion, Slack, or Airtable account without placing credentials in the agent process.
- Not a fit if
- Teams that want OAuth working out of the box without registering their own provider apps
- Users who need fully offline operation with no hosted runtime or third-party APIs
- Teams unwilling to operate their own database, object storage, and runtime infrastructure
- Source review
- 57/100 · Major gaps
What does this agent do, and when should you use it?
OpenConnector is an open-source connector gateway that routes AI application requests to actions for users’ authorized SaaS accounts. It exposes a catalog described as covering more than 1,000 providers and 10,000 prebuilt Actions, with API-key, OAuth2, custom-credential, and no-auth support. Clients can discover and execute Actions through the Connector SDK, the oo CLI, MCP, HTTP endpoints, or generated OpenAPI. The runtime manages connection identity, scopes, runtime tokens, action allow/block policies, temporary file transit, and redacted run logs so provider secrets remain behind its boundary. It can run locally with Docker or Node.js, on Fly.io, on Cloudflare Workers with D1 and R2, or through OOMOL’s hosted runtime.
A client browses the provider catalog, inspects an Action’s request/response schemas and required scopes, selects a connection alias, and executes the Action through the gateway. A self-hosted instance can store a GitHub connection with PUT /api/connections/github and invoke POST /v1/actions/github.get_current_user; POST /v1/actions/hackernews.get_top_stories provides a no-auth verification call. MCP-capable hosts can use http://localhost:3000/mcp, while custom clients can call /v1/actions/* and inspect /openapi.json. The Web Console supports provider browsing, credential configuration, runtime-token creation, schema inspection, Action debugging, and recent-run review.
- A team building an enterprise assistant that must use each user’s authorized GitHub, Gmail, Notion, Slack, or Airtable account without placing credentials in the agent process.
- An engineer adding SaaS tool execution to an existing AI product through documented HTTP endpoints or a generated OpenAPI description.
- A local developer using an MCP-capable host who wants connected application Actions exposed at http://localhost:3000/mcp.
- A team that wants to operate the connector runtime in its own Cloudflare account using Workers, D1, R2, and static console assets.
- An operator investigating authorization, scope, or Action-call problems through schema inspection, debugging, and redacted runtime logs.
How do you install or deploy this agent?
For a local self-hosted runtime:
docker compose upThis pulls ghcr.io/oomol-lab/open-connector:latest. To build from source instead:
docker compose -f docker-compose.yml -f docker-compose.build.yml up --buildThe console is then available at http://localhost:3000 and API documentation at http://localhost:3000/docs. Source development requires Node.js 22 or newer, followed by npm install and npm run dev. OAuth providers require client credentials that you register with the relevant providers; the GitHub example can use a personal access token.
How do you use this agent?
First verify the runtime with a no-auth Action:
curl -s -X POST http://localhost:3000/v1/actions/hackernews.get_top_stories \
-H 'content-type: application/json' \
-d '{"input":{}}'Then configure and test GitHub:
curl -s -X PUT http://localhost:3000/api/connections/github \
-H 'content-type: application/json' \
-d '{"authType":"api_key","values":{"apiKey":"github_pat_..."}}'
curl -s -X POST http://localhost:3000/v1/actions/github.get_current_user \
-H 'content-type: application/json' \
-d '{"input":{}}'Applications can alternatively use the Connector SDK, oo connector, MCP, or /v1/actions/*; inspect /openapi.json for the generated API contract.
What are this agent's strengths and limitations?
- The same provider IDs, Action IDs, schemas, and contracts are intended to work across open-source self-hosted and OOMOL SaaS deployments.
- It offers five documented integration surfaces: Connector SDK,
oo connector, MCP, HTTP, and OpenAPI. - The runtime includes inspectable controls for connection identity, scopes, tokens, Action policies, and redacted run logs.
- Deployment paths span local Docker/Node.js, Fly.io, Cloudflare Workers, and an OOMOL-hosted runtime.
- Self-hosted OAuth integrations require you to register, configure, and manage OAuth client credentials for each provider.
- The Cloudflare path depends on Cloudflare Workers, D1, R2, and Static Assets.
- Local and Fly.io deployments use SQLite persistence, leaving storage and runtime operations to the deploying team.
- The supplied material states catalog totals but does not enumerate the supported scope or behavior of every provider and Action.
How does this agent compare with similar options?
OpenConnector describes itself as an alternative to Pipedream and Composio. Its documented distinction is a self-hostable, inspectable runtime with shared provider and Action contracts across self-hosted and OOMOL-hosted deployments; no feature matrix or migration tooling is described.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| OpenConnector This agent | 57 · Major gaps | Self-hosted serviceFreemium | ★ 6.2k | today | TypeScript | — |
| Agentica — AI Function Calling Framework | 49 · Major gaps | CLIFree + model costs | ★ 1k | 5mo ago | TypeScript | ChatGPT · Claude.ai · OpenAI API · Claude API |
| Agent Kanban | 80 · Good | Self-hosted serviceFree | ★ 496 | 1mo ago | TypeScript | — |
| Create Context Graph | 55 · Major gaps | CLIFree + model costs | ★ 745 | 28d ago | Python | ChatGPT · Claude Code · Claude.ai · OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows: README and SECURITY.md describe credential storage, encryption, tokens, policies, and log redaction, but implementation details are not provided. CI workflow uses least privilege (contents: read). Deductions: user confirmation mechanism not explicit, dependency security only lists dependencies without vulnerability scanning or audit evidence.
Evidence shows: README and docs describe multiple deployment modes, CI includes lint, typecheck, and tests. Deductions: failure messages not detailed, dependency availability not verified.
Evidence shows: README describes multiple usage scenarios (SDK, CLI, MCP, HTTP) and deployment options (local, Cloudflare, Fly.io, OOMOL). Deductions: trigger precision (e.g., Action invocation) not detailed, environment fit lacks specific configuration examples.
Evidence shows: README provides installation, usage, deployment docs, has LICENSE.txt (Apache-2.0), has version number (1.3.5). Deductions: known limitations not explicitly listed, version changelog not provided.
Evidence shows: README describes outputs (Action results, logs) and marginal value (connect once, use everywhere). Deductions: cost-benefit not quantified, output usability lacks concrete examples.
Evidence shows: README claims (e.g., 1000+ providers) have links, but no independent verification. Deductions: cross-source corroboration insufficient, facts and inferences not clearly separated.
- Static review, no code execution, all conclusions based on documentation and config files.
- Dependency security lacks vulnerability scanning or audit evidence; check dependencies yourself.
- User confirmation mechanism not explicit; verify actual behavior.
- Known limitations not listed; assess yourself.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
What's Changed * feat(oomol-rag): add atomic block-level article editing by @alwaysmavs in https://github.com/oomol-lab/open-connector/pull/844 Full Changelog: https://github.com/oomol-lab/open-connector/compare/v1.9.8...v1.9.9View on GitHub ↗ -
Release notes excerpt
What's Changed * feat(oomol-rag): accept Markdown for article creation and updates by @alwaysmavs in https://github.com/oomol-lab/open-connector/pull/843 Full Changelog: https://github.com/oomol-lab/open-connector/compare/v1.9.7...v1.9.8View on GitHub ↗ -
Release notes excerpt
What's Changed * fix(oomol-rag): preserve gateway rejection status by @alwaysmavs in https://github.com/oomol-lab/open-connector/pull/842 Full Changelog: https://github.com/oomol-lab/open-connector/compare/v1.9.6...v1.9.7View on GitHub ↗
FAQ
Do agents receive provider credentials directly?
Can I use OAuth when self-hosting?
Which interfaces can call the gateway?
oo connector CLI, MCP at http://localhost:3000/mcp, HTTP /v1/actions/*, and the generated /openapi.json document.