TL;DR
“Open source” is one of the most common requirements when engineers pick an API integration platform for their AI agents and SaaS products. It promises three things: no vendor lock-in, a credential store you can inspect, and integrations you can extend rather than wait on a vendor’s catalog.
Most tools publish only an open-source SDK, while the runtime that stores your customers’ credentials and runs your integrations remains closed. Nango is the exception in this comparison.
This post compares four platforms by which parts of each are actually open source, from the client SDK to the runtime that stores credentials:
- Nango: The integration platform where coding agents build API integrations and your product consumes them across 800+ APIs. The whole platform is open source under the Elastic License 2.0, and integrations are code you own in your repo.
- Composio: A large hosted catalog of agent tools. The SDK is MIT, but the runtime that stores credentials and runs tool calls is closed source, and a May 2026 security incident forced customers to rotate keys and have their users re-authorize.
- Arcade.dev: An MCP runtime with per-user OAuth. The tool-building framework is MIT, but the engine that holds tokens and executes calls is a closed binary.
- Superglue: An open-source tool that uses an LLM to generate integrations on the fly. Useful for one-off integrations, but there is no prebuilt connector catalog, no managed data syncs or webhooks, and per-customer auth sits behind a paid tier.
Why open source matters for AI agent integrations
An integration platform holds three sensitive things: the OAuth tokens and API keys for your customers’ accounts, the data those APIs return, and the code that runs against them. Open source decides how much of that you can see and control.
For teams building AI agents, three properties matter:
- You can inspect the code that holds credentials. A security reviewer can read how tokens are stored, encrypted, and refreshed instead of trusting a marketing page. Where those credentials live matters too. When they sit in one closed vendor cloud, a breach of that single system exposes every customer at once. Composio’s May 2026 security incident exposed around 10,242 customer credentials and forced every customer to rotate keys and have their users re-authorize. An open, self-hostable platform lets you keep credentials on infrastructure you control and audit.
- You avoid lock-in. When integrations are code you own, you can move them, fork them, and keep running them. When they are entries in a vendor’s catalog, you migrate by rewriting.
- You can extend it. A coding agent like Claude Code, Cursor, or Codex can read an open integration, change it, and ship a new one. A closed catalog only lets you consume what the vendor already built.
The problem is that “open source” has become a label applied to a client SDK. The repo with the stars is often a thin wrapper. The part that matters for an integration platform, the runtime that stores credentials and executes calls, runs on the vendor’s cloud and has no public source.
What counts as open source for an integration platform
The test is whether you can read, run, and self-host the component that stores your customers’ credentials and executes your integrations. That is the runtime. An open SDK, CLI, or MCP wrapper does not make the platform open source. It is client tooling, not the core infrastructure.
The word “open source” also spans a few license types:
- Permissive (MIT, Apache-2.0): Use, modify, and redistribute with almost no restrictions.
- Source-available (Elastic License 2.0, Functional Source License): Read, self-host, modify, and embed the code in your product. These carry limits, usually that you cannot resell the software as a competing managed service, but for a team that wants to run and extend the platform they behave like open source.
- Proprietary: No public source.
What to look for in an open-source platform for AI agents
- An open, self-hostable runtime and credential store: The source for the part that stores tokens and runs integrations should be public, and you should be able to run it yourself. Check the actual repo, not the SDK.
- Code-first integrations you own: Integrations should be code in your repo, version controlled and reviewable, so you are not locked into a catalog you cannot inspect or change.
- Coding agents can build on it: A skill or harness that lets Claude Code, Cursor, or Codex research an API, write an integration, test it against a real connection, and deploy it.
- More than tool calls: Data syncs to keep agent context fresh for RAG, webhook processing and triggers to react to events, and per-customer configuration for tenant-specific behavior.
- White-label, per-customer auth: Each of your customers connects their own account under your brand, with token refresh handled for you.
- Observability and compliance: Full request and response logs that both humans and agents can read, plus the certifications that regulated buyers ask about.
The best open-source API integration platforms for AI agents
1. Nango
Nango is the integration platform where coding agents build API integrations. Engineers or coding agents like Claude Code, Cursor, and Codex, write integrations as code in your repo using the Nango AI builder skill. Nango’s runtime executes them securely and at scale, covering auth, tool calls, data syncs, webhooks, and triggers across 800+ APIs. It is open source under the Elastic License 2.0; you can self-host it, and hundreds of fast-growing AI companies use it as core infrastructure.
What is open
The whole platform source is public under the Elastic License 2.0: the auth layer, the credential store, the proxy, and the execution runtime. You can read it, fork it, self-host it, and embed it in your product. The integrations themselves are TypeScript functions that live in your own repo, so that code is yours. Nango also publishes a library of integration templates you can clone and customize as a starting point.
Best for
Teams building AI agents or SaaS products that want an integration platform they can read, extend, and self-host, where coding agents build the integrations, and the AI agents and features in their product consume them across hundreds of APIs.
Pros
- The runtime and credential store are open source: You can read how tokens are stored, encrypted, and refreshed, and audit them in a security review. In self-hosted deployments, tokens live in your own database and are encrypted at rest with your own key. This is the component that the other platforms here keep closed.
- Open code and a sandboxed runtime, so security teams can sign off: Because the platform is open source, your engineers and the wider community can review how credentials are handled instead of trusting a vendor’s cloud. The execution runtime isolates each run, so one customer’s integration cannot reach another’s. See how Nango runs untrusted customer code at scale for the architecture.
- AI builder skill for 18+ coding agents: One command installs the skill. It gives Claude Code, Cursor, Codex, Gemini CLI, and others the context to research an API, write the integration, and test it against a real connection. See the walkthrough of building a real-time Google Calendar integration.
# Install the Nango builder skill for your coding agent
npx skills add NangoHQ/skills -s building-nango-functions
-
Test generated code against real APIs: The Nango CLI ships a
nango dryruncommand that runs generated code against a real connection and returns real responses, so the agent iterates on actual errors instead of hallucinating endpoints. The remote function builder lets a coding agent compile, dry-run, and deploy an integration without a local project, straight from a prompt. - Code-first integrations you own, with no catalog lock-in: Integrations are functions in your repo, deployed through CI/CD. A coding agent can fork a template, change a field, or add an API that Nango does not cover yet. You are never blocked waiting for a vendor to add a connector.
- Built-in MCP server and typed tool calls: Every action is a deterministic tool call over both a REST API and a hosted MCP server, with strict input and output schemas so the model does not guess parameters.
- Beyond tool calls on the same platform: Durable incremental data syncs keep data fresh for RAG, webhook processing and polling triggers react to provider events, and per-customer configuration adapts behavior per tenant without forking code.
- White-label auth across 800+ APIs: A drop-in Connect UI handles OAuth, API keys, JWT, basic auth, and MCP Auth, with token refresh built in. Your end users authorize under your brand, not the platform’s.
- Observability built for agents: Every operation produces structured logs with full request and response details, exported through OpenTelemetry. A coding agent can read a failing run and ship a fix on its own.
- Enterprise compliance: SOC 2 Type II, GDPR, and HIPAA, with a BAA available on request.
Cons
- Free self-hosting covers auth and the proxy; the full runtime is a paid tier: You can self-host the auth layer and the API proxy for free. Running the complete platform yourself, with functions, data syncs, webhooks, and the MCP server, needs Enterprise self-hosting. Most teams use Nango Cloud, which the Nango team runs for you, so you ship integrations without provisioning and operating your own servers.
2. Composio
Composio is a hosted tool-calling platform for AI agents. It provides agents with managed OAuth and a single MCP endpoint to access a large catalog of app toolkits.
What is open
The Python and TypeScript SDKs, the CLI, and the framework adapters are MIT-licensed. The part that matters is not. The backend that stores your customers’ OAuth tokens and executes tool calls is closed source and runs on Composio’s cloud. The prebuilt tools are closed too, so you cannot read or modify them. An open SDK sits on top of a proprietary platform.
Best for
Teams that want a large hosted catalog of pre-built agent tools and are comfortable with a closed runtime where credentials live in the vendor’s cloud. A reasonable fit for internal productivity or personal automation agents.
Pros
- Large catalog: Over 1,000 app toolkits, with a Tool Router that selects relevant tools to keep the agent’s context small.
- MIT-licensed SDKs with broad framework support: Adapters for OpenAI, Anthropic, LangChain, CrewAI, and others.
- Managed per-user auth: Connected accounts are scoped to your user IDs and automatically refresh tokens. SOC 2 Type II and ISO 27001 certified.
Cons
- A closed cloud that concentrates credentials, with a track record: In May 2026, a breach of Composio’s systems exposed around 10,242 customer credentials, including 5,001 GitHub OAuth tokens and roughly 5,241 API keys. Composio deleted all existing API keys and required every customer to rotate keys. Because it could not revoke connected-account tokens on its own, customers had to ask their end-users to re-authorize. An independent analysis traced the scale of the exposure to credentials being aggregated in a single closed cloud. The platform is closed source, so customers could not inspect what ran or verify the fix, and no detailed root-cause postmortem was published.
- The runtime and credential store are closed: On every tier except enterprise, your customers’ tokens sit in Composio’s cloud, and every call routes through its backend. You cannot inspect or self-host the part that matters most.
- You cannot deploy your own connector: Custom tools are limited, and there is no path for a coding agent to author a new integration and ship it to Composio’s runtime. You consume the catalog, you do not extend it.
- Tool calls only: There is no managed data sync layer for RAG, and there is no first-class webhook ingestion. Event-driven and scheduled work lives elsewhere.
For a deeper comparison, see the Composio vs Nango head-to-head and the best Composio alternatives.
3. Arcade.dev
Arcade is an MCP runtime for agent tool calling, built around per-user authorization. When a tool call lacks a user grant, the Arcade Engine runs the OAuth flow, stores the tokens, and injects them at call time, so credentials never enter the model context.
What is open
The arcade-mcp framework for building tools is MIT-licensed. The engine is not. The component that stores credentials and runs your tool calls ships as a closed binary with no public source. As with Composio, the open part is the client tooling, not the infrastructure that holds your customers’ tokens.
Best for
Teams building MCP-first agents that only need tool calls to APIs, and do not need webhooks, triggers, data syncs, or a coding-agent skill for building and shipping integrations.
Pros
- Per-user OAuth built for agents: Authorization is checked before execution and tokens never enter the model context, which is a sound security model.
- MIT framework for custom tools: You can build and package custom MCP servers with an open framework, with skills for Claude Code and Cursor that scaffold new tools.
- Open-ecosystem signals: Arcade joined the Linux Foundation’s Agentic AI Foundation as a Gold Member in December 2025.
Cons
- The engine is a closed binary: The exact component that stores end-customer credentials and executes calls has no public source, so you cannot audit or fork it.
- Tool calls only: No data syncs to feed agent context, no webhook ingestion, no scheduled triggers.
- Catalog-bound, not white-label embedded: It is designed for an agent to consume a shared tool catalog, not for a SaaS to offer per-customer, white-label auth to its own end customers. The first-party catalog is roughly 112 integrations.
- Full self-hosting is enterprise-only: Running the binary yourself is free, but production on-premise deployment is gated to a sales contract, and the engine stays closed wherever it runs.
4. Superglue
Superglue takes a different approach. Instead of a fixed catalog, you describe an integration task in natural language and its LLM pipeline generates the integration code, runs it against the target API, and self-heals when the API drifts.
What is open
Superglue is more open than Composio and Arcade. It publishes the runtime itself as open source, including the server, dashboard, and credential store, which you can run with docker compose up. Tokens stay in your own database. Two things narrow it down for a product team. The license is the Functional Source License, which lets you self-host and modify the code but restricts its use for building a competing commercial product for two years after each release. The multi-tenant features of a customer-facing product, per-end-user credentials, role-based access, and a white-label portal are included in the paid Enterprise Edition, so the free core is effectively single-tenant.
Best for
Teams that want an LLM to generate one-off integrations against arbitrary REST, GraphQL, or SQL sources, and do not need a prebuilt connector catalog or per-customer auth in the free version.
Pros
- Open-source runtime you can self-host for free: Credentials stay in your own database, with your encryption key. You bring your own LLM provider key.
- Coding-agent-first by design: It ships a skill for Claude Code and Cursor and an MCP server, and the integration is generated rather than picked from a catalog.
- Self-healing integrations: When an upstream response changes, the pipeline attempts to repair the integration automatically.
Cons
- The license restricts embedding it in a product: The Functional Source License lets you self-host and modify the code, but you cannot use Superglue to build a competing commercial product until two years after each release. For a team embedding an integration platform in their own product, that is a real constraint.
- Embedded multi-tenancy is paid: Per-customer credentials, role-based access, and white-label auth, the core of an embedded use case, sit in the Enterprise Edition, not the free core.
- LLM-generated integrations need review: Each integration is generated against the API you point it at, so correctness depends on the API’s docs and the self-heal loop. There is no library of tested, maintained connectors to fall back on, so you review and test the generated code before it goes to production.
- Not a full integrations platform: It generates and runs integrations, but it does not offer durable incremental data syncs at scale or first-class webhook ingestion in the free core, so it covers less ground than a platform like Nango.
Open source by component
A GitHub repo alone does not tell you what is open. This table breaks each platform down by component: the runtime that stores credentials, the license, and the prebuilt connectors.
| Component or property | Nango | Composio | Arcade.dev | Superglue |
|---|---|---|---|---|
| Runtime and credential store open source | Yes | No | No | Yes |
| Platform license | Elastic License 2.0 | Proprietary (MIT SDK only) | Proprietary (MIT framework only) | Functional Source License |
| Who holds credentials (self-serve) | You (self-host) or your Nango account | Composio cloud | Arcade cloud, or your backend if you run the binary | You (your database) |
| Self-host the full runtime | Free + Enterprise | Enterprise only (closed images) | Partial (free binary, on-prem is Enterprise) | Free + Enterprise |
| Integrations you own as code | Yes | No (catalog) | Partial (tools via SDK) | Yes (generated) |
| Coding agents build integrations | Yes (18+ agents, dry-run) | No | Partial (author tools, closed runtime) | Yes (LLM-generated) |
| Data syncs and webhooks | Yes | No | No | Partial |
| White-label per-customer auth | Yes | Partial | Limited | Enterprise only |
| Prebuilt connectors | 800+ (open templates) | 1,000+ (closed) | ~112 | None (bring your own API) |
Catalog counts use each vendor’s own unit (APIs, toolkits, integrations) and are not directly comparable.
How to choose
- You want an open, self-hostable platform where coding agents build integrations and your product consumes them across hundreds of APIs: pick Nango. It is the broadest option here, with an open-source runtime, code-first integrations you own, and data syncs and webhooks alongside tool calls.
- You want a large hosted catalog of agent tools and accept a closed runtime with credentials in the vendor cloud: Composio fits, best for internal or personal automation agents. Weigh its May 2026 security incident and the closed-source risk before putting it on the path of production credentials.
- You want per-user OAuth for MCP tool calling and tool calls are your whole scope: Arcade.dev is worth a look, if a closed engine and no syncs or webhooks are acceptable.
- You want an LLM to generate one-off integrations against arbitrary APIs: Superglue is interesting. For a product that needs a connector catalog, managed syncs and webhooks, and per-customer auth, Nango is the broader fit.
FAQ
What is the best open-source API integration platform for AI agents?
Nango is the strongest open option for AI agents in 2026. Its runtime, connectors, and templates are open source under the Elastic License 2.0, so you can inspect, fork, self-host, and embed it. Integrations are code you own in your repo, and coding agents like Claude Code, Cursor, and Codex can build new ones directly against it, with data syncs and webhooks on the same platform.
Is Composio open source?
No. Composio’s Python and TypeScript SDKs are MIT-licensed, but the part that matters, the runtime that stores your customers’ credentials and executes tool calls, is closed source. The prebuilt tools cannot be inspected or modified, and a May 2026 security incident exposed credentials stored in that closed cloud.
Is Arcade.dev open source?
No. Arcade’s arcade-mcp tool-building framework is MIT-licensed, but the Arcade Engine that stores credentials and runs tool calls is a closed binary with no public source. Full on-premise deployment is enterprise-only, and the engine stays closed wherever it runs.
Is Nango open source?
Yes. Nango is open source under the Elastic License 2.0. You can read the code, self-host it, modify it, and embed it in your product. You can audit how credentials are stored, run it on your own infrastructure, and extend any integration as code in your repo.
Can I use n8n or Activepieces for customer-facing product integrations?
Both are built for internal workflow automation, and their licenses reflect that. n8n’s Sustainable Use License limits use to internal business purposes, so embedding it in a customer-facing product needs a separate commercial license. Activepieces has an MIT core, but its embedding and white-label features sit in a paid enterprise edition.
Can I use these platforms with LangChain, CrewAI, or the OpenAI Agents SDK?
Yes. All of them expose integrations through some combination of REST APIs, MCP servers, and SDKs that work with the popular agent frameworks.
Conclusion
Most platforms in this category publish an open-source SDK while the credential store and runtime stay on the vendor’s cloud. Composio and Arcade both keep the engine that holds your customers’ tokens closed, and Composio’s May 2026 breach showed what that concentration of credentials can cost. Superglue does publish its runtime, but its license restricts embedding it in a product, and its multi-tenant features and connector coverage push a product team toward the paid tier.
Nango is the broadest open option of the four. The platform is open source under the Elastic License 2.0, integrations are code you own in your repo, and you can self-host it. Coding agents build the integrations, the AI agents in your product consume them through an MCP server, tool calls, data syncs, and webhooks, and the same code runs on a tenant-isolated runtime you can read and audit.
If you want to try the Nango AI builder skill with your favorite coding agent, follow the Nango functions guide to get started.
Related reading
- Best self-hosted API integration platforms for AI agents
- Best agentic API integrations platform in 2026
- Best API integration platforms to use with Claude Code, Cursor, and Codex
- Best Composio alternatives for AI agent integrations in 2026
- Composio vs Nango: a developer’s comparison for production AI agent integrations
- A guide to secure AI agent API authentication
- The emergence of just-in-time integrations








Top comments (0)