open-connector is a free, open source api development & testing project written in TypeScript and released under a custom open-source licence. It has 6,163 GitHub stars, 586 forks and 0 open issues, and was last pushed 16 hours ago. On this registry it ranks #36 of 186 tracked projects in API Development & Testing, with 5 head-to-head comparisons available. It gained 231 stars over the last 30 tracked days.

What is open-connector?

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.

project readme (upstream, from github) — read inline

English | 简体中文 | 繁體中文 | 日本語 | 한국어 | Русский | Français | Español

License: Apache-2.0 Node.js 22+ Cloudflare compatible MCP OpenAPI

Providers Actions

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. Cloudflare, Fly.io, RepoCloud, nibrun, and more.
🚀 OOMOL Hosted Self-host More platforms

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.

OpenConnector connector catalog dashboard

Usage Overview

Use the Overview page after deployment to monitor runtime readiness, available providers, executable Actions, recent failures, tool call trends, and recent calls.

OpenConnector runtime overview dashboard

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
Open-source self-host Developers and teams that want full control Local Docker or Node runtime, SQLite or PostgreSQL state, local or S3-compatible transit files, MCP, HTTP, OpenAPI, and Web Console
Kubernetes (Helm) Teams that run their own clusters Hardened Helm chart with PVC-backed SQLite or PostgreSQL plus migration hooks, Ingress, autoscaling, and NetworkPolicy toggles
OOMOL Teams that want users to authorize accounts immediately OOMOL-provided OAuth apps, monthly included Connect credits, and hosted runtime infrastructure; the same provider and Action contracts keep a path open to later private or self-hosted deployment

Quick Start

[!NOTE] This starts a self-hosted runtime. OAuth providers require OAuth client credentials from apps you register with those providers. To let users authorize supported providers without setting up your own OAuth apps, use OOMOL-hosted connectors.

Start the runtime from the published image with Docker Compose:

docker compose up

This 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 --build

Open the local console and generated API reference:

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

Run a no-auth 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":{}}'

See docs/quickstart.md for the full local setup, first provider connection, OAuth flow, and runtime settings.

Connect a Provider

GitHub is the simplest credentialed example because it can use a personal access token:

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":{}}'

For OAuth2 apps, named connections, credential encryption, token refresh, and action policies, see docs/credentials.md and docs/configuration.md.

Web Console

For npm-based local development, open http://localhost:5173; the Web Console dev server proxies API requests to the runtime on http://localhost:3000. For Docker or a built Node runtime, the console is served from http://localhost:3000.

The console supports provider browsing, API key and OAuth client configuration, runtime token creation, Action schema inspection, Action debugging, recent run review, and access to the generated OpenAPI and MCP metadata.

PostgreSQL Runtime Storage

The Node runtime uses SQLite by default and can use PostgreSQL 15 or newer when OOMOL_CONNECT_DATABASE_URL is configured. PostgreSQL migrations are explicit: run npm run runtime:migrate before starting a version with pending migrations. Server startup only checks schema readiness and never applies PostgreSQL DDL. See docs/configuration.md for configuration, permissions, TLS, and multi-instance requirements. The Docker image exposes the same runner as its migrate subcommand; see docs/docker-ghcr.md.

Docker Image (GHCR)

Run OpenConnector from a prebuilt image on GitHub Packages (GHCR): ghcr.io/oomol-lab/open-connector. Use latest for the newest release, a pinned released version for production, or tip for the latest main build.

See docs/docker-ghcr.md for tags, pulling, and running.

Build a Desktop Agent with Wanta

OpenConnector and Wanta are two open-source projects for AI Agents in the OOMOL ecosystem. OpenConnector connects Agents to external services such as Gmail, Slack, and Notion. Wanta provides a complete desktop Agent application powered by OpenCode and uses OpenConnector to work with connected SaaS services.

  • Run locally: Use your own OpenAI-compatible model without creating a Wanta account.
  • Build your own: Fork Wanta and customize its prompts, tools, interface, models, and branding.
  • Use hosted services: The optional hosted experience provides managed models, OAuth connections, and team workspaces.

Issues and pull requests are welcome.

Documentation

Development

Use Node.js 22 or newer:

npm install
npm run dev

The local API runtime listens on http://localhost:3000. The Web Console dev server listens on http://localhost:5173 and proxies API requests to the runtime.

Before opening a pull request:

npm run fix-check
npm test

Provider code lives under src/providers/. See CONTRIBUTING.md for provider contribution rules.

License Scope

Unless otherwise noted, the source code, scripts, generated project scaffolding, tests, and documentation authored for this repository are licensed under the Apache License, Version 2.0. See LICENSE.txt.

The Apache-2.0 license for this repository does not grant rights to third-party products, providers, apps, APIs, trademarks, service marks, trade names, logos, icons, brand assets, documentation, screenshots, or other copyrighted materials owned by their respective holders.

Provider and app names, metadata, links, scopes, permissions, and optional logos/icons are included only to identify services and enable interoperability. All third-party brand and product rights remain with their respective owners. Inclusion in this catalog does not imply endorsement, sponsorship, partnership, certification, or verification by those owners.

If you contribute provider metadata or assets, only submit material you have the right to submit. Prefer linking to official public assets instead of copying brand files into this repository.

Community

Please keep issues and pull requests focused, respectful, and actionable. Participation in this project is governed by CODE_OF_CONDUCT.md.

Support OpenConnector

If OpenConnector is useful to you, giving it a ⭐ helps more developers discover the project.

Contributors

Thanks to everyone who has helped build OpenConnector. Want to join them? See CONTRIBUTING.md.

OpenConnector contributors

Star History

Frequently asked questions

Is open-connector free to use?

open-connector is open source. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does open-connector do?

Open-source auth gateway connecting 1500+ SaaS providers to AI agents through SDK, CLI, MCP, HTTP, and OpenAPI.

What is open-connector written in?

open-connector is primarily written in TypeScript. Its source is publicly available at https://github.com/oomol-lab/open-connector, and it has 6,163 GitHub stars.