DEV Community: Sapnesh Naik

Build a GitHub API integration for AI agents using Nango

Sapnesh Naik — Wed, 17 Jun 2026 18:01:20 +0000

This guide shows how to build a custom, customer-facing GitHub API integration that the AI agents in your product can act on, using Nango and an AI coding agent (Codex, Claude Code, Cursor, or any other).

By the end of this guide, you will have:

The ability for an AI agent in your product to create issues, comment on pull requests, and open PRs on a customer’s repositories, exposed as typed MCP tool calls instead of raw GitHub API parameters.
A GitHub auth UI in your product (Nango Connect) so your customers can connect their own GitHub account or install your GitHub App.
A durable sync that imports issues and pull requests from a customer’s repositories and keeps them up to date, so the agent always reasons over current data.
A signature-verified webhook handler that reacts to GitHub events (pushes, pull requests, issues) in real time.

Get the working example: the complete demo (frontend, backend, nango-integrations) is on GitHub at NangoHQ/github-api-integration. Clone it to run the whole thing end to end, or follow the guide below and let Codex generate the same functions in your own project.

What is a GitHub API integration?

A GitHub API integration connects your application or agent to a customer’s GitHub data (repositories, issues, pull requests, and commits) through GitHub’s REST and GraphQL APIs. It authenticates as a GitHub App or an OAuth App, reads data into your app with scheduled syncs, writes back with actions like creating issues or commenting on pull requests, and reacts to repository events through webhooks.

Example use cases: an AI agent that triages a customer’s issues and opens pull requests, an AI code-review product that comments on PRs, a project management tool that mirrors a customer’s issues, or a developer analytics dashboard.

Why is it hard to integrate the GitHub API into your app?

The GitHub REST API exposes repositories, issues, pull requests, commits, and webhooks. A production integration on top of it takes a few decisions up front, plus the infrastructure to keep them running.

The first is the auth type. For a customer-facing product, a GitHub App is usually the right call; reach for an OAuth App only when you are building a personal-developer tool that should act purely as the user.

Capability	GitHub App	OAuth App
Acts as	A bot/installation	The authorizing user
Fine-grained permissions	Yes, per resource	No, inherits the user's scope
Rate limit	5,000 to 12,500/hour (scales with org)	5,000/hour
Repository access	Only repos granted at install	Every repo the user can access
Best for	Customer-facing products	Personal-developer tools

See GitHub App vs. GitHub OAuth and GitHub’s own comparison for the full breakdown. The rest of the work is infrastructure:

The auth flow is not standard OAuth, and tokens are short-lived: GitHub App installation tokens expire after one hour. When “Expire user authorization tokens” is enabled (the default), user access tokens expire after 8 hours and refresh tokens after 6 months. A failed refresh shows up as the BAD_REFRESH_TOKEN error, usually after a rotated client secret or a revoked installation. Someone has to store, refresh, and encrypt all of this.
The Issues API also returns pull requests: GET /repos/{owner}/{repo}/issues returns both issues and PRs, and every pull request carries a pull_request field. Filter on it or you double-count.
Webhooks need signature verification: GitHub signs each delivery with the X-Hub-Signature-256 header (an HMAC-SHA256 of the raw body using your webhook secret). You verify it with a constant-time comparison before trusting the payload, and read the event type from X-GitHub-Event.
Pagination is header-driven: REST responses page through the Link header (rel="next", up to 100 items per page), and some data is only practical through GitHub’s GraphQL API, which has its own point budget.

Building all of this by hand takes weeks. With Nango and a coding agent like Codex, the same GitHub API integration ships in about an hour, the same workflow we used to build 200+ integrations across five APIs in 15 minutes.

Why use Nango for a GitHub API integration

Nango is the integration platform where coding agents build API integrations. An agent like Codex writes the integration as code in your repo, and Nango’s runtime runs it with managed auth, retries, and observability across 800+ APIs.

For a GitHub integration, we will use these Nango features:

Managed auth for GitHub Apps and OAuth: your product gets a customizable, white-label auth UI where customers install your GitHub App or authorize a GitHub OAuth app, while Nango handles installation and user tokens, refresh, encryption, and revocation behind it.
A function builder skill for Codex: to build your integration logic, Codex uses the Nango function builder skill. It researches the GitHub API, writes your actions and syncs from a prompt, tests them against a real GitHub connection, and iterates on real errors until its tests pass against your connection. The same skill works with Claude Code, Cursor, Gemini CLI, and other agents.
Integrations infrastructure for every use case:
- Actions: one-off operations like creating an issue, commenting on a PR, or opening a pull request.
- Syncs: scheduled functions that keep issues, PRs, and commits flowing into your app.
- Webhooks: receive GitHub events, verified, and route them to your integration in real time.
- MCP server: exposes your deployed actions as typed tools for the AI agents in your product.

Prerequisites

Sign up for Nango (the free tier is enough for development).
Add GitHub as an integration. Nango supports all the various GitHub auth types. In this demo, we’ll be registering a new GitHub App (the “GitHub App OAuth” type, integration ID github-app-oauth) with Nango’s callback URL https://api.nango.dev/oauth/callback.

Add a test connection: on the Nango dashboard, open the integration and select Connections > Add Test Connection, then authorize a GitHub account that owns a repository with a few issues and pull requests. While Codex builds your integration, it runs the generated code against this connection, so what ships has already worked against real data.
Give Codex a project to build in. Install the Nango CLI and run nango init: it creates a nango-integrations folder with the Nango framework bootstrapped. Set NANGO_SECRET_KEY_DEV (your dev API key, from Environment Settings in the dashboard) in nango-integrations/.env so it can test and deploy on your behalf.
Install the Nango skill. Run npx skills add NangoHQ/skills -s building-nango-functions-locally; the installer detects Codex and copies the skill to .agents/skills/, where Codex discovers it. The same skill works with Claude Code, Cursor, and other coding agents.

Tip: LLM training data on Nango is often stale. Add the Nango docs MCP server alongside the skill so Codex pulls current API references while it generates code: codex mcp add nango-docs --url "https://nango.dev/docs/mcp"

Sync a customer’s issues and pull requests into your app

A sync keeps a fresh copy of a customer’s GitHub data in your app. Here it imports the issues and pull requests from a connected repository, then refreshes on a schedule so new activity shows up without anyone clicking refresh.

You build it by prompting Codex with the Nango skill (type $ to mention a skill, or run /skills to browse):

$building-nango-functions-locally Build a Nango sync for the github-app-oauth integration that imports
the issues and pull requests from the repos a customer connects and keeps them up to date,
refreshing every hour. Integrate it with my frontend.

With the skill loaded, Codex:

Researches the GitHub API and the endpoints it needs.
Writes the sync and a typed model for your records.
Tests it against your real connection with nango dryrun.
Iterates on any errors until the sync works end to end.

// Codex generates this sync. You do not write it by hand.
export default createSync({
    description: 'Imports issues and pull requests from a connected repo and refreshes hourly.',
    frequency: 'every hour',
    autoStart: false, // starts once your app saves the repo metadata
    models: { GithubIssue },
    exec: async (nango) => {
        const { owner, repo } = await nango.getMetadata();
        for await (const issues of nango.paginate({
            endpoint: `/repos/${owner}/${repo}/issues`,
            params: { state: 'all', sort: 'updated', per_page: '100' },
        })) {
            // GET /issues returns pull requests too; the pull_request field tells them apart.
            await nango.batchSave(issues.map(toRecord), 'GithubIssue');
        }
    },
});

nango.paginate follows GitHub’s Link header for you, so you do not hand-roll pagination. The full sync, with the record model, incremental updates keyed on issue activity, and the onWebhook handler, is in fetch-issues-and-pull-requests.ts in the demo repo.

When Codex finishes, it deploys the sync for you (approve the deploy when it asks):

nango deploy --sync fetch-issues-and-pull-requests dev

Because the prompt said to integrate the frontend, Codex also wires Nango Connect into your app: customers install your GitHub App, pick which repositories to grant, and the sync starts on its own.

Your backend reads the synced records from Nango’s cache and serves them to your UI:

const { records } = await nango.listRecords({
    providerConfigKey: 'github-app-oauth',
    connectionId,
    model: 'GithubIssue',
});

Run the issues sync on demand

Syncs run on a schedule (every hour in this example). When a customer wants fresh data immediately, give them a refresh button that triggers the sync on demand (behind the scenes, a nango.triggerSync call) instead of waiting for the next run. The refresh endpoint that triggers the sync is in backend/server.mjs in the demo repo.

Create issues and comment on pull requests from your app

An action is a one-off operation your product or an agent triggers on demand. This is the write-back direction: an AI agent files an issue from a support ticket, posts a review summary on a pull request, or opens a fix PR. Prompt Codex to build it:

$building-nango-functions-locally Add an action to the github-app-oauth integration that creates an issue
in a customer's repo from a typed title, body, and labels.

Codex writes the action, tests it by opening a real issue in your connected test repository, and deploys it when you approve. The full action is in create-issue.ts in the demo repo.

// Codex generates this action; approve the deploy when it asks.
export default createAction({
    description: 'Create an issue in the connected repo',
    retries: 0, // creating an issue is not idempotent; a blind retry could open a duplicate
    exec: async (nango, input) => {
        const res = await nango.post({
            endpoint: `/repos/${input.owner}/${input.repo}/issues`,
            data: { title: input.title, body: input.body, labels: input.labels },
        });
        return { number: res.data.number, url: res.data.html_url };
    },
});

On retries: 0: creating an issue is not idempotent, so re-running the whole action after an unknown failure could open the same issue twice. Rate-limited requests are safe because they wrote nothing, and Nango’s proxy retries those for you.

Deploy it the same way (Approve when Codex asks to deploy):

nango deploy --action create-issue dev

Commenting on a pull request uses the same shape. In GitHub, a pull request is also an issue, so a comment posts to /repos/{owner}/{repo}/issues/{number}/comments whether the number points at an issue or a PR. One more prompt adds an add-issue-comment action, and a third opens a pull request from a branch with POST /repos/{owner}/{repo}/pulls:

$building-nango-functions-locally Add actions to the github-app-oauth integration to comment on an issue
or PR, and to open a pull request from a head branch into a base branch.

You can test any action from your app, or run it from the Nango dashboard with the Playground against your connection.

React to GitHub events in real time with webhooks

A scheduled sync is enough for most data, but GitHub is event-rich, and a lot of products need to react the moment a pull request opens or an issue changes. GitHub Apps deliver one webhook stream for the events you subscribe to (push, pull_request, issues, and more).

Nango receives those webhooks, verifies the X-Hub-Signature-256 signature against your webhook secret, and forwards the verified event to your integration, so you do not write HMAC code. Prompt Codex to wire it up:

$building-nango-functions-locally Subscribe the github-app-oauth integration to pull_request and issues
webhook events and update the synced records as soon as events arrive.

Keep the hourly sync running as a backstop. Webhook deliveries can be missed (a transient outage, a paused delivery), and a scheduled re-sync catches anything the event stream dropped. The combination of verified webhooks for freshness and a periodic sync for completeness is the pattern most production GitHub integrations settle on.

One manual step is needed to start receiving events: point your GitHub App at Nango’s webhook URL. Copy it from your integration’s settings page in the Nango dashboard, then paste it into your GitHub App under Developer settings > GitHub Apps > your app > Webhook URL.

Give AI agents in your product access to GitHub

This is where the previous steps pay off: the sync gives the agent current GitHub data to reason over, and the actions become the tools it acts with. Once they are deployed, the AI agents inside your product can use them. Nango exposes enabled actions as typed tool calls through a hosted MCP server, so an agent calls create-issue or add-issue-comment with typed inputs instead of guessing raw GitHub API parameters.

Point your MCP client at Nango’s server (Streamable HTTP transport) and pass three values:

Authorization:        Bearer <YOUR-NANGO-SECRET-KEY>
provider-config-key:  github-app-oauth
connection-id:        <CONNECTION-ID>

Authorization: your Nango secret key, held by your backend.
provider-config-key: your GitHub integration ID (github-app-oauth).
connection-id: the connection for the current user. Fetch it per logged-in user rather than hardcoding it, so each user’s agent acts on their own repositories.

Codex can wire this into your product’s agent for you:

$building-nango-functions-locally Wire my product's AI agent to Nango's MCP server for the github-app-oauth
integration, passing the logged-in user's connection id, so it can read issues and open PRs. Add flexible actions to Nango to make the agent feature complete

If you do not have an agent interface in your product yet but want to try the tools, add Nango’s MCP server to Codex itself. codex mcp add does not support custom headers, so add it to ~/.codex/config.toml:

[mcp_servers.nango_github]
url = "https://api.nango.dev/mcp"
bearer_token_env_var = "NANGO_SECRET_KEY"
http_headers = { "connection-id" = "<CONNECTION-ID>", "provider-config-key" = "github-app-oauth" }

Then ask Codex: “Open an issue titled ‘Flaky test in checkout’ in my connected repo using the nango github MCP.” For the patterns that make these tool calls reliable in production, see build reliable tool calls for AI agents.

Tip: you can view detailed action and sync logs on the Nango dashboard.

Common issues

Issue	Cause and fix
`401 Bad credentials`	The token expired or the installation was revoked. Nango refreshes installation tokens (1 hour) and user tokens (8 hours) for you; if the customer removed the installation, they reconnect from your app.
`BAD_REFRESH_TOKEN` on a user token	The client secret was rotated or the installation was revoked. The customer reconnects. See the full breakdown.
`403` or `429` with `retry-after`	A primary or secondary rate limit (100 concurrent requests, 900 points per minute). Nango retries with backoff; spread bulk work and avoid firing parallel requests at one installation.
Issue sync contains pull requests	`GET /issues` returns PRs too. Filter on the `pull_request` field to keep them separate.
Webhook rejected or ignored	The `X-Hub-Signature-256` HMAC did not match. Confirm the webhook secret on your GitHub App matches the one in Nango; Nango verifies the signature for you.
`404` on a repo the user can see	The GitHub App installation was not granted that repository. The customer adds it under the installation's repository access settings.
Endpoint returns `Not Found` only for a GitHub App	Some endpoints work only with OAuth Apps. Check for the "Works with GitHub Apps" note on the endpoint in GitHub's docs.
`listRecords` is empty right after connecting	The sync starts only after your app saves the repo metadata, and the first run is asynchronous. Read records once a run completes.

FAQ

Should I use a GitHub App or an OAuth App for a customer-facing product?

Use a GitHub App. It installs per organization or repository with fine-grained permissions and rate limits that scale from 5,000 to 12,500 requests per hour. An OAuth App acts as the authorizing user and suits personal-developer tools.

How do you handle GitHub API rate limits when syncing data?

GitHub allows 5,000 to 12,500 requests per hour, plus secondary limits of 100 concurrent requests and 900 points per minute. Spread bulk work, avoid firing parallel requests at one installation, and retry on 403 or 429 using the retry-after header.

How do you verify GitHub webhooks?

GitHub signs each delivery with an X-Hub-Signature-256 header, an HMAC-SHA256 of the raw request body using your webhook secret. Verify it with a constant-time comparison before trusting the payload, and read the event type from the X-GitHub-Event header.

How long does it take to build a GitHub API integration?

By hand, a production integration with auth, syncs, webhooks, and rate-limit handling takes weeks. With Nango and a coding agent like Codex, the agent writes and tests the same integration against a real connection in about an hour.

Conclusion

A production-grade GitHub API integration for agents comes down to customer auth, incremental sync, writing safely, reacting in real time (signature-verified webhooks), and staying inside two rate-limit systems. Together they become the tools the AI agents in your product call to act on a customer’s GitHub.

With the Nango skill, Codex writes that logic as code from a prompt and tests it against a real connection, while Nango’s runtime handles managed OAuth, durable syncs, webhook verification, retries, and observability. The same workflow covers any of Nango’s 800+ supported APIs, and it scales into just-in-time integrations: integrations built on demand by an agent instead of pre-built for every use case.

Clone the demo project on GitHub to run it end to end, or build your first integration from the quickstart.

Related reading:

Best open-source API integration platforms for AI agents in 2026

Sapnesh Naik — Mon, 15 Jun 2026 19:09:15 +0000

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 dryrun command 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.

How to build a Google Sheets API integration with Nango and Codex

Sapnesh Naik — Fri, 12 Jun 2026 15:39:22 +0000

This guide shows how to build a custom, customer-facing Google Sheets API integration with Nango and an AI coding agent (Codex, Claude Code, Cursor, or any other).

By the end of this guide, you will have:

A Google Sheets auth UI in your product (Nango Connect) so your customers can connect their own spreadsheets to your app.
A durable sync that imports rows from a connected spreadsheet and keeps them up to date as the sheet changes.
The ability to append rows to a customer’s spreadsheet and export reports to new spreadsheets, from your UI or from an AI agent in your product (via an MCP tool call).

Get the working example: the complete demo (frontend, backend, nango-integrations) is on GitHub at NangoHQ/google-sheets-api-integration. Clone it to run the whole thing end to end, or follow the guide below and let Codex generate the same functions in your own project.

Why is it hard to integrate the Google Sheets API into your app?

A production Google Sheets API integration needs a few decisions up front:

You need an OAuth app, not an API key: a Google Sheets API key only reads public spreadsheets. Accessing customer spreadsheets takes an OAuth 2.0 app with a consent screen, token refresh, and revocation handling.
Decide on scopes early, they set your verification timeline: most integrations request https://www.googleapis.com/auth/spreadsheets, the standard read-write scope. Google classifies it as sensitive, so your app needs verification to go live (unverified apps cap at 100 users), and while the OAuth app’s publishing status is Testing, refresh tokens expire every 7 days.
Plan around the rate limits: the quota is 300 read and 300 write requests per minute per project, and 60 per user. Past that, requests fail with 429: Too many requests, and Google’s limits page says exceeding quota is planned to incur charges later in 2026.
No Google Sheets webhooks: the v4 API has no push notifications. Change detection means polling, or Drive API files.watch channels that expire after at most one day and carry no payload.
Decide whether you want Google’s auto-formatting on writes: valueInputOption=USER_ENTERED parses values the way the Sheets UI does (strings can become numbers and dates), while RAW stores them as-is. Phone numbers and zip codes usually belong in RAW.
Keep the data you write contiguous: values.append looks for a “table” in the target range and writes after the last one it finds, so empty rows shift where new rows land.
Avoid hardcoding sheet names or ranges: customers rename tabs and reorder columns, which breaks A1 ranges (Unable to parse range). Store the stable numeric sheetId, resolve the current tab name with spreadsheets.get before building ranges, and read headers instead of assuming column order.

Building all of this by hand takes weeks. With Nango and a coding agent like Codex, the same Google Sheets API integration can ship in about an hour.

Why use Nango for a Google Sheets API integration

For a Google Sheets integration, we will use these Nango features:

OAuth for Google Sheets: your product gets a customizable, white-label auth UI where customers connect their Google Sheets account, while Nango handles token storage, refresh, and encryption behind it.
A function builder skill for Codex: to build your integration logic and flows, Codex uses the Nango function builder skill. It researches the Sheets API, writes your actions and syncs from a prompt, tests them against a real Google Sheets connection, and iterates until the integration works end to end. Note: The Nango skill also works with other coding agents like Claude Code, Cursor, Gemini CLI, etc.
Integrations infrastructure for every use case:
- Actions: one-off operations on a customer’s sheet, like appending a row or creating a spreadsheet.
- Syncs: scheduled functions that keep spreadsheet rows flowing into your app.
- Webhooks: route external events, like Drive file-change notifications, to your integration.
- MCP server: exposes your deployed actions as tools for the AI agents in your product.

Nango also has pre-built actions and syncs for Google Sheets. They cover the common operations (a worksheet rows sync, appending values, reading values, upserting rows, creating spreadsheets) and you can enable them from your dashboard and use them right away, without building anything. Or have Codex clone and customize them to fit your use case.

Prerequisites

Sign up for Nango (the free tier is enough for development).
Add Google Sheets as an integration on the Nango dashboard. For this tutorial, use Nango’s pre-configured developer app: activate the shared credentials on the integration page and skip the Google Cloud setup entirely. For production, register your own Google OAuth app with Nango’s callback URL https://api.nango.dev/oauth/callback.

Add a test connection: on the Nango dashboard, open the integration and select Connections > Add Test Connection, then authorize a Google account that owns a spreadsheet with a few rows of data (your own or any test account). While Codex builds your integration, it runs the generated code against this connection, so what ships has already worked against real data.

Give Codex a project to build in. Install the Nango CLI and run nango init: it creates a nango-integrations folder with the Nango framework bootstrapped, and Codex writes and deploys your syncs and actions from there. Set NANGO_SECRET_KEY_DEV (your dev API key, from Environment Settings in the dashboard) in nango-integrations/.env so it can test and deploy on your behalf.

Install the Nango skill. Run npx skills add NangoHQ/skills -s building-nango-functions-locally; the installer detects Codex and copies the skill to .agents/skills/, where Codex discovers it. The same skill works with Claude Code, Cursor, and other coding agents.

Tip: LLM training data on Nango is often stale. Add the Nango docs MCP server alongside the skill so Codex pulls current API references while it generates code:

codex mcp add nango-docs --url "https://nango.dev/docs/mcp"

Sync customer spreadsheet rows to your app

A sync keeps a fresh copy of the customer’s sheet in your app. Here it imports every row of the spreadsheet they connect, then refreshes on a schedule so edits show up without anyone clicking refresh.

You build it by prompting Codex with the Nango skill (type $ to mention a skill, or run /skills to browse):

$building-nango-functions-locally Build a Nango sync for the google-sheet integration that imports
the rows of the spreadsheet a customer connects and keeps them up to date, refreshing every hour.
Integrate it with my frontend.

With the skill loaded, Codex:

Researches the Sheets API and the endpoints it needs.
Writes the sync and a typed model for your rows.
Tests it against your real connection with nango dryrun.
Iterates on any errors until the sync works end to end.

// Codex generates this sync. You do not write it by hand.
export default createSync({
    description: 'Imports rows from the connected Google Sheet and refreshes them every hour.',
    frequency: 'every hour',
    autoStart: false, // starts once your app saves the spreadsheetId metadata
    models: { SheetRow },
    exec: async (nango) => {
        const { spreadsheetId, range } = await nango.getMetadata();
        const res = await nango.get({
            endpoint: `/v4/spreadsheets/${spreadsheetId}/values/${encodeURIComponent(range)}`,
        });
        await nango.batchSave(toRows(res.data.values), 'SheetRow');
    },
});

The full sync, with the row model, header mapping, and delete tracking, is in the demo repo: fetch-spreadsheet-rows.ts.

When Codex finishes, it deploys the sync for you (approve the deploy when it asks):

nango deploy --sync fetch-spreadsheet-rows dev

Because the prompt said to integrate the frontend, Codex also wires Nango Connect into your app: customers authorize Google Sheets, paste their spreadsheet link, and the sync starts on its own.

Your backend reads the synced rows from Nango’s cache and serves them to your UI:

const { records } = await nango.listRecords({
    providerConfigKey: 'google-sheet',
    connectionId,
    model: 'SheetRow',
});

Do a quick check to confirm everything works: open your app, connect a Google account, paste a spreadsheet URL, and watch the rows appear. Codex has already tested the integration with nango dryrun; this is your own sanity check.

Letting users pick a Google Sheet

The Sheets API has no endpoint to list a user’s spreadsheets, so the sync needs to be told which one to read. Here we handle it by asking the user for the spreadsheet URL. If you would rather let customers pick from a list of their spreadsheets than paste a link, use the Google Drive API: a Drive-scoped connection plus a file picker, which we will cover in a separate Google Drive guide.

Run the sync on demand

$building-nango-functions-locally Add a refresh button to my app that triggers the fetch-spreadsheet-rows
sync on demand for the current user's connection.

With the sync deployed, a customer connects once and the rows they maintain in Sheets show up in your app and stay current: a product catalog they edit in a spreadsheet, a price list your billing features read, or the roster behind your scheduling screens.

Append rows to a customer’s spreadsheet from your app

An action is a one-off operation your product or an agent triggers on demand. Here it writes back: each new lead, order, or form response in your app lands as a row in the customer’s sheet. Prompt Codex to build it:

$building-nango-functions-locally Add an action to the google-sheet integration that appends a row
to the customer's connected spreadsheet from typed input.

Codex writes the action, tests it by appending real rows to your connected test spreadsheet, and deploys it when you approve.

// Codex generates this action; approve the deploy when it asks.
export default createAction({
    description: 'Append a row to the connected spreadsheet',
    retries: 0, // appends are not idempotent, a retry must not duplicate the row
    exec: async (nango, input) => {
        const res = await nango.post({
            endpoint: `/v4/spreadsheets/${input.spreadsheetId}/values/${encodeURIComponent(input.range)}:append`,
            params: { valueInputOption: 'USER_ENTERED', insertDataOption: 'INSERT_ROWS' },
            data: { values: [input.row] },
        });
        return { updatedRange: res.data.updates.updatedRange };
    },
});

Two parameters matter here: valueInputOption=USER_ENTERED parses values the way the Sheets UI would (so a date string becomes a real date), and insertDataOption=INSERT_ROWS inserts new rows instead of overwriting data below the table. If your customers store values that look like numbers but aren’t (phone numbers, zip codes), switch to RAW. On retries: 0: a rate-limited request is safe to retry because it wrote nothing, and Nango’s proxy handles that; re-running the whole action after an unknown failure could append the row twice, so the action itself does not retry.

Deploy it the same way:

nango deploy --action append-row dev

You can test the action from your app, or run it from the Nango dashboard with the Playground against your connection. The demo wires one more action of the same shape for inline edits, so changing a row in the app updates the sheet:

Your product can now write to the spreadsheets your customers already work in. Form builders use this exact pattern to stream responses into a sheet, schedulers log bookings as they happen, and e-commerce tools export each order as it comes in, without the customer ever downloading a CSV.

Export app data to a new spreadsheet

The other common write pattern is an “Export to Google Sheets” button: instead of appending to an existing sheet, your app creates a fresh spreadsheet in the customer’s account and fills it with data. The same action workflow covers it:

$building-nango-functions-locally Add an action to the google-sheet integration that creates a new
spreadsheet from a title and a 2-D array of values, and returns the new spreadsheet's URL.

Codex builds this on two calls, spreadsheets.create followed by a values.batchUpdate write, and returns the spreadsheetUrl your UI can open in a new tab. Analytics exports, scheduled report generation, and one-report-sheet-per-customer setups are all this action plus a place to trigger it from.

Give AI agents in your product access to customer spreadsheets

Once the sync and actions are deployed, the AI agents inside your product can use them. Nango exposes enabled actions as typed tool calls through a hosted MCP server, so an agent calls append-row with typed inputs instead of guessing raw Sheets API parameters.

Point your MCP client at Nango’s server (Streamable HTTP transport) and pass three values:

Authorization:        Bearer <YOUR-NANGO-SECRET-KEY>
provider-config-key:  google-sheet
connection-id:        <CONNECTION-ID>

Authorization: your Nango secret key, held by your backend.
provider-config-key: your Google Sheets integration ID (google-sheet).
connection-id: the connection for the current user. Fetch it per logged-in user rather than hardcoding it, so each user’s agent acts on their own spreadsheets.

Codex can wire this into your product’s agent for you:

$building-nango-functions-locally Wire my product's AI agent to Nango's MCP server for the google-sheet
integration, passing the logged-in user's connection id, so it can read and append spreadsheet rows.

[mcp_servers.nango_sheets]
url = "https://api.nango.dev/mcp"
bearer_token_env_var = "NANGO_SECRET_KEY"
http_headers = { "connection-id" = "<CONNECTION-ID>", "provider-config-key" = "google-sheet" }

Then ask Codex: “Append a row with today’s signup count to my Metrics spreadsheet using the nango sheets MCP.”

Tip: you can view detailed action and sync logs on the Nango dashboard.

Your product’s agents can now work with customer spreadsheets through the same integration: an in-product assistant answers questions from the synced rows, a support copilot logs each resolution to the customer’s tracking sheet, all scoped to that user’s connection and logged like every other call.

Common issues

Issue	Cause and fix
`Unable to parse range: Sheet1!A1:D10` (400)	The tab was renamed, or the sheet name needs single quotes (`'Q2 Leads'!A1:D10`). Store the numeric `sheetId` and resolve the current tab name with `spreadsheets.get` before building ranges.
429 `Quota exceeded for quota metric 'Read requests'`	The Sheets API allows 60 requests per minute per user. Batch with `values.batchGet` / `values.batchUpdate`; Nango retries with backoff for you.
403 `The caller does not have permission`	The connected account lost access to the spreadsheet, or was not granted access in the first place. Reconnect with the owning account or re-share the sheet.
400 `This operation is not supported for this document`	The ID points to an Excel file stored in Drive, not a native Google Sheet. Convert it (File > Save as Google Sheets) and use the new ID.
Numbers or dates change when written	`USER_ENTERED` parses values like the Sheets UI, so "06-11" can become a date. Use `RAW` to store values verbatim.
Appended rows land in the wrong place	`values.append` writes after the last "table" it finds in the range, and blank rows split tables. Keep data contiguous and check the `tableRange` field in the response.
Refresh token stops working after 7 days	Your Google OAuth app is in Testing mode. Publish it to Production and complete verification; see Google OAuth invalid_grant: what it means and how to fix it.
`listRecords` is empty right after connecting	The sync starts only after your app saves the `spreadsheetId` metadata, and the first run is asynchronous. Read records once a run completes (Codex wires this into your app).

Conclusion

A production-grade Google Sheets API integration comes down to customer OAuth (sensitive scopes and Google verification), reading rows durably (a polling sync, since the API has no webhooks), writing rows safely (append semantics and value parsing), and staying inside per-user quotas.

With the Nango skill, Codex writes that logic as code from a prompt and tests it against a real connection, while Nango’s runtime handles managed OAuth, durable syncs, retries, and observability. The same workflow covers any of Nango’s 800+ supported APIs, and it scales into just-in-time integrations: integrations built on demand by an agent instead of pre-built for every use case.

Clone the demo project on GitHub to run it end to end, or build your first integration from the quickstart.

Related reading:

Best self-hosted API integration platforms for AI agents

Sapnesh Naik — Wed, 10 Jun 2026 19:49:50 +0000

TL;DR

AI agents and SaaS products need API integrations with their customers’ tools: read a record from the CRM, post to Slack, draft an email, update a ticket. An integration platform handles the auth, credential storage, and execution behind those calls. On a managed platform, all of that runs on the vendor’s cloud.

Teams in regulated industries, or with data-residency rules or strict security reviews, need a self-hosted integration platform where credentials and execution stay on their own infrastructure.

The platforms compared:

Nango: The integration platform where coding agents build API integrations and AI agents consume them. Open source, with a free self-hosted edition for auth and the API proxy, and Enterprise self-hosting that runs the full platform in your own cloud.
Composio: A managed tool-calling platform with a large catalog. Their GitHub repo is only the SDK; the runtime that stores credentials is closed source, and self-hosting is an Enterprise-only option that goes through sales.
Paragon: A low-code embedded iPaaS whose full runtime can run in your own Kubernetes. Self-hosting needs a quote-based Enterprise license, and the closed-source images contact Paragon’s cloud for license checks.
Arcade.dev: An MCP (Model Context Protocol) runtime with per-user auth for agents. The engine is a closed-source binary and full self-hosting is enterprise-only. The documented on-prem pattern still routes through Arcade’s cloud.

Why self-host an API integration platform

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. Most teams are fine letting a managed cloud hold all three. For some, that is ruled out:

Regulated industries: Healthcare, finance, and government workloads often cannot pass customer credentials or data through a third-party processor.
Data residency: Some jurisdictions require data to stay in a region, or a network, that you control.
Security review and procurement: “Where do our customers’ Salesforce tokens live?” is an easier question in a vendor review when the answer is “in our own VPC.”
Air-gapped or private networks: Some deployments have no route to a public SaaS API at all.

Open-source SDK vs self-hostable runtime

Most platforms in this space have a public GitHub repo. In most cases, the repo contains a client SDK, a CLI, or an MCP wrapper. The backend that stores tokens, runs OAuth flows, and executes integration code is either closed source behind an enterprise license or not available at all.

Self-hosting comes in three tiers:

Free self-hosting: You deploy a working edition from public images without talking to sales.
Enterprise-licensed self-hosting: The full runtime runs in your cloud, but only with a license key from the vendor’s sales team.
Not self-hostable: The runtime only exists as managed SaaS.

License terms matter as much as deployment. The part you run may be MIT or Apache-2.0 while the part that holds credentials is proprietary. Some licenses also prohibit embedding the tool in a commercial product.

What to look for in a self-hosted integration platform for AI agents

A self-hostable runtime: Auth, credential storage, and execution can run on your infrastructure. Check what unlocks it: a free edition you can deploy yourself, or an enterprise license that starts with a sales call.
White-label, per-customer auth: Each of your customers connects their own account under your brand, with token refresh handled for you. Check where tokens are stored and which domain appears in the OAuth callback.
MCP and typed tool calls: Agents discover and call tools over the Model Context Protocol or a REST API, with strict input and output schemas so the model does not guess parameters.
A way for coding agents to build integrations: A skill that lets Claude Code, Cursor, or Codex write a new integration and test it against a real connection, instead of only consuming a fixed catalog.
More than tool calls: Data syncs keep agent context fresh, webhooks let agents react to events, and per-customer configuration handles tenant-specific behavior.
Isolation, observability, and compliance: Per-tenant isolation, full request and response logs, and the certifications (SOC 2, GDPR, HIPAA) that regulated buyers ask about.

The best self-hosted API integration platforms in 2026

1. Nango

Nango is the integration platform where coding agents build integrations. Engineers, or coding agents like Claude Code, Cursor, and Codex, write integrations as code in your repo. Nango’s runtime executes them securely and at scale, covering auth, tool calls, data syncs, and webhooks across 800+ APIs. It is open source under the Elastic License 2.0: you can self-host it and embed it in your product, but not resell Nango as a managed service. Hundreds of fast-growing AI companies use it as core infrastructure.

On self-hosting:

Nango offers two self-hosting paths. A free self-hosted edition deploys with docker-compose and covers managed auth and the API proxy. Enterprise self-hosting deploys the full platform with Helm charts on your own AWS, GCP, or Azure. It runs the same architecture as Nango Cloud: five Node services plus Postgres, Redis, object storage, and Elasticsearch, sized for 1M+ executions per day.

Best for

Teams building AI agents or SaaS products that need API integrations with their customers’ tools, with credentials and execution on infrastructure they control. Coding agents build the integrations, and the agents and features in your product consume them.

Pros

Credentials stay yours, encrypted with your key: Self-hosted deployments require your own encryption key (the NANGO_ENCRYPTION_KEY environment variable) to encrypt credentials and cached records at rest. Tokens live in your Postgres, encrypted with a key Nango never holds.
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 skill for your coding agent
npx skills add NangoHQ/skills -s building-nango-functions

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 at https://api.nango.dev/mcp.
Data syncs and webhooks included: Durable incremental syncs keep data fresh for RAG, webhook processing reacts to provider events in real time, 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.
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.

Just-in-time integrations: Since June 2026, the remote function builder lets coding agents build and deploy actions, syncs, and webhook handlers from a single prompt, without a local project. See the emergence of just-in-time integrations.
Enterprise compliance: SOC 2 Type II, GDPR, and HIPAA, with a BAA available on request.

Cons

The free self-hosted edition covers auth and the proxy only: Functions, syncs, webhooks, and the MCP server require Enterprise self-hosting or Nango Cloud. Nango documents this split openly on the self-hosting page.

2. Composio

Composio is a managed tool-calling platform for AI agents. It offers a catalog of 1,000+ apps, MIT-licensed Python and TypeScript SDKs with adapters for the popular agent frameworks, and managed per-user auth.

On self-hosting:

Composio’s main GitHub repo contains the SDKs and a CLI, not the platform. The backend that stores credentials and executes tool calls is closed source.

Composio publishes official Helm charts for the platform, but the charts pull closed-source images from a registry tied to an Enterprise license.

Best for

Teams that want a large hosted catalog of agent tools on a managed runtime. A fit if you are prepared to sign an enterprise contract later, when credentials need to move on-prem.

Pros

Large catalog: 1,000+ apps, with Tool Router routing across the catalog to keep agent context small.
MIT-licensed SDKs with broad framework support: OpenAI, Anthropic, LangChain, CrewAI, Vercel AI SDK, and others.
Managed per-user auth: Connected accounts are scoped to your user IDs, with automatic token refresh. SOC 2 Type II and ISO 27001 certified.

Cons

Closed-source runtime: The credential store and execution services have no public source. A GitHub request for self-serve self-hosting has been open since July 2024, answered only with “part of our paid offering.”
Credentials always pass through Composio’s cloud on self-serve plans: Even with your own OAuth app, the documented setup registers Composio’s backend callback URL with the provider. Composio’s cloud captures and stores the tokens.

No data syncs: Triggers exist, but there is no managed sync infrastructure for keeping customer data fresh for RAG.
No path to deploy your own connectors: Custom tools are marked experimental and run in-process in your own app. Coding agents can consume the catalog but not extend it.

For a detailed comparison, see the Composio vs Nango head-to-head.

3. Paragon

Paragon is an embedded integration platform for B2B SaaS. It combines a white-label Connect Portal, a visual workflow builder, and Managed Sync for data ingestion. It also exposes 1,000+ pre-built actions as tools for AI agents.

On self-hosting:

Paragon’s full runtime is self-hostable, which is rare among embedded iPaaS vendors, but it is Enterprise-only. The public installer repo deploys the platform onto Kubernetes in your AWS, GCP, or Azure account with Terraform and Helm. It requires a license key from Paragon’s sales team and a Docker account with read access to Paragon’s private image registries.

Once deployed, the data plane stays local: the docs state the applications never export or sync data outside the installation.

Best for

Enterprise B2B SaaS teams that want an embedded iPaaS with a visual builder and managed data sync, deployed in their own VPC. A fit if you have the budget and DevOps capacity for a quote-based Enterprise deployment.

Pros

Full runtime in your cloud: Auth, credentials, workflows, and sync run in your cloud, with credentials stored in your own Postgres.
Managed deployment option: Paragon’s team can operate the stack inside your cloud account. Most of their self-hosted customers use this option.
Agent tooling on top of the platform: ActionKit exposes pre-built actions and triggers as LLM tools, with an official MCP server. HIPAA support for self-hosted installs was added in January 2026.

Cons

Enterprise-only and quote-based: There is no free or self-serve way to run the runtime. Nothing boots without a license key.
Closed source with vendor-controlled installers: You deploy opaque images from private registries. The public Terraform and Helm assets carry no open-source license, and the README warns that modified charts may not be supported.
Self-hosted installs depend on Paragon’s licensing service: The services contact Paragon’s cloud on bootup and on a periodic cron to verify the license.
Heavy operational footprint: An unmanaged install runs a Kubernetes cluster, three Postgres databases, Redis clusters, and MinIO, with your team owning monitoring and upgrades.
Low-code customization only: The catalog is 130+ connectors, and custom work routes through Paragon’s dashboard and low-code tooling. A coding agent cannot extend the platform.

For a detailed comparison, see Paragon vs Nango.

4. Arcade.dev

Arcade is an MCP runtime for agent tool calling, built around per-user auth. When a tool call lacks a user grant, the Arcade Engine intercepts it, runs the OAuth flow with the end user, and stores and refreshes the tokens. Credentials never enter the LLM context. The tool-building framework is open source under MIT.

On self-hosting:

Arcade’s Engine, which holds tokens and routes tool calls, is a closed-source binary with no public repo. Full platform self-hosting exists only as part of the enterprise offering, and the pricing page does not mention self-hosting on any tier.

Best for

Teams building MCP-first agents where per-user authorization is the priority. Best suited if tool calls are your entire scope and you do not need data syncs or webhooks.

Pros

Per-user OAuth built for agents: Authorization is checked before execution, the user is prompted to grant access, and tokens never enter the model context.
MCP-native with an open-source framework: Hosted MCP servers, streamable HTTP transport, and an MIT framework for building custom servers, with skills for Claude Code and Cursor that scaffold new tools.
Co-authored the MCP auth spec: Worked with Anthropic on the MCP secure authorization capability, announced in November 2025.

Cons

The Engine is closed source: The exact component that stores end-customer credentials and routes authenticated tool calls has no public repository.
Full self-hosting is enterprise-only: The Helm-based on-prem deployment is sold as part of the enterprise offering, and self-serve install docs were removed in October 2025.
The non-enterprise “on-prem” pattern is hybrid: Your MCP server must be reachable from Arcade’s cloud Engine over a public URL, and OAuth tokens stay in Arcade Cloud.
Tool calls only: No data syncs to feed agent context, no webhook ingestion, no scheduled triggers.
Modest catalog: The registry advertises 154 MCP servers, but only 116 are live as of June 2026, and 42 of the live ones are auto-generated.

Side-by-side comparison

Capability	Nango	Composio	Paragon	Arcade.dev
Free self-hosted edition	Yes (auth + proxy)	No	No	No
Full platform on your infra	Enterprise plan	Enterprise plan	Enterprise plan	Enterprise plan
Open-source runtime	Yes	No	No	No
Credentials on your infra	Yes	Enterprise only	Enterprise only	Enterprise only
Coding agents build integrations	Yes (18+ agents)	No	No (low-code only)	Limited (scaffolding)
MCP tool calls	Yes	Yes	Yes	Yes
Data syncs and triggers	Yes	Triggers only	Yes	No
Catalog	800+ APIs, 2000+ prebuilt actions	1,000+ apps	130+ connectors	116 MCP servers
Compliance	SOC 2 Type II, GDPR, HIPAA	SOC 2 Type II, ISO 27001	SOC 2 Type II, GDPR, HIPAA	Not publicly listed
Primary focus	Build + run agentic integrations	Hosted tool catalog	Embedded iPaaS	Tool-calling auth runtime

Catalog counts use each vendor’s own unit (APIs, apps, connectors, MCP servers) and are not directly comparable.

How to choose

You want to try self-hosting for free before an enterprise contract: Pick Nango. It is the only platform in this comparison with a free self-hosted edition.
You need credentials and execution on your own infrastructure, for an app and the AI agents inside it: Pick Nango. It is the only platform here where coding agents build integrations on a runtime you can self-host, and the only one with data syncs and webhooks built in.
You want a visual workflow builder in your VPC and have an enterprise budget: Paragon, if you accept the closed-source runtime and the license checks against Paragon’s cloud.
Per-user authorization for MCP tool calling is your hardest problem: Arcade.dev, if tool calls are the only scope.

FAQ

Can you self-host Composio?

Only on the Enterprise plan. Composio publishes official Helm charts on GitHub, but the platform images are closed source and pulled from a registry tied to an enterprise license, and the docs have no self-hosting section. On self-serve plans, all credentials are stored on Composio’s cloud. See the Composio alternatives post for the wider comparison.

Are Prismatic, Pipedream Connect, or Merge self-hostable?

No. Prismatic offers an Enterprise-plan private cloud, but Prismatic’s own team deploys and operates it in your AWS account, and its on-prem agent is a connectivity proxy, not the runtime. Pipedream (acquired by Workday in November 2025) publishes connector components on GitHub while the Connect runtime stays fully managed. Merge runs as managed cloud only.

Can you 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 requires a separate commercial license. Activepieces has an MIT core, but embedding and white-label features sit in its paid enterprise edition.

What is the difference between self-hosted, open source, and on-premise?

Self-hosted means you run the software on infrastructure you control; on-premise is the stricter subset where it runs in your data center. Open source describes the license, not the deployment. A platform can be open source yet cloud-only in practice, because the published code is just an SDK. Self-hostable software can also be fully closed source, like Paragon. Always check which components the open-source license covers.

What is the best self-hosted integration platform for AI agents?

Nango is the strongest option for AI agents in 2026. It is open source, the free self-hosted edition keeps auth and credentials on your infrastructure, and Enterprise self-hosting runs the full platform (MCP server, tool calls, data syncs, webhooks) in your own cloud with your own encryption key. It is also the only platform in this comparison where coding agents build and test integrations end to end.

Conclusion

Self-hosting rules out most of the API integration market. Many platforms publish an open-source SDK while the credential store and runtime stay on the vendor’s cloud. The rest gate self-hosting behind an enterprise sales process: Paragon’s closed-source runtime needs a quote-based license, and Composio and Arcade.dev reserve full self-hosting for enterprise contracts.

Nango is the broadest option of the four. The platform is open source, and the free self-hosted edition keeps customer credentials on your infrastructure from day one. Enterprise self-hosting runs the complete platform (auth, tool calls, syncs, webhooks, and the MCP server) in your own cloud. Coding agents build the integrations, and the AI agents in your product consume them.

If you want to try the Nango AI builder skill with your favorite coding agent, follow the Nango functions guide to get started.

Best integration platform for mail and calendar integrations (2026)

Sapnesh Naik — Wed, 03 Jun 2026 13:48:46 +0000

TL;DR

If you need email and calendar API integrations in your product, building them involves handling OAuth across Google, Microsoft, and IMAP, incremental sync, and push notifications. This post compares the platforms teams use to build mail and calendar integrations in 2026.

We rank them on provider coverage, how you build integrations with each one (including AI coding agent support), how much of the underlying API you can reach, who owns auth, and what else the platform can integrate when mail and calendar are no longer enough.

Nango: The integration platform where coding agents build integrations. It covers mail and calendar alongside 800+ other APIs, with full API access and auth you own.
Nylas: Unified API for email, calendar, and contacts. Limited to communications data, and your users’ tokens live on Nylas.
Aurinko: A pass-through alternative to Nylas with the same mailbox scope. Owns the OAuth app your users authorize.
Unipile: A unified API built around messaging (LinkedIn, WhatsApp), with email and calendar added on.

Why mail and calendar API integrations are hard

If you’re integrating mail and calendar, you’re either looking at Google, Microsoft, Apple or generic IMAP. Each models the data differently, and none offers a simple “subscribe and get updates” endpoint.

For email:

Sending needs raw MIME, not JSON: the Gmail API wants a base64url-encoded RFC 2822 MIME message in a raw field, not a to/subject/body object (Gmail docs).
Incremental sync is stateful and expires: Gmail tracks changes with a historyId that expires after about a week, and once it ages out you get a 404 and run a full resync (Gmail docs). Microsoft Graph does the same with per-folder delta tokens.
Real-time needs more than a webhook URL: Gmail push runs through Google Cloud Pub/Sub, and the watch must be renewed at least every 7 days (Gmail docs). Microsoft Graph mail subscriptions expire in under 7 days and cap at 1,000 per mailbox (Graph docs). Plain IMAP has no webhooks at all: you hold a connection open with IDLE and poll (RFC 2177).
Restricted scopes need a security review: gmail.readonly, gmail.modify, and gmail.compose are restricted scopes that require Google verification plus an annual security assessment before you go live (Gmail scopes).

For calendars:

Sync tokens, then full resets: Google Calendar incremental sync uses a syncToken to fetch only what changed. Google invalidates that token after a period of time, or when too much has changed to return a clean delta. The next call then returns 410 Gone, and you wipe local state and resync from scratch (Calendar docs).
Watch channels expire with no renew endpoint: Google Calendar push channels expire after about a week, with no automatic renewal. You create a new channel before the old one dies (Calendar docs). For 1,000 connected users, that is 1,000 channels to rotate every week.
Recurring events and Apple: you expand recurring events with singleEvents=true, and syncToken cannot be combined with most query parameters. Apple iCloud is CalDAV, which has no push at all (RFC 4791).

OAuth tokens need constant maintenance on top of this. Access tokens last about an hour, so you refresh them on every connection. Refresh tokens can break too: when a user changes their password or revokes access. When two requests refresh the same token at once, you also have to handle concurrency.

This is the standard work involved in mail and calendar API integrations, and it is why most teams use an integrations platform rather than building it themselves.

Tip: If you’re looking for a full build example, see our guides on the Gmail API and real-time Google Calendar integrations.

What to look for in a mail and calendar integration platform

Every tool here supports embedded, customer-facing integrations, where each of your users connects their own mailbox or calendar. The differences are in how you build integrations with each one, how much of the API you can reach, and who owns the auth.

Provider coverage: Gmail and Google Workspace, Microsoft 365, Outlook, and Exchange, and IMAP at a minimum. Add iCloud (CalDAV) if you need Apple calendars.
How you build integrations: the fastest teams now have coding agents (Claude Code, Cursor, Codex) write integrations against real APIs. The platform should ship a skill or harness so an agent can research, write, test, and deploy an integration, not just expose a fixed catalog.
How much of the API you can reach: a normalized email or calendar schema only exposes the fields most providers share. When you need a provider-specific field or endpoint, you want full API access to reach it.
Who owns auth and tokens: if the tokens live on the vendor’s servers, your users may see the vendor on the consent screen, and migrating off means re-authenticating every account. Prefer a platform where you use your own OAuth app, under your brand, and keep control of the credentials.
Real-time syncs and webhooks: durable data syncs plus managed webhook and channel renewal, so the watch rotation and resync recovery are handled for you.
What else it integrates: most products need more than mail and calendar. Once you add CRM, Slack, ticketing, or storage, a communications-API-only platform means a second vendor. A broad platform covers mail and calendar as one slice of a much larger catalog.
Code-first and open source: integrations that live in your repo, under version control and CI, are easier to review, test, and own than a closed catalog you cannot inspect.
Observability: per-request logs and OpenTelemetry export, so you and your coding agent can read a failure and fix it.

The 4 best mail and calendar integration platforms

1. Nango

The platform covers API auth, tool calls, data syncs, webhooks, and unified APIs across 800+ APIs. For mail and calendar, that means Gmail, Microsoft 365 and Outlook, Google Calendar, and IMAP, alongside every other API your product will eventually need.

Nango also ships pre-built Gmail and Google Calendar templates, so you can start from a working sync or action and customize it, or have your coding agent generate one from scratch.

Best for

Teams that need email and calendar today and will need more integrations (CRM, Storage, Slack, ticketing) tomorrow, and want coding agents to build them.

Pros

Coding agents build the integration: install the AI builder skill and your agent (Claude/Cursor/Gemini) researches the Gmail or Calendar API, writes the sync or action, tests it against a real connection, and iterates until it works.

The agent can also build, test, and deploy without a local project, so an agent inside your product can build mail and calendar integrations just-in-time, straight from a customer’s prompt (just-in-time integrations).
Full API access: you can reach the complete Gmail, Graph, and Calendar APIs, provider-specific fields and endpoints included, and you can still normalize into a unified API layer when you want one.
You own auth, under your brand: a drop-in Connect UI handles OAuth, API keys, and token refresh across 800+ APIs. Use your own Google or Microsoft OAuth app so your users authorize you, not Nango.

Durable data syncs and managed webhooks: data syncs and webhook handling are managed for you, including the Google Calendar channel renewal and resync recovery you would otherwise build by hand.
Model Context Protocol (MCP) server and typed tool calls: the AI agents inside your product can send mail or read a calendar through a typed tool call instead of guessing raw parameters.
Open source and self-hostable: integrations live in your repo, the platform is open source, with SOC 2 Type II, GDPR, and HIPAA, with self-hosting for teams that need full data isolation.
Observability: every operation produces structured logs with full request and response details and OpenTelemetry export.

Cons

Code-first by design: Nango assumes you, or your coding agent, write integration logic as code. Teams that specifically want a non-technical, visual builder for one-off mail and calendar workflows will find a code-first model is more than they need.

2. Nylas

Nylas is a hosted unified API for email, calendar, and contacts. You write code once against the Nylas API and it works across Gmail, Microsoft 365, Outlook, Exchange, and IMAP. They also added an MCP server in March 2025 and a meeting-notes API.

Best for

Teams that want a pre-built, hosted email, calendar, and contacts API and do not expect to integrate much beyond communications data.

Pros

Broad mail and calendar coverage: Gmail, Microsoft 365, Outlook, Exchange, and IMAP behind one schema, plus contacts and an embeddable scheduler.
Mature and hosted: webhooks, token refresh, and provider differences are managed for you.

Cons

Communications data only: email, calendar, contacts, scheduling, and meeting notes, and nothing else. CRM, Slack, ticketing, or storage require a separate platform.
Normalized schema is limiting: the unified model abstracts away provider-specific fields and behavior, and reviewers report gaps such as not fully supporting certain event types.
Breaking API releases: Nylas deprecated its v2 API in January 2025 and moved customers to v3, a migration teams describe as significant work.
No coding-agent build skill: No skill for a coding agent to build, test, and deploy integrations the way Nango’s builder does.

3. Aurinko

Aurinko is a unified API for email, calendar, contacts, and tasks, positioned as an alternative to Nylas. It runs mainly as a pass-through gateway, so it stores minimal data.

Best for

Teams that want a unified mailbox API and do not need coverage beyond email, calendar, contacts, and tasks.

Pros

Core mailbox coverage: Google, Microsoft 365, Exchange, iCloud, and IMAP behind one schema, with webhook subscriptions that auto-renew.
Pass-through architecture: it proxies requests to providers and stores minimal content, which helps in data-sensitive setups.

Cons

Communications-only scope: email, calendar, contacts, and tasks, plus a configurable CRM-connector layer, but not a broad catalog. You will need another platform for most non-mailbox APIs.
Aurinko owns the OAuth app: your end users authorize Aurinko, and Aurinko issues its own tokens, so the consent screen and the credentials are not yours.

No AI builder or MCP server: there is no coding-agent skill and no MCP server, so it is not built for an agent-driven workflow.

4. Unipile

Unipile is a unified API focused on messaging channels, primarily LinkedIn and WhatsApp, with email and calendar added on. Its main draw is access to social messaging that has no easy official API.

Best for

Teams that specifically need access to personal LinkedIn or WhatsApp accounts that the official APIs do not expose, and accept the account-suspension risk. For official LinkedIn and WhatsApp access, Nango covers those APIs without that risk.

Pros

Messaging breadth: LinkedIn, WhatsApp, Instagram, and Telegram in one API, with email (Gmail, Outlook, IMAP) and calendar (Google, Outlook) alongside.
Fast to connect: a hosted auth wizard and an MCP server for agent access.

Cons

LinkedIn access is unofficial: Unipile states it is not affiliated with LinkedIn and connects through user credentials and sessions. Its own docs warn this can trigger LinkedIn warnings, forced reconnections, and account-suspension risk.
Communications-only scope: messaging, email, and calendar, with no CRM, ticketing, accounting, or storage.
Hosted only, tokens on Unipile: there is no self-hosting, and the end user authenticates on Unipile’s domain, so credentials live with Unipile.

Calendar is the lighter half: the product centers on messaging, and calendar coverage is limited to Google and Outlook.
No coding-agent build skill: No skill for a coding agent to build and deploy integrations.

How to build a mail or calendar integration with Nango

Paste Nango’s quickstart prompt into Claude Code, Cursor, or Codex, and it handles account setup, API keys, and your first connection. To build the integration, install the AI builder skill and describe what you want in plain English.

/building-nango-functions-locally Build a Nango sync for the google-calendar integration
that syncs events from the primary calendar and keeps them current with
webhooks. Then add an action to create an event. Integrate both with the frontend.

The agent researches the API, writes the sync and action as typed code, runs nango dryrun against a real connection to test it, and iterates until it works. The integration then runs on Nango’s runtime with managed auth, durable syncs, webhook handling, retries, and logs.

The workflow is the same for Gmail, Outlook, or Google Calendar and covers any of Nango’s 800+ supported APIs, so the next integration after mail and calendar (a CRM, HRIS, Slack) is built the same way. For end-to-end walkthroughs, see building a Gmail API integration and a real-time Google Calendar integration.

Side-by-side comparison

Capability	Nango	Nylas	Aurinko	Unipile
Email (Gmail, Outlook, IMAP)	Yes	Yes	Yes	Yes
Calendar (Google, Outlook, iCloud)	Yes	Yes	Yes	Partial
Beyond mail and calendar	800+ APIs	No	Limited	No
AI integration builder skill	Yes	No	No	No
API access	Full	Normalized	Normalized	Normalized
You own the OAuth app and tokens	Yes	No	No	No
MCP server	Yes	Yes	No	Yes
Open source	Yes	No	No	No
Self-hosting	Yes	No	No	No

Choosing the right platform

If you need email and calendar now and expect to integrate more (CRM, Slack, ticketing) later, and want coding agents to build it: pick Nango.
If you want full API access and to own your users’ auth under your brand: pick Nango.
If you only ever need a hosted email, calendar, and contacts API and are comfortable with communications-only scope and tokens on the vendor: Nylas fits, or Aurinko for a pass-through alternative.
If you need LinkedIn or WhatsApp alongside email and calendar: Nango covers them through their official APIs.
If you want to self-host for data residency: Nango supports self-hosting.

FAQ

What is the best Nylas alternative?

Nango is the broader alternative, with full API access, your own OAuth app, durable syncs, and an AI builder skill for Claude Code, Cursor, and Codex.

Can I build a Gmail and Outlook integration with an AI coding agent?

Yes. With Nango, you install the AI builder skill and prompt a coding agent (Claude Code, Cursor, Codex, or others) to build the integration. The agent researches the Gmail or Microsoft Graph API, writes the action or sync as code, tests it against a real connection with nango dryrun, and iterates until it works. See building Gmail API integration with Nango and Claude for an example.

Do I need a unified API for email and calendar?

Not always. A unified schema works well when you only read the fields Gmail and Outlook share. It limits you when you need a provider-specific field or endpoint it does not model. A platform with full API access lets you reach the complete provider surface and still normalize into a unified layer when that helps.

What about Apple iCloud calendars?

iCloud uses CalDAV (RFC 4791), which has no push notifications, so you sync by polling. The unified mailbox APIs (Nylas, Aurinko) abstract CalDAV for you. With a code-first platform like Nango, you (or your coding agent) build against CalDAV directly when you need iCloud, with the sync infrastructure managed for you.

Should I build email and calendar integrations in-house or use a platform?

Based on our experience supporting API integrations across 800+ APIs, we would not recommend building the OAuth, sync, and webhook plumbing from scratch. The provider differences (Gmail’s Pub/Sub watch, Graph subscription renewal, Calendar syncToken and 410 recovery, CalDAV polling) keep changing, so they cost maintenance time long after the first version ships. A platform handles that layer so your code focuses on your product, and with a code-first platform you keep full control of the integration logic.

Conclusion

The specialist vendors covered here each solve one slice of the problem. Nylas and Aurinko give you a unified mailbox API, and Unipile leans into social messaging. If mail or calendar is the only integration you will ever build and you fit one of those niches, they work.

Most products do not stay there. Email and calendar are usually just the first integrations, and a communications-only API means a second vendor once you add a CRM, a help desk, or Slack. Nango covers mail and calendar, and the same platform supports 800+ other integrations, with coding agents doing the building.

How to sync large amounts of contacts from the HubSpot API

Sapnesh Naik — Thu, 07 May 2026 16:36:49 +0000

If you are building API integrations with HubSpot in your product, you will eventually need to sync more than 10,000 contacts from a customer's portal. That is not easy when you want a durable, resumable sync that fetches only new and changed records, instead of refetching everything on every run. You also need to think about managing the auth tokens for 100s of users, record storage, webhook updates, and more.

This guide walks through how to build a production-ready HubSpot contacts sync using Claude Code, Cursor, Codex, or any other AI Coding Agent with the Nango AI Function Builder skill.

The full working demo, including the Nango sync, an Express backend, and an HTML dashboard for browsing synced contacts, is on GitHub at NangoHQ/blog-demos/how-to-sync-large-amounts-of-contacts-from-hubspot-api.

Note: The same steps can also be used for syncing HubSpot companies, deals, tickets, and any other CRM Nango supports.

Why syncing large amounts of contacts from HubSpot is hard

HubSpot exposes contacts through two endpoints, and neither one is enough on its own:

Endpoint	Filter by `lastmodifieddate`?	10k total cap?
`GET /crm/v3/objects/contacts` (basic list)	No	No
`POST /crm/v3/objects/contacts/search`	Yes	Yes (400 error past 10k)

The search-the-crm guide confirms it: "The search endpoints are limited to 10,000 total results for any given query. Attempting to page beyond 10,000 will result in a 400 error." Search is also rate-limited to five requests per second per account.

So the search endpoint is the only one that filters by lastmodifieddate (what you need for incremental syncs), but it walls off at 10k. The basic list endpoint has no cap but no filter. The HubSpot community forum is full of 400 reports from developers who only used search and assumed their code was broken.

Solution to sync large amounts of contacts from HubSpot

Split the sync into two phases that share state via Nango checkpoints:

Initial phase. Page through every contact using the basic list endpoint. No 10k cap. After each page, save a checkpoint with the after cursor and the highest lastmodifieddate seen so far. Note: while this endpoint does have lastmodifieddate in its response, it does not support filtering by lastmodifieddate.
Incremental phase. Switch to the search endpoint. Filter by lastmodifieddate GT <watermark>, sort ascending by lastmodifieddate, and page through. Each page advances the watermark. If a request 400s past the 10k cap, catch the error, save the latest watermark, and start a fresh search from it inside the same run. Repeat until a search returns fewer than 10k results, so no modified records are missed.

Why building this from scratch is harder than it looks

The two-phase pattern is the easy part. The infrastructure underneath is the hard part:

Durable checkpoints that survive process restarts and store per-connection cursors and watermarks.
Resumable execution, so a 200k-contact backfill can stop and pick up across multiple runs without skipping or duplicating records.
HubSpot OAuth lifecycle with concurrent token refreshes and graceful handling of BAD_REFRESH_TOKEN.
Rate-limit handling with backoff and per-connection queuing for HubSpot's 5 req/s search cap.
Sync-completion webhooks so your backend knows when new records landed.

What Nango provides for building API integrations

Nango is an agentic API integrations platform. It gives you five building blocks that turn the two-phase pattern from a multi-week project into minutes of work with a coding agent:

Wide API support with managed auth. Pre-built auth for 700+ APIs, including HubSpot, with OAuth 2.0, API keys, basic auth, JWT, and other auth types. Token refresh, encryption, and revocation handling are managed for you.
AI Function Builder skill for coding agents. Install once with npx skills add NangoHQ/skills and your AI coding agent (Claude Code, Cursor, Codex, Gemini CLI, and others) gets the context to research the API, write a Nango sync or action in TypeScript, run dryruns against a real connection, and iterate until the integration works.
Actions and tool calls. Actions are functions written in TypeScript that run on Nango's infrastructure and are triggered from your app or by an AI agent. For example, a create-contact action calls POST /crm/v3/objects/contacts with the right token for the right connection, returning the created record.
Data syncs with record storage. Syncs run on Nango's serverless, tenant-isolated runtime. Synced records are stored in Nango's cache so your app can read them in a paginated manner with nango.listRecords(). The sync handles retries, rate limits, and resumable execution automatically.
Webhooks from external APIs. Nango ingests webhooks from external providers like HubSpot (for example, contact.deletion events), attributes each event to the right connection, and forwards a normalized payload to your backend. You write the handler once and Nango deals with provider-specific signing, retries, and routing.

Implementing a HubSpot contacts sync with Nango

Follow the steps below to implement a durable HubSpot contacts sync using the Nango AI Function Builder skill.

By the end of this section, you will have:

A customizable auth UI in your product so customers can connect their HubSpot account.
An initial backfill sync that fires the moment a new HubSpot connection is created and pulls all contacts.
An incremental phase that picks up only modified contacts on every run (every hour, customizable) and slides past the 10k search cap automatically.
Checkpoints that survive runtime restarts and rate limits.
A backend that receives sync-completion webhooks and reads only the records that changed.

Prerequisites

You will need a Nango account (the free tier is enough for development). Then register your own HubSpot OAuth app with the crm.objects.contacts.read scope, set the OAuth callback URL to https://api.nango.dev/oauth/callback, and configure HubSpot as an integration in the Nango dashboard.

Note: If you do not have your own HubSpot OAuth app yet, you can use Nango's pre-configured developer credentials to get going, then swap to your own credentials before going to production.

Next, install the Nango CLI and initialize an integrations project:

npm install -g nango
nango init
cd nango-integrations

Then install the AI Function Builder skill, so your coding agent has the context it needs to write Nango functions:

npx skills add NangoHQ/skills -s building-nango-functions-locally

This adds Nango's interface patterns, Zod schema conventions, dryrun testing flow, and CLI usage to whichever coding agent you use.

Tip: LLM training data on Nango is often stale. Add the Nango docs MCP server alongside the skill, so your agent can pull current API references during code generation.

Finally, set a Nango dev API key in a .env file at the root of nango-integrations so the CLI and dryrun commands can authenticate:

# nango-integrations/.env
NANGO_SECRET_KEY_DEV=<your-dev-api-key>

You can create or copy a dev API key from the Nango dashboard.

Step 1: Add a HubSpot test connection

Before generating the sync, create a real HubSpot connection in the Nango dashboard. The AI coding agent uses this connection to run nango dryrun against the live HubSpot API while it iterates on the function, so the generated code is tested against real responses.

In the Nango dashboard, click Add Test Connection, pick HubSpot, and complete the OAuth flow against a HubSpot developer account. Copy the connection ID from the connection details page; you will pass it into the prompt in the next step.

Step 2: Generate the contacts sync

Open your project in your AI coding agent and invoke the AI Function Builder skill with a prompt like the one below. Replace the connection ID with the one you just created.

Build a Nango sync for HubSpot contacts that runs every hour, handles
portals with more than 10,000 contacts reliably, and resumes cleanly
across runs without skipping or duplicating records.

Integration ID: hubspot
Connection ID: <your-connection-id>

Properties to sync: firstname, lastname, email, phone, jobtitle,
company, createdate, lastmodifieddate.

The agent figures out the rest from HubSpot's docs and the AI Function Builder skill: which endpoints to use, how to paginate, how to handle the 10k search cap, and how to checkpoint for resumability.

The agent researches both endpoints, writes the function, generates a test suite, runs nango dryrun against your test connection, and iterates on real responses until everything passes. Here is what the agent does behind the scenes.

Step 3: Review the generated sync

When the agent finishes, you will see three new files inside nango-integrations/hubspot/:

hubspot/syncs/fetch-contacts.ts: the sync function itself, with the two-phase logic, checkpoint schema, and Zod model.
hubspot/tests/fetch-contacts.test.json: a recorded HubSpot API response captured during the agent's dryrun, used as a deterministic fixture for unit tests.
hubspot/tests/hubspot-fetch-contacts.test.ts: the unit test that replays the fixture and asserts the sync produces the expected records.

Let's look at the important bits of the sync file. The full file with imports, schemas, helpers, and types is in the demo repo.

1. The createSync declaration and phase dispatcher. A string-only CheckpointSchema carries the phase, the basic-list cursor, and the watermark across runs.

const CheckpointSchema = z.object({
    phase: z.string(),
    after: z.string(),
    lastmodifieddate: z.string()
});

const sync = createSync({
    description: 'Two-phase HubSpot contacts sync that slides past the 10k search cap.',
    version: '1.0.0',
    frequency: 'every hour',
    autoStart: true,
    checkpoint: CheckpointSchema,
    models: { HubspotContact: HubspotContactSchema },
    exec: async (nango) => {
        const checkpoint = await nango.getCheckpoint();
        const phase = checkpoint?.phase === 'incremental' ? 'incremental' : 'initial';
        let watermark = checkpoint?.lastmodifieddate || undefined;

        if (phase === 'initial') {
            watermark = await runInitialPhase(nango, checkpoint?.after, watermark);
        }
        await runIncrementalPhase(nango, watermark);
    }
});

2. Initial phase: paginate through the basic list endpoint, save a checkpoint per page. No 10k cap on this endpoint, so a 200k-contact portal flows through across however many runs are needed.

const proxyConfig = {
    endpoint: '/crm/v3/objects/contacts',
    params: { limit: PAGE_LIMIT, properties: PROPERTIES.join(',') },
    paginate: {
        type: 'cursor' as const,
        cursor_name_in_request: 'after',
        cursor_path_in_response: 'paging.next.after',
        response_path: 'results',
        limit: PAGE_LIMIT,
        on_page: async ({ nextPageParam }) => {
            if (typeof nextPageParam === 'string' && nextPageParam) {
                await nango.saveCheckpoint({ phase: 'initial', after: nextPageParam, lastmodifieddate: watermark ?? '' });
            } else {
                // Backfill done. Switch to incremental on the next run.
                await nango.saveCheckpoint({ phase: 'incremental', after: '', lastmodifieddate: watermark ?? '' });
            }
        }
    },
    retries: 3
};

for await (const page of nango.paginate<HubspotContactRaw>(proxyConfig)) {
    const contacts = page.map(toContact);
    await nango.batchSave(contacts, 'HubspotContact');
    watermark = highestWatermark(contacts, watermark);
}

3. Incremental phase: search filtered by watermark, ascending, checkpointed per page. This is the part that solves the 10k cap. filterWatermark defines the search; savedWatermark advances per page. When a paged request 400s past the 10k cap, catch the error, restart the search from the latest watermark, and continue inside the same run until a slice returns fewer than 10k results.

let filterWatermark = savedWatermark;

while (true) {
    const filterGroups = [{
        filters: [{
            propertyName: 'lastmodifieddate',
            operator: 'GT',
            value: toMillisecondsString(filterWatermark)  // HubSpot wants Unix milliseconds
        }]
    }];

    let after: string | undefined;
    let hitTenKCap = false;

    while (true) {
        let response;
        try {
            response = await nango.post<SearchResponse>({
                endpoint: '/crm/v3/objects/contacts/search',
                data: {
                    filterGroups,
                    sorts: [{ propertyName: 'lastmodifieddate', direction: 'ASCENDING' }],
                    properties: [...PROPERTIES],
                    limit: PAGE_LIMIT,
                    ...(after ? { after } : {})
                },
                retries: 3
            });
        } catch (err) {
            // Past the 10k cap, HubSpot returns a 400. Restart the search
            // from the latest watermark inside the same run.
            if (isTenKCapError(err)) {
                hitTenKCap = true;
                break;
            }
            throw err;
        }

        const contacts = response.data.results.map(toContact);
        if (contacts.length === 0) return;

        await nango.batchSave(contacts, 'HubspotContact');
        savedWatermark = highestWatermark(contacts, savedWatermark);

        await nango.saveCheckpoint({ phase: 'incremental', after: '', lastmodifieddate: savedWatermark ?? '' });

        after = response.data.paging?.next?.after;
        if (!after) return;
    }

    if (!hitTenKCap) return;
    filterWatermark = savedWatermark;  // Slide the search window forward and loop.
}

A few design decisions worth calling out:

Checkpoints saved per page. The initial phase uses nango.paginate with an on_page callback; the incremental phase saves inline after each batchSave. Either way, if the function is interrupted, the next run resumes from the saved state rather than starting over.
Ascending sort on lastmodifieddate. Each search returns the lowest-watermark records first. When a request 400s past the 10k cap, the latest saved watermark is already past everything we just processed, so restarting the search from it picks up the next slice without gaps. The outer loop keeps sliding the window forward until a slice fits under 10k.
Milliseconds, not ISO, for the search filter. HubSpot's search endpoint expects lastmodifieddate as Unix milliseconds. toMillisecondsString handles the conversion.

Step 4: Deploy

Deploy just this sync to your Nango dev environment:

nango deploy --sync fetch-contacts dev

The sync now runs every hour for every connected HubSpot portal, starting with the initial backfill and automatically transitioning to the incremental phase once the backfill catches up.

Step 5: Handle sync-completion webhooks in your backend

When a sync run finishes with new records, Nango sends a sync-completion webhook to your backend with counts of added, updated, and deleted records, plus a modifiedAfter timestamp. Set the webhook URL in the Nango dashboard under Environment Settings > Webhooks. The demo app shows a working Express backend and an HTML dashboard that displays the synced contacts.

Then fetch only the records that changed:

const records = await nango.listRecords({
    providerConfigKey: 'hubspot',
    connectionId,
    model: 'HubspotContact',
    modifiedAfter: webhookPayload.modifiedAfter,
});

Tip: Always verify the webhook signature before processing using nango.verifyIncomingWebhookRequest(). Nango signs payloads with HMAC-SHA256, and verification requires the raw request body (before JSON parsing).

nango.listRecords is paginated. Loop through next_cursor until it returns null, so you do not silently drop records on portals with very high modification rates.

Local testing tip: To inspect webhooks during development, run ngrok against your local backend and set the ngrok URL as the webhook target in Nango's environment settings.

Step 6: Connect a new HubSpot account and test

With the sync deployed, connect a new HubSpot portal through Nango's auth UI. The sync starts immediately because of autoStart: true.

To verify the sync is doing the right thing:

Check the dashboard. The Nango dashboard shows per-run logs, record counts, current checkpoint, and durations. You should see an initial-phase run that each process all the contacts, then incremental runs that process only modified contacts.
Watch the checkpoint. During the initial phase, the checkpoint shows phase: "initial" with an advancing after cursor. Once the backfill completes, the phase flips to "incremental" and the lastmodifieddate watermark starts moving forward.
Modify a contact in HubSpot. Within the next hour, the incremental sync should pick it up, and your backend should receive a sync-completion webhook with addedOrUpdated: 1.

Edge cases worth knowing about

Custom properties. Update the prompt with the custom property names and rerun the AI Function Builder skill. For per-customer property lists, store them in connection metadata and read them during the sync.
Deletes. Search does not return deleted contacts. Subscribe to HubSpot's contact.deletion webhook. Nango can forward those webhooks to your backend after attributing each event to the right connection.

Conclusion

Syncing large amounts of contacts from HubSpot requires both of HubSpot's contact endpoints. Search filters by lastmodifieddate but caps at 10,000 results. The basic list endpoint has no cap but cannot filter. A reliable sync uses both, with checkpoints that resume cleanly across runs and durable infrastructure underneath: OAuth refresh, retries, rate limit handling, and webhook routing.

With Nango, the sync logic is a code function your AI coding agent generates from a prompt, while the infrastructure is managed for you. The same approach works for HubSpot companies, deals, tickets, and any of Nango's 700+ supported APIs.

Related reading:

Best agentic API integrations platform in 2026

Sapnesh Naik — Fri, 24 Apr 2026 10:26:14 +0000

TL;DR

An agentic API integrations platform is where coding agents (like Claude, Cursor) build API integrations and AI agents in your product call them at runtime. The platform gives you three things in one stack: integrations-as-code (prompted by you and written by your coding agent), a secure, scalable runtime, and Managed Auth for external APIs with data sync. It is the successor to embedded iPaaS (2010s, low-code) and closed unified APIs (early 2020s, narrow scope).

An agentic API integrations platform also enables you to set up just-in-time integrations, where integrations are generated on demand using an AI coding agent and consumed by other AI agents in production.

Three platforms worth evaluating in 2026:

Nango: An agentic API integrations platform supporting 700+ APIs. Coding agents build integrations with the Nango AI builder skill, running against a secure and scalable runtime. AI agents consume those integrations through an MCP server, tool calls, webhooks, and data syncs. Open-source.
Arcade: An MCP-first runtime for agent tool calling with permission checks and evaluation testing. Catalog of 112 first-party integrations, focused on the run side only. Not fully agentic.
Composio: A closed-source tool library for agent integrations across 500+ apps. No code-level customization, no data syncs or webhooks, limited observability. Not fully agentic.

Agentic API integrations: A new platform category

For more than a decade, teams built product integrations by hand. Read the API docs, implement OAuth, handle pagination, write error handling, test, ship, and maintain. A typical team shipped 3 to 5 integrations per quarter. However, customers now ask for integrations with hundreds of tools. Engineering cannot pre-build every use case one at a time.

Two things changed since October 2025:

AI coding agents can build integrations autonomously: Claude Code, Cursor, Codex, and Gemini CLI can read API docs, iterate on a failing request, and produce a working integration. We built 200+ integrations in 15 minutes using OpenCode and the Nango builder skill.
Every AI agent needs API access at runtime: Agents need to read context from external systems to understand the task and take action to complete it. Common examples include fetching a customer record from the CRM, sending a Slack message, drafting an email in Gmail, or updating a ticket in Linear.

These two shifts collapse into the same use case. The agent that uses the integration is increasingly likely to ask another agent to build what it needs. This is the idea behind just-in-time integrations: integrations generated on demand, prompted by an engineer, another agent, or an end customer, rather than pre-built by the platform for every use case. Instead of handcrafting each integration, teams build an integration factory. The more the coding agent does, the less human involvement is needed.

What is an agentic API integrations platform?

An agentic API integrations platform lets engineers and coding agents build, run, and maintain integrations at scale.

1. AI coding agents build integrations:

The platform exposes skills, SDKs, and a testing loop (test runs against real APIs, real credentials, real logs) so a coding agent (like Claude, Cursor, Codex) can author, test, and deploy integrations end to end. Integrations are code in your repo, so your team keeps full version control, review, and audit.

2. AI agents in production consume integrations:

The platform exposes the same integrations as typed tool calls, MCP servers, data syncs, and webhook triggers, so product-facing agents can reliably act on external systems.

3. Developers stay in control:

The integration is code that your engineers can read, review, and edit. Coding agents can write integrations end-to-end, or a human engineer can drive a coding agent with review on every change. The platform supports both modes, so teams move fast without losing control of what ships.

As you can see, the word "agentic" has two implications. On the build side, agents produce the integration code. On the run side, agents consume the integration at runtime. An agentic API integrations platform supports both.

Supporting both the run and the build side matters because platforms that do only one side of the job hit a wall quickly. A tool library without a build workflow cannot quickly scale API integrations, customize integrations for specific customers, or react to schema changes in the external API. A coding assistant without a runtime cannot ship anything to production.

Agentic API integrations platform vs. earlier categories

Category	Era	Builder	Consumer	Limitations
Embedded iPaaS	2010s	Human in a low-code editor	Human end user	Visual builders, AI coding agents cannot build using the platform, nor can AI agents consume integrations
Unified API	Early 2020s	Platform vendor (fixed catalog)	Backend engineers	Constrained schemas, limited categories covered, no customization
Agentic API integrations platform	2026+	AI coding agent or backend engineer in your repo	AI agent in your product, or your SaaS	Emerging category

For deeper context on the older categories, see how Nango differs from embedded iPaaS and unified APIs, what is an embedded iPaaS, and what is a unified API.

What to look for in an agentic integrations platform

Evaluate a platform against the build side, the run side, and the runtime that connects them.

Build side: Can AI coding agents build integrations on it?

A dedicated skill or SDK that encodes integration patterns (auth, pagination, delete detection, checkpoints, error handling) so the agent does not start from a blank file.
Compatibility with the coding agents your team already uses: Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot, OpenCode.
A testing command that executes generated code against a real connection and surfaces real API responses, so the agent can iterate on actual errors instead of hallucinating.
Deployment through CI/CD with version control, unlimited environments, and no vendor-specific build pipeline.

Run side: Can AI agents consume integrations at runtime?

A built-in MCP server so agents speak a standard protocol.
Typed tool calls with strict input and output schemas so the LLM does not guess parameters.
Real-time triggers (webhooks, polling) so agents react to provider events, not just initiate requests.
Data syncs to enhance the context of your agent (for example, RAG) and keep data fresh across millions of records.

Runtime and security:

Managed authentication across OAuth, API keys, JWT, basic auth, and MCP Auth.
A white-label, drop-in auth UI so end users authorize under your brand, not the platform's.
Tenant isolation and per-customer resource limits, since one customer's integration should never affect another's.
Deep, real-time observability: full request and response logs, custom log messages, and OpenTelemetry export. Both agents and humans need to read failures.
Per-customer configuration for custom field mappings and tenant-specific behavior.

Use this checklist when evaluating any platform in the category.

Best agentic API integrations platforms

1. Nango

Nango is an open-source agentic API integrations platform. Coding agents can build and maintain integrations on it using the Nango AI builder skill. AI agents inside your product call those integrations at runtime through an MCP server, tool calls, webhooks, and data syncs.

Nango supports 700+ APIs out of the box and is used as core infrastructure by hundreds of fast-growing AI companies.

Best for

Teams building production AI agents that want coding agents to generate integrations on demand, with a secure and scalable runtime to execute them. Includes runtime primitives (MCP, tool calls, syncs, webhooks) to expose those integrations to the AI agents inside a SaaS product.

Pros

AI builder skill for 18+ coding agents: Install with one command, and the skill gives Claude Code, Cursor, Codex, Gemini CLI, OpenCode, and others the context to research an API, write the integration, test it against a real connection, and iterate on real errors. See the walkthrough of building a real-time Google Calendar API integration end-to-end with the Nango AI builder skill.

  # Install the Nango skills for your coding agent
  npx skills add NangoHQ/skills

  <!-- Sample prompt -->

  Build a Nango sync that fetches events from the primary Google Calendar.

  Should run hourly, backfill on initial sync for the last 30 days and
  all future events. After the first run, only fetch future events
  incrementally.

  Return at least:
  - Event title
  - Start and end date
  - Location
  - RSVP status
  - Attendees list (email, display name, response status)

Test generated code against real APIs: AI coding agents use the Nango CLI, which includes a dryrun command that executes generated code against a real connection, returns real responses, and lets the agent iterate until tests pass. This closes the loop that most coding agents lack when building integrations.
Built-in MCP server and typed tool calls: Nango exposes every action as a typed, deterministic tool call through a REST API or MCP server. Agents see clear input and output schemas, reducing the risk of hallucinations.
Beyond tool calls on the same platform: Native data syncs for RAG, webhook processing, polling triggers, per-customer configuration, and an extensible unified API layer. Your agent can read context, react to events, and take actions all within the same platform.
White-label auth across 700+ APIs: A drop-in UI component handles OAuth, API keys, JWT, basic auth, and MCP Auth. Custom credential validation and token refresh are built in. Your end users authorize under your brand.

Low-overhead, tenant-isolated runtime: Tool calls add less than 100ms of overhead. The serverless execution runtime automatically scales during traffic surges and isolates each customer. Syncs use durable checkpoints to resume across millions of records.
Real-time observability with OpenTelemetry: Every operation generates structured logs with full request and response details. Custom log messages, full-text search, and export through OpenTelemetry. A coding agent can read a failing run, find the exception, and fix the code autonomously.

Playground: Trigger syncs and actions from the dashboard to validate end-to-end behavior before wiring them into your product.
Role-based access control: Control who on your team can edit, deploy, or manage integrations and connections.
Enterprise compliance and hosting: SOC 2 Type II, GDPR, HIPAA. Enterprise self-hosting is available for teams that need full data isolation.

2. Arcade

Arcade is an MCP-native runtime for agent tool calling. It exposes a pre-built tool catalog, an SDK for custom MCP servers, and evaluation tools for testing agent behavior against scripted scenarios.

Best for

Teams building MCP-first agents focused on tool calling. Best suited if you don't need broader integration patterns like data syncs or webhooks, or AI coding agent support.

Pros

MCP-native: every tool runs through the Model Context Protocol, which standardizes how agents discover and call tools.
Automatic user permission checks before tool execution.
SDK to build custom MCP servers that run on Arcade's runtime.

Cons

Arcade's SDK targets human developers who write and package custom MCP servers locally. There is no dedicated skill for Claude Code, Cursor, or similar agents. No integrated testing loop against a real connection, and no path for a coding agent to author and deploy a new tool end-to-end inside Arcade.
Tool calls are the only pattern. No data syncs to feed agent context, no webhook processing, no unified API layer.
First-party integrations are approximately 112 as of March 2026 (48 hand-built, 57 auto-generated, plus community contributions).
No per-customer configuration.

3. Composio

Composio is a developer-facing tool library for AI agents. It ships managed auth and a large catalog of pre-built tools wrapped in frameworks like LangChain, CrewAI, Autogen, and the OpenAI Agents SDK.

Best for

Teams that want an MCP server with a large pre-built catalog and managed auth. Best suited for internal productivity or personal automation agents rather than product teams needing custom tools or triggers.

Pros

Catalog of 500+ apps accessible through one SDK.
Managed authentication across supported APIs.
Framework adapters for the most popular agent SDKs.
SOC 2 and ISO certified.

Cons

No custom tools on the platform. You cannot deploy a tool you wrote yourself (or had a coding agent write) onto Composio's runtime. If a pre-built tool does not do what you need, you are blocked until Composio adds it.
No custom triggers. Composio does not let you define webhook or schedule-based triggers for your integrations, so event-driven or scheduled work has to live elsewhere.
There is no dedicated AI builder skill, no repo-level code-generation workflow, and no real API test loop to iterate on integration code.
Tools are closed-source. You cannot inspect or modify the code of a pre-built tool.
No data syncs to feed agent context, no webhook processing, no per-customer tool configuration.
Observability is basic. You cannot add custom log messages, inspect full request and response details, or export traces via OpenTelemetry.

For a deeper comparison, see our best Composio alternatives post.

Comparison table

Capability	Nango	Arcade	Composio
AI coding agent skill (build-time)	Yes, 18+ agents supported	SDK only	None
Test against real API	Yes	Partial	No
MCP server (runtime)	Yes	Yes	Yes
Typed tool calls	Yes	Yes	Yes
Data syncs for agent context	Yes (durable, incremental)	No	No
Webhook processing	Yes (high-throughput)	No	No
Per-customer configuration	Yes	Enterprise only	No
White-label auth UI	Yes, drop-in	Limited	Limited
Open-source templates	Yes	Partial (SDK)	No
Self-hosting	Yes (Enterprise)	VPC, on-prem	No
Primary focus	Full agentic platform (build + use)	MCP runtime	Tool library
Supported APIs	700+	~112 first-party	500+

Why AI coding agents change what "best" means

The short answer is that "best" is no longer about who has the largest closed catalog. It is about the platform that lets your team ship integrations as fast as the coding agent can generate them, and exposes the result to AI agents reliably at runtime.

Three loops compound here:

The Build loop: An integration platform with good coding-agent skills, real-API testing, and secure, real-credential access lets an agent produce a working integration in under an hour. Without that loop, the agent hallucinates endpoints and ships non-working code.
The Run loop: An agentic API integrations platform exposes every integration as a typed tool call or an MCP endpoint, with managed auth and observability, so the AI agent in your product can call it reliably in production.
The Maintain loop: When an integration fails, the logs need to be accessible so that a coding agent, not just a human, can read the exception, trace the failing request, and ship a fix.

Nango is the only platform in this comparison that treats all three loops as first-class, and the only one where the same code an agent builds today runs unmodified in a hardened tenant-isolated runtime tomorrow.

FAQ

What makes a platform "agentic"?

A platform is agentic when AI agents are first-class on both sides. Coding agents can build and deploy integrations with a real testing loop. Product-facing AI agents can call those integrations as tool calls, MCP endpoints, or triggers at runtime.

Is an agentic API integrations platform the same as a unified API?

No. A unified API normalizes data from multiple providers into a single schema. It is built for backend engineers to query a fixed catalog. An agentic API integrations platform is built for AI agents on both sides: coding agents that produce integrations and product agents that consume them. Many agentic platforms can expose a unified API layer when needed, but that is one capability, not the whole category.

Can AI coding agents like Claude Code or Cursor build integrations on these platforms?

Only where the platform ships a dedicated skill or harness. Nango's AI builder skill works with 18+ coding agents and includes a test command that runs generated code against a real connection. Other platforms in this post provide SDKs but do not yet ship a production-grade coding-agent workflow.

Do AI agents need an MCP server?

Not always. MCP is useful when the agent framework expects a standard protocol for discovering tools (for example, Claude Code or agents exposed through LangSmith). Many agent products also use REST APIs for integration, which is simpler and more deterministic. A good agentic platform supports both, so you pick per use case. See our note on avoiding MCP for production reliability, where custom tool calls are a better fit.

How does an agentic integration platform help with just-in-time integrations?

Just-in-time integrations are generated on demand when a customer requests one in your product. The platform provides the sandbox where a coding agent writes the integration, the runtime that executes it with managed auth and tenant isolation, and the observability layer that lets agents read failures and fix themselves. Nango is the open-source factory for this pattern.

Can I use these platforms with LangChain, CrewAI, or the OpenAI Agents SDK?

Yes. All three platforms in this post expose integrations via a combination of REST APIs, MCP servers, and native SDKs that work with LangChain, CrewAI, the OpenAI Agents SDK, the Vercel AI SDK, and the most popular agent frameworks.

Conclusion

The "best agentic API integrations platform" is a simple question with a layered answer: the platform needs to serve AI coding agents that build integrations and AI agents that use them, on a runtime that a team can trust in production.

Nango is the only platform in this comparison that treats both sides as first-class. Coding agents build and maintain integrations through the AI builder skill, testing generated code against real APIs end to end. Product-facing AI agents consume those integrations through an MCP server, tool calls, webhooks, and data syncs. Integrations are code in your repo, running on a secure and scalable runtime, so your team stays in control of every layer while AI agents do most of the work.

Best Arcade.dev alternatives for AI agent integrations in 2026

Sapnesh Naik — Tue, 21 Apr 2026 06:34:25 +0000

TL;DR

Arcade.dev is an MCP runtime that executes authenticated tool calls for AI agents. It works well for MCP-first teams that need a hosted runtime and user-scoped auth. But production AI agents usually need more than tool calls: continuous data syncs for RAG, webhook ingestion, and deep observability across API integrations.

If you are evaluating alternatives, pick the one that covers your full integration surface: not just the tool calls you need today, but the data syncs, webhooks, auth, and observability your agents will need once they ship to real customers.

Top Arcade.dev alternatives for 2026:

Nango: Best for teams building production AI agent API integrations that need tool calls, data syncs, webhooks, and auth on a single code-first platform. Supports 700+ APIs with open-source tools and works with Claude Code, Cursor, and other AI coding agents.
Composio: An MCP-native alternative aimed mainly at internal and personal automation agents. Larger pre-built catalog than Arcade (500+ apps), but closed-source tools and no data syncs, webhooks, or per-customer configuration.
Pipedream Connect: Fits teams that prefer a low-code, UI-based workflow builder with a large action library.
Merge Agent Handler: Fits teams that want pre-built MCP tool-packs for common SaaS actions and don't need custom tool logic or data syncs.

Why teams look for Arcade.dev alternatives

Arcade.dev positions itself as the MCP runtime that makes AI agents production-ready. It handles OAuth, runs tool calls, and supports server-level and tool-level authorization.

That positioning works well for a specific profile: teams that are already committed to MCP, want a hosted runtime, and only need tool calls. But as teams move from prototyping to production API integrations, several limitations surface.

Drawbacks of using Arcade for production AI agent integrations:

Tool calls only: Arcade is a tool-calling runtime. It does not offer data syncs (for RAG pipelines), webhook ingestion, polling triggers, or unified APIs. If your AI product needs external data continuously kept up to date, or if it must react to events in Salesforce, HubSpot, or other systems, you need a separate platform.
Narrow first-party catalog: Arcade lists around 24 first-party OAuth providers, which is materially smaller than other platforms in this comparison. Many APIs are only reachable through community MCP servers of varying quality and maintenance.

MCP-dependent architecture: Every tool call flows through MCP. That is useful for prototyping, but generic MCP servers can reduce reliability in production: broad tool definitions inflate the LLM's context, and handing off multi-step logic to the agent increases hallucination risk.
Limited observability: Arcade provides basic logs of tool executions. Teams that need full request and response payload inspection, custom log messages inside a tool, or OpenTelemetry export find the logging surface narrow.
For example: During our testing, we ran a suggested /reddit tool call inside Arcade's Playground. It failed with an invalid Client ID error, but the failed execution never showed up in the Audit Logs page. Small gaps like this point to a platform that is still maturing in production, where several features are described as aspirational or in progress.

No per-customer configuration: Arcade tools are defined at the server level, not per tenant. There is no built-in support for tenant-specific custom field mappings, per-customer tool behavior, or custom auth validation. Every customer gets the same tool surface.

These constraints are manageable for chat assistants and prototypes. They become real limits when AI agents are a core product feature that must run reliably across customers.

Best Arcade.dev alternatives

1. Nango

Overview

Nango is an open-source integration platform for AI agents and SaaS products. It provides a unified interface for API auth, custom tool calls, data syncs, webhooks, and an MCP server, all on a single platform.

Nango supports 700+ APIs out of the box and is used by hundreds of fast-growing AI agent companies as core infrastructure for their API integrations.

Best for

Teams building production AI agent API integrations that need tool calls, data syncs for RAG, webhooks, and auth across a wide range of APIs on a single code-first platform.

Pros

Broad API coverage across 700+ APIs: Pre-built auth for OAuth, API keys, JWT, basic auth, and the new MCP Auth standard. White-label by default, so end users authorize your app, not Nango. You can also contribute support for new APIs yourself.

Code-first with AI coding agent support: Tool definitions are functions that live in your git repo and deploy through CI/CD. The Nango AI Integration Builder works with Claude Code, Cursor, Codex, or any AI coding assistant, so you can generate and iterate on custom tools, syncs, and webhook handlers in minutes.

  # Install the Nango skills for your coding agent
  npx skills add NangoHQ/skills

  <!-- Sample prompt -->

  Build a Nango sync that fetches events from the primary Google Calendar.

  Should run hourly, backfill on initial sync for the last 30 days and
  all future events. After the first run, only fetch future events
  incrementally.

  Return at least:
  - Event title
  - Start and end date
  - Location
  - RSVP status
  - Attendees list (email, display name, response status)

Open-source, customizable tools: Nango's pre-built integration templates are open source. You can clone an existing tool, modify it for your use case with a coding agent, and deploy it to your account. This is the opposite of the closed tool model used by many MCP-first platforms.
Built-in MCP server: Nango exposes your custom tool calls through an MCP server. The flow is Agent to Nango MCP to your own custom tools. That keeps the agent's context focused on the specific tools you have built instead of flooding it with hundreds of generic ones.
Beyond tool calls, on the same platform: Native resumable data syncs (for RAG), webhook processing, polling triggers, and per-customer configuration. A built-in Playground lets you test tool calls, syncs, and triggers interactively before wiring them into your agent, and role-based access control (RBAC) scopes access across teammates.
Deep real-time observability: Every operation generates detailed logs with full API request and response details, error messages, and custom log messages. Everything exports via OpenTelemetry.
Scalable runtime with low overhead: Nango adds less than 100ms overhead on tool calls, isolates each customer's executions with tenant-level fairness, and auto-scales under webhook bursts.
Enterprise-grade compliance: SOC 2 Type II, GDPR, and HIPAA compliant. Enterprise self-hosting and VPC deployments available.

2. Composio

Overview

Composio is an AI agent integration platform with a catalog of 500+ apps. It acts as an MCP gateway: every integration is automatically exposed through a standardized MCP interface, on top of managed OAuth and pre-built tool definitions.

Best for

Teams building internal or personal automation agents that want an MCP-native alternative to Arcade with a larger pre-built catalog and managed auth, and that do not need data syncs, webhooks, or per-customer configuration.

Pros

Larger catalog than Arcade: Pre-built tool definitions across 500+ apps, covering Slack, GitHub, Notion, Gmail, Salesforce, and more.
MCP gateway: Every integration is auto-exposed through MCP so you can expose tools to MCP-Compatible clients (like Claude Desktop, Cursor)
Managed OAuth: Handles token acquisition, refresh, and scope management out of the box.
Broad framework support: Works with LangChain, CrewAI, OpenAI Agents SDK, and the Vercel AI SDK.

Cons

Closed-source tools: You cannot inspect or modify the code of Composio's pre-built tools. If a tool does not match your requirements, you build a replacement from scratch outside the platform.
No data syncs or webhooks: Composio focuses on tool calls. RAG pipelines that need continuously updated external data, or agents that react to real-time events, require a separate system.
Limited per-customer configuration: Every customer gets the same tool behavior. Tenant-specific field mappings, custom auth validation, or per-customer tool logic are not supported.
Observability constraints: Basic execution logs. Custom log messages inside tool code and OpenTelemetry export are limited compared to code-first platforms.

3. Pipedream Connect

Overview

Pipedream Connect is the embedded version of Pipedream's serverless integration platform. It exposes MCP servers per app and gives agents access to a large library of pre-built actions across 2,800+ apps.

Best for

Teams that prefer a low-code workflow builder and need wide catalog coverage for internal-facing or lightly customized agent use cases.

Pros

Large action library: 10,000+ pre-built actions across 2,800+ apps give agents a wide default surface area.
MCP server per app: Dedicated MCP servers per supported app, so agents can discover and call tools through the protocol.
Low-code workflow builder: Useful for teams that want to assemble multi-step tool-call logic visually.

Cons

Acquired by Workday: Pipedream was acquired by Workday (an Enterprise HR platform) in November 2025. You can read their announcement here.
Non-standard action schemas: Action inputs use Pipedream-specific types ("alert props," "dynamic props," "external props") that require a learning curve and limit compatibility with external tooling.
Complex action configuration: Most actions must be "configured" before they can run, often requiring 2-5 additional API requests. That adds latency and friction for background agents.
No data syncs: Pipedream Connect does not offer scheduled or incremental data syncs, so RAG implementations need another platform for ongoing data ingestion.
Limited white-label auth: End users see Pipedream branding and consent to Pipedream during OAuth, which is a problem for enterprise-facing products.

4. Merge Agent Handler

Overview

Merge Agent Handler is a separate product from Merge's traditional unified API. It lets teams create custom MCP servers with specific pre-built Merge integrations enabled, giving an AI agent a defined set of capabilities.

Best for

Teams that only need pre-built MCP tool-packs for common SaaS actions (for example, fetch tickets from Linear, create an issue in GitHub) and do not need custom tool calls, data syncs, or custom object and field support for CRM and ERP integrations.

Pros

Pre-built tool-packs: Bundle relevant integrations for a specific agent and restrict the available tools, for example a read-only tool-pack for ticketing.
Playground: A testing environment to validate MCP behavior before deploying.
Public MCP import: You can import any public MCP server and edit tool schemas to fit your agent.

Cons

Narrow connector library: Merge Agent Handler supports around 110 pre-built connectors. If the API you need is not covered, you fall back to public MCP servers.
No custom tool calls: You cannot build custom tool logic on the platform. Agents are constrained to the pre-built surface, which can force the LLM to chain multiple tool calls for a single business action.
No Custom fields support: Pre-built tools do not handle custom fields or objects well, which is common in enterprise Salesforce or HubSpot deployments.
No data syncs: No support for continuous data syncs, so RAG pipelines need a second platform.
MCP Auth gaps: Some APIs, such as HubSpot's remote MCP server, require MCP Auth. Merge Agent Handler currently supports standard (non-MCP) auth for most providers.

Comparison of Arcade.dev alternatives

Feature	Nango	Composio	Pipedream Connect	Merge Agent Handler
Primary focus	Agentic, code-first AI agent and product integrations	MCP-first tool calling	Low-code embedded workflows	Pre-built MCP tool-packs
Supported APIs	700+	500+	2,800+	~110
Tool customization	Full (code-first, open source)	Limited (closed tools)	Low-code workflows	No custom tool code
AI agent (LLM) tool calls	Yes (custom, code-first)	Yes (pre-built)	Yes (pre-built actions)	Yes (pre-built)
AI coding agent support (Claude Code, Cursor)	Yes (optimized tools and skills)	No	No	No
MCP server	Yes (on your custom tools)	Yes (auto on all tools)	Yes (per app)	Yes
Data syncs for RAG	Yes (native, incremental)	No	No	No
Webhook processing	Yes (high throughput)	No	Triggers only	No
Per-customer configuration	Yes	Limited	Limited	Limited
Observability	Deep (OpenTelemetry, custom logs)	Basic	Basic	Basic
Auth model	White-label (your brand)	Managed	Pipedream-branded	Platform-managed
Open source	Yes	Partial (closed tools)	Partial	No
Self-hosting	Yes (Enterprise)	No	No	No

How we evaluated these platforms

We assessed each Arcade.dev alternative across five dimensions that matter for production AI agent integrations:

Catalog breadth and extensibility: How many APIs are supported out of the box? Can you add new APIs yourself without waiting on the vendor?
Tool customization: Can you build and modify tool logic in code? Can AI coding agents (Claude Code, Cursor, Codex) help generate or refactor tools?
Integration patterns beyond tool calls: Does the platform support data syncs for RAG, webhooks, polling triggers, and per-customer configuration?
Observability: Are there full request and response logs, custom log messages inside tool code, and OpenTelemetry export?
Deployment and auth model: Is auth white-label and tenant-safe? Is self-hosting available for regulated workloads?

Which alternative should you choose?

You are building production AI agent integrations with broad requirements: Choose Nango. It is the only platform in this comparison that combines pre-built tool calls, data syncs, webhooks, and unified APIs on a single code-first platform, with 700+ APIs and AI coding agent support for building custom tools fast.

You want an MCP-native alternative to Arcade with a larger catalog: Consider Nango or Composio. They both give you pre-built tools behind an MCP gateway.

You prefer a low-code workflow builder with a large catalog: Pipedream Connect fits, especially for internal-facing agents.

You only need standard, pre-built tool-packs: Merge Agent Handler can work for ticketing, CRM reads, and other common SaaS actions. Confirm that your APIs are supported and that you do not need data syncs or deep customization.

FAQ

What is the best Arcade.dev alternative for production AI agents?

Nango is a strong fit for teams building production AI agent API integrations. It supports 700+ APIs, code-first custom tool calls with AI coding agent support, data syncs for RAG, webhooks, and deep observability with OpenTelemetry. Unlike Arcade, it is not limited to tool calls and exposes an MCP server on top of your own custom tools instead of relying on public MCP servers.

Does Arcade.dev support data syncs or webhooks?

No. Arcade.dev is a tool-calling runtime. It does not provide scheduled or incremental data syncs, webhook ingestion, or polling triggers. If your AI agent needs continuously updated external data for a RAG pipeline, or must react to events in Salesforce or HubSpot, you need a separate platform. Nango supports all of these on a single platform alongside tool calls.

Is Arcade.dev open source?

Arcade.dev's SDK and MCP server framework are open source, so you can build custom MCP servers and self-host. The platform itself (runtime, catalog, managed auth) is a hosted product. Nango, by contrast, is fully open source on GitHub, and all of its pre-built integration templates are open and editable.

Can I use Arcade.dev alternatives with LangChain, CrewAI, or the OpenAI Agents SDK?

Yes. Nango, Composio, Pipedream Connect, and Merge Agent Handler all expose tools through standard interfaces (REST APIs and/or MCP servers) that work with any agent framework. Nango's MCP server and REST API integrate with LangChain, CrewAI, OpenAI Agents SDK, Vercel AI SDK, and Mastra. Composio is MCP-native and works with any MCP-compatible client.

Can I build custom tools with Arcade.dev alternatives using AI coding agents?

No, not with Arcade itself. But Nango is designed for this: tool definitions are code, and the Nango AI Integration Builder provides skills for Claude Code, Cursor, and other coding assistants to generate and refine tool calls, data syncs, and webhook handlers. Composio, Arcade, Pipedream Connect, and Merge Agent Handler do not ship dedicated AI coding agent integrations for building tools on their platforms.

Conclusion

Arcade.dev is a focused MCP runtime that fits teams with strict MCP-first requirements and simple tool-calling workloads. Once AI agent integrations become a core product surface, the tool-calling-only scope, narrow first-party catalog, and basic observability start to matter.

Nango covers the broadest set of production requirements on a single platform: 700+ APIs, custom tool calls, data syncs for RAG, webhooks, unified APIs, and deep observability, with AI coding agent support for building everything fast. Composio is a closer direct alternative to Arcade if your scope stays inside MCP tool calls. Pipedream Connect and Merge Agent Handler cover narrower low-code and pre-built use cases.

Start with the hardest integration requirement in your product roadmap. The platform that handles it today will carry you further as your AI agents scale.

Related reading: