DEV Community: Sapnesh Naik

5 best tools to trigger AI agents from incoming emails in 2026

Sapnesh Naik — Mon, 03 Aug 2026 22:32:54 +0000

TL;DR

At many companies, a new task starts as an email from a customer or coworker. An email-based trigger lets an AI agent derive context from the message and start performing a task.

A production email trigger must deliver events reliably across providers, authenticate each mailbox, route events to the correct user, recover missed notifications, and give the agent scoped access to the APIs it needs after reading the message.

We compared five such tools for developers building customer-facing agents. The main differences are mailbox coverage, trigger latency, customizability, coding-agent support, and whether the same platform lets the triggered agent act in other APIs.

Nango: Best overall for customer-facing agents that start from email and act across other APIs. It supports webhooks for Gmail, Microsoft, iCloud, and IMAP integrations. It also provides 6,000+ pre-built tool calls across 900+ APIs, including CRM, ERP, banking, and e-commerce.
Nylas: Best for one unified email API. Its webhook hides provider differences, but its catalog is limited to communications APIs. Actions in a CRM, help desk, or accounting system need another integration product.
Pipedream Connect: Best for internal automations built in a low-code visual workflow editor, with the option to add snippets of code.
AgentMail: Best when the agent needs its own programmable inbox. It cannot connect an existing Gmail or Outlook mailbox, and actions in other APIs need another platform.
Composio: Best for personal agents and internal automations that use pre-built Gmail or Outlook triggers. Gmail polling can take about 15 minutes.

Tool	Existing mailbox coverage	New-email delivery	Actions after the email	Coding-agent build support	Best for
Nango	Gmail, Microsoft 365, Outlook, Exchange, Yahoo, iCloud, Fastmail, Zoho, and IMAP	Webhooks or custom polling sync	6000+ tools across 900+ APIs	Dedicated skill to build, test, and deploy	Customer-facing agents with custom workflows
Nylas	Gmail, Microsoft 365, Outlook, Exchange, Yahoo, iCloud, and IMAP	Normalized webhook	Email, calendar, and contacts; other APIs require another platform	No dedicated integration builder skill	Unified email API across providers
Pipedream Connect	Gmail and Outlook	Provider trigger or configurable polling	Workflow components	No dedicated integration builder skill	Low-code internal workflows
AgentMail	AgentMail-hosted inboxes only	Webhook or WebSocket	Email only; other APIs require another platform	No dedicated integration builder skill	A dedicated email identity for an agent
Composio	Gmail and Outlook triggers	Outlook real time, Gmail polling	500+ toolkits	No dedicated hosted custom-trigger builder	Personal agents and internal automations

Why trigger an AI agent from email?

Email remains the front door for a lot of operational work. Customers send support requests, prospects reply to sales threads, vendors submit invoices, and candidates attach resumes. An agent can start that work when the message arrives, rather than waiting for someone to copy it into another system.

Common implementations include:

Customer support: classify the request, fetch account context from a CRM, update the help desk, and draft a reply for approval.
Sales operations: enrich an inbound lead, create or update the CRM record, assign an owner, and notify the right Slack channel.
Accounts payable: extract an invoice, validate it against the vendor record, create a draft bill, and route exceptions to a human.
Recruiting: parse a resume, check for an existing candidate, update the ATS, and schedule the next step.
Agent identities: give a browser or research agent its own address so it can receive sign-in codes, files, and replies without access to a human mailbox.

Many AI agent systems use email as the trigger, then call other APIs to retrieve data and perform tasks.

Challenges of supporting multiple email providers

Customer-facing agents often need to support multiple email providers, each with a different event model. A platform that supports only one trigger mechanism leaves gaps when customers connect another kind of mailbox.

Gmail and Google Workspace

First, create a Google Cloud Pub/Sub topic and call the watch API for each mailbox. Notifications identify the mailbox and its latest historyId, but do not include the changed message. Call history.list to find the change, then fetch the message (Gmail push notification docs).

Note: Google requires each Gmail watch to be renewed at least every seven days and recommends daily renewal.

Microsoft 365, Outlook, and Exchange

You subscribe to created, updated, or deleted changes on a message resource and receive them at a webhook URL. Message subscriptions expire in under seven days, and Microsoft limits applications to 1,000 active Outlook subscriptions per mailbox (Microsoft Graph subscription reference).

IMAP: iCloud, Yahoo Mail, Fastmail, and private mail servers

Apple has IMAP for reading iCloud Mail, not a public email webhook API (Apple’s iCloud Mail server settings). An IMAP server may support the IDLE extension for change notifications. Otherwise, the integration must poll for messages after the last stored UID (RFC 2177).

The platform should handle these event models without requiring separate authentication, subscription renewal, routing, and retry systems for every provider.

What to look for in an email trigger platform

We used seven criteria for this comparison.

Mailbox coverage: Can customers connect Gmail, Outlook, Microsoft 365, Exchange, iCloud, Yahoo, Fastmail, and generic IMAP accounts? Does the tool also support inboxes owned by agents?
Webhook and polling support: Can the platform use the provider’s native event system when available and run an incremental poll when it is not?
Per-user authentication: Can each customer connect an account through your product, with tokens stored and refreshed outside the agent?
Connection routing: Does every event identify the right tenant and mailbox without a custom lookup system for each provider?
Tool access after the trigger: Can the agent update a CRM, create a ticket, send a Slack message, or call another API with the same user’s credentials?
Customization and ownership: Can you change filters, sync state, message parsing, and tool logic in code? Can a coding agent help build and test it?
Production controls: Signed delivery, retries, deduplication, logs, tenant isolation, and a polling safety net all matter once the agent can write to customer systems.

The 5 best tools for AI agent email triggers

1. Nango

Nango lets you connect your AI agent to 900+ APIs. It ships with 6,000+ pre-built tools, customizable with coding agents, on infrastructure built for scale.

For email-driven agents, Nango supports Gmail, Microsoft 365, Outlook, Exchange, and more through their provider APIs. Nango receives provider webhooks, runs scheduled syncs, and exposes approved actions through an API or MCP.

The triggered agent can then act in CRM, help desk, calendar, messaging, accounting, and other APIs without receiving raw credentials.

Best for

Product teams building customer-facing agents that need custom email triggers for multiple email providers and tool calls beyond the mailbox.

How the email trigger works

Enable the integrations for the email providers you need, using Nango’s pre-provisioned OAuth apps or your own client IDs and secrets. Next, enable the pre-built tool calls or syncs the agent needs for each integration.

For customization, use the Nango function builder skill with Claude Code, Cursor, Codex, or another coding agent to describe the mailbox trigger. When a new email is detected, Nango identifies the matching user connection and sends a webhook event to your application. Your handler can then queue the AI agent with the correct customer and message context.

Pros

Broad API coverage after the trigger: along with Gmail, Microsoft mail APIs, and IMAP-compatible providers, Nango provides auth and tools for the CRM, help desk, Slack, accounting, calendar, and storage APIs that the agent will act on next.
Fast triggers with a recovery path: use provider webhooks for low latency and a scheduled incremental sync to recover notifications that never arrived.
Full email API access: the agent can use provider-specific fields, Gmail labels, Outlook categories, custom headers, and endpoints via Nango’s proxy, rather than being limited to a fixed email schema.
6,000+ pre-built tools: start with Gmail template actions for listing messages, managing labels, creating drafts, and sending replies. A coding agent with the Nango builder skill can customize or replace any function.

Production runtime: retries, per-connection logs, OpenTelemetry export, and customer-level routing are built into the platform.
Multiple deployment options: use Nango Cloud, deploy a fully managed instance in your own cloud account and region through BYOC, or self-host the open-source runtime.

Cons

No visual workflow canvas: Nango is a better fit for engineers and coding agents than non-technical operations teams building one-off automations.

2. Nylas

Nylas provides a normalized email, calendar, and contacts API. Its Email API supports the major hosted providers and generic IMAP mailboxes.

Nylas exposes a message.created webhook for new mail. One webhook subscription covers connected accounts, and the payload includes the grant and message IDs needed to fetch the full message. Nylas also offers message.created.cleaned, which can deliver a cleaned Markdown body for agent processing, and Agent Accounts for inboxes owned by agents.

Best for

Teams that want one hosted email API across multiple providers and expect agent workflows to stay within communications APIs.

Pros

Wide mailbox coverage: Gmail, Outlook, Exchange, Yahoo, iCloud, and IMAP use the same message schema.
Simple new-email subscription: message.created hides Gmail Pub/Sub and Microsoft Graph subscription differences.
Agent-friendly payloads: cleaned-message webhooks can remove quoted replies and return Markdown instead of raw HTML.

Cons

Narrow API scope: the catalog covers email, calendar, and contacts. An agent that needs to act in CRM, ticketing, accounting, or messaging systems requires a separate integration platform.
Normalized schema: the abstraction is convenient until the agent needs a provider-specific Gmail or Microsoft Graph field or endpoint that Nylas does not expose.
Less control over the event implementation: Nylas owns the provider sync and webhook abstraction. You consume its model rather than changing the underlying trigger code.
No coding-agent build skill: Nylas does not provide a dedicated skill for Claude Code, Cursor, or Codex to build, test against a real connection, and deploy custom integration logic.

3. Pipedream Connect

Pipedream Connect exposes pre-built triggers through an SDK and a low-code visual workflow builder. A developer can deploy a Gmail or Outlook trigger for a specific external user and then route each event to a Pipedream workflow or an application webhook.

Best for

Internal email automations built in a low-code visual editor, with the option to add snippets of code.

Pros

Large component catalog: more than 10,000 pre-built actions and triggers are available to a workflow or agent.
Configurable polling: polling sources accept an interval in seconds. Pipedream’s documentation shows a 60-second configuration as an example.
Code snippets when needed: add Node.js, Python, Go, or Bash steps inside a visual workflow.

Cons

Workflow-first development: important logic and configuration live in the Pipedream project rather than as code in your application repo.
Production constraints: running workflows for end users in production requires a higher-tier plan, and end-user workflows have account-selection limitations.
No coding-agent integration skill: Pipedream does not provide a dedicated skill that guides a coding agent through researching, testing, and deploying custom provider integrations.
Uncertain roadmap after the Workday acquisition: Workday announced its acquisition of Pipedream in November 2025. Pipedream’s public changelog lists no release after October 2025, so teams should verify the Connect roadmap before adopting it.

4. AgentMail

AgentMail is an email provider for agents. You create an inbox through its API, receive message.received events through a webhook or WebSocket, and use the same API or MCP server to read threads and reply.

AgentMail does not connect to a customer’s Gmail or Outlook account. The agent receives a new address on AgentMail’s infrastructure, or on a custom domain you configure.

Best for

Browser agents, research agents, support agents, and other systems that need a dedicated machine-owned email identity.

Pros

Inbox creation by API: provision one inbox per agent, customer, or workflow without a human OAuth flow.
Real-time events: webhooks and WebSockets deliver received, sent, delivered, bounced, and rejected message events.
Email primitives for agents: threads, replies, attachments, labels, custom domains, semantic search, SDKs, and MCP are first-class features.
Scoped permissions: API keys and webhooks can be limited to an inbox or a group of inboxes.

Cons

Does not connect existing mailboxes: users cannot authorize their Gmail or Outlook inbox. AgentMail explicitly runs as a separate email provider.
Email only: the agent still needs another integration platform to update a CRM, help desk, calendar, or other SaaS API.
No coding-agent integration skill: AgentMail provides SDKs and MCP, but no dedicated skill for building and testing integrations with coding agents.

5. Composio

Composio connects AI agents to pre-built toolkits and trigger types. For email, it provides Gmail and Outlook tools. Outlook events arrive in real time, while Gmail events use polling and can take about 15 minutes with Composio-managed auth.

Best for

Personal agents and internal automations that can use Composio’s pre-built email trigger types.

Pros

Pre-built Gmail and Outlook tools: agents can read messages, manage mailbox objects, and send replies through existing toolkit actions.
One webhook destination: Composio signs events and includes the trigger metadata needed to route them.
Tools outside email: the triggered agent can call actions from other Composio toolkits.

Cons

May 2026 security incident: HubSpot reported that unauthorized access to Composio systems exposed OAuth credentials and API keys used in Composio toolkits. HubSpot rotated credentials used with Composio’s HubSpot toolkit, then found no evidence that HubSpot or its customer accounts were compromised (HubSpot’s security update).
Gmail latency: managed Gmail triggers poll and can take about 15 minutes, which is too slow for time-sensitive support or routing workflows.
Pre-built trigger types: you choose from the triggers that a toolkit exposes. Custom tools can run in your application process, but they do not provide a durable, hosted custom-trigger runtime.
No mailbox data sync: a trigger detects an event, but it does not maintain an incremental local copy of the mailbox for history or recovery.

How to process an email trigger safely

Incoming email is untrusted input. A sender can place prompt-injection instructions in the body, hide text in HTML, or attach a malicious file. Treat the message as data, not as instructions that can override the agent’s policy.

A reliable handler follows this sequence:

Verify the webhook signature before parsing the payload.
Return **`200 OK*`* quickly** and queue the work. Provider delivery should not wait for the LLM.
Deduplicate by event and message ID. Gmail, Microsoft Graph, Nylas, and other systems can deliver the same change more than once.
Fetch the message from the provider when the event contains only a cursor or object ID.
Normalize the content: convert HTML to text, remove quoted history and signatures, and scan attachments before extraction.
Resolve the tenant and connection before loading context or tools.
Give the agent a narrow tool set. A support email should not make payroll or destructive admin tools available. See our guide to reliable and scoped tool calls for the authorization pattern.
Require approval for high-risk writes: refunds, payments, account changes, bulk sends, and access-control changes should stop for a human decision.
Record an audit trail containing the message ID, agent run, tool calls, approvals, and final result.
Run a periodic incremental sync to recover any provider notification that was delayed or dropped.

Which tool should you choose?

Choose Nango when email is the trigger for a customer-facing agent workflow and you need custom provider logic, polling fallbacks, coding-agent support, and tools across many APIs.
Choose Nylas when one normalized Email API matters more than access to non-communications APIs.
Choose Pipedream Connect when your team prefers a low-code visual workflow builder for internal automation.
Choose AgentMail when the agent should have its own inbox instead of acting through a user’s existing address.
Choose Composio for personal agents or internal automation when its pre-built Gmail or Outlook trigger and provider-dependent latency are sufficient, and after reviewing the May 2026 incident for your security requirements.

Zapier, Make, and n8n also trigger workflows from incoming email, but they are better suited to internal automation where a team member owns the workflow.

FAQ

What is the best way to trigger an AI agent from Gmail?

Nango is the best fit when a Gmail email should trigger a customer-facing agent and actions in other APIs. Its coding-agent skill builds the Pub/Sub webhook, history.list sync, watch renewal, and recovery schedule, then Nango runs them with the correct user’s connection.

Can Gmail send a webhook directly to my AI agent?

No. Gmail publishes mailbox-change notifications to a Google Cloud Pub/Sub topic, and the payload contains a cursor rather than the email body. With Nango, Pub/Sub posts to the Nango webhook, Nango resolves the customer connection and fetches the change, then your event handler queues the agent.

How do I trigger an AI agent from Outlook email?

Use Nango when the Outlook trigger also needs to call other customer APIs. A coding agent can build the Microsoft Graph subscription, clientState verification, message fetch, renewal function, and agent event on Nango’s runtime.

How do I trigger an agent from Apple iCloud Mail?

Use a Nango sync when an iCloud email should trigger an agent that also acts in other APIs. A coding agent can build the IMAP IDLE or incremental polling logic, store the last UID, and emit an event when it finds a new message. Nylas is an alternative when you only need a normalized communications API.

Should the agent receive the full email in the webhook?

Usually not. A small event containing the connection, message ID, and cursor is easier to verify, deduplicate, and retry. Fetch the message after the event is queued, then sanitize the HTML and attachments before sending selected content to the model.

Can an email trigger call tools in other APIs?

Yes. With Nango, the email event identifies the user’s connection and the agent calls scoped tools across the same 900+ API catalog. Nango keeps OAuth credentials outside the model, resolves the customer connection, validates tool inputs, and logs each call.

Conclusion

Nylas fits teams that only need one communications API across mailbox providers. Pipedream makes sense for low-code internal workflows. AgentMail provides dedicated inboxes for agents but does not connect existing mailboxes or other APIs. Composio supports pre-built Gmail and Outlook triggers, but teams should evaluate its latency and security history.

For developers building customer-facing agents, Nango covers the path from incoming email to the task that follows. It supports Gmail, Microsoft 365, Outlook, iCloud, and other mailboxes. Provider webhooks and scheduled syncs deliver new-message events to your application, while the same platform gives the agent scoped tools across CRM, help desk, Slack, accounting, and 900+ other APIs. This avoids combining separate platforms for mailbox events and downstream actions.

Best enterprise-grade AI agent integration providers in 2026

Sapnesh Naik — Fri, 31 Jul 2026 01:26:46 +0000

AI agents increasingly connect to external APIs and need API integrations for tasks like refunding payments or updating records in Salesforce. Enterprises are also looking for secure, compliant, and easy-to-integrate platforms for AI agents.

This post compares six integration platforms for enterprise AI agents in detail: Nango, Arcade, Composio, Pipedream Connect, Workato, and Paragon. For the general comparison, see Best AI agent integration platforms.

TL;DR

For an enterprise, the integration platform becomes part of your product’s security surface. It stores customer credentials, executes calls on their behalf, and is reviewed as part of every security review and procurement process.

Three platforms worth evaluating in 2026:

Nango: An integration platform connecting your AI agent to 900+ APIs and 6,000+ pre-built tool calls, customizable with code. SOC 2 Type II, GDPR, and HIPAA with a BAA, deployable in any region via bring-your-own-cloud. Open source.
Arcade: An MCP-native runtime with per-user authorization, scoping credentials per tool. SOC 2 compliant, with RBAC only rolling out in July 2026, and tool calls are not audit logged. No syncs or webhooks.
Composio: A hosted catalog of 1,047 toolkits. Closed-source runtime and a history of security incidents, with governance and audit gated behind the enterprise tier. Suits internal automation more than customer-facing integrations.

We also cover Workato, Pipedream Connect, and Paragon below, but they suit narrower cases than the three above.

What are integration platforms for AI agents?

An integration platform for AI agents sits between an agent and the external APIs it acts on. It handles the work that is time-consuming and security-sensitive to rebuild for every provider: the OAuth handshake and credential storage, a tool definition for each API operation, execution with the correct end user’s credentials, and an audit trail for every call.

In a product with more than one customer, the platform also routes each tenant to its own credentials, checks that the calling user is permitted to run a given tool before it runs, and executes calls in isolation with an audit trail for each call. It also queues each tenant’s work fairly, so one customer’s load does not delay another.

This platform stores your users’ credentials and calls external APIs on their behalf. Those responsibilities place it within the scope of a security review, unlike most dependencies a team adds.

Note: Most platforms expose tools over the Model Context Protocol, direct API calls, or both. The choice is covered in detail in MCP vs tool calls for AI agents.

What makes an agent integration platform enterprise-ready?

We use the following criteria to determine whether a platform meets enterprise requirements. They cover what a security review checks for, and whether the team can ship the integrations its product needs.

Criterion	What to verify
Compliance	SOC 2 Type II and its scope, GDPR with a signed DPA, HIPAA with a BAA
Deployment	Managed cloud, private deployment, self-hosting maturity, EU data residency
Security architecture	Credential encryption, key custody, tenant execution isolation, and incident history
Governance	RBAC, SSO, and SAML, per-user permission checks on tool calls, approval flows
Observability	Request-level tool-call logs, administrative audit trails, SIEM export
Tool-call overhead	A published latency figure, with the methodology, percentile, and test setup behind it
Tenant fairness	Per-tenant queues or concurrency caps, so one customer's load does not delay another's
Ownership	Whether tool definitions live in your version control, reviewed, and deployed like application code
Open source	Whether the runtime that executes your tools is public and auditable, and whether you could keep running it if the vendor disappeared
Coding agents build integrations	Whether coding agents like Claude Code, Cursor, and Codex can research an API, write the integration as code, and test it against a real connection
Breadth	Catalog size, custom tools as code, Git, and CI workflow
Support	Contractual SLAs, dedicated support, DPAs, and subprocessor lists

For more on the authentication criterion, see the guide to secure AI agent API authentication.

Best enterprise-ready AI agent integration providers

1. Nango

Overview

Nango connects your AI agent to 900+ APIs and 6,000+ pre-built tool calls, with managed auth and credential storage. You can use the catalog out of the box, then customize what you need with code on infrastructure built for scale. Hundreds of AI companies run Nango in production.

Nango also supports data syncs (pulling external data for RAG context) and webhooks on the same platform.

Best for

Teams looking for a large API catalog and customizable pre-built tool calls for AI agents. Also suitable for teams seeking full enterprise readiness with multi-tenant isolation, access control, audit trails, compliance (SOC 2, GDPR, HIPAA), and deployment in their own cloud and region.

Pros

Wide API coverage and tool-call support: Connect agents to 900+ APIs across every auth type (OAuth, JWT, ID-JAG, Basic) with 6,000+ pre-built tool calls, customizable with an AI coding agent through the Nango API integrations builder skill.
Compliance and procurement: SOC 2 Type II, GDPR with a DPA that applies to every cloud account, and HIPAA with a BAA on request, backed by a public subprocessor list and a trust center.
Multi-tenant runtime: Each customer’s executions run isolated and fairly queued on a scalable runtime, with AES-256-GCM credential encryption and tool-call overhead under 100ms.
Permissions and audit trail: RBAC, SAML SSO, and permission-scoped API keys enforce what each user and agent can do, and every tool call, sync, and webhook is logged and exportable over OpenTelemetry.

Data syncs and webhooks: Sync data from external APIs for RAG, or trigger agents on webhooks from external APIs on the same platform.
Mature self-hosted offering (BYOC): Enterprise bring-your-own-cloud runs a fully managed Nango in your own cloud account and region, at feature parity with the managed cloud.
Open source, customizable with code: Build a tool as TypeScript in your own repo and review it like application code, on a runtime that is open source on GitHub so you can audit what executes your tools.

Cons

Free self-hosting is scoped: Functions, syncs, webhooks, MCP, RBAC, SAML, and OpenTelemetry export need Enterprise self-hosting or Nango Cloud. The split is documented.

2. Arcade

Overview

Arcade is an MCP-native tool-calling runtime built around delegated user authorization. Credentials are scoped to each tool, consent is stepped up as new scopes are needed, and the token itself is never exposed to the model or the client.

Best for

Teams that only need MCP tool calling with per-user access control, can bring their own policy layer, and are okay with only a SOC 2 Type II certification.

Pros

Tool metadata for policies: Read-only, destructive, idempotent, and open-world tags let admins govern tools by what they actually do.
Self-hosting for data residency: Enterprise-plan self-hosting (including on-premises and air-gapped) is the documented way to keep data outside the US.
Fits your existing stack: Works with popular agent frameworks and MCP clients like Cursor, Claude, and VS Code.

Cons

Tool calls are not audit logged: Audit logs cover administrative events but not tool executions, which Arcade lists as future work. For a governance platform that is the compliance-critical event.
RBAC only just shipping: Default RBAC began rolling out to new Cloud signups in July 2026 and is not yet generally available to existing organizations.
Thin compliance: SOC 2 Type II is the only certification Arcade publicly claims, with no HIPAA BAA, ISO 27001, or published DPA, and the trust center is access-gated.
US-only cloud: EU data residency requires full self-hosting.
No syncs or webhooks: The catalog is around 80 toolkits and covers tool calls only, so retrieval and event handling need a second platform. The Engine that stores tokens and executes calls is proprietary, so only the tool-authoring framework can be audited.

3. Composio

Overview

Composio has 1,047 toolkits, and each toolkit can contain a large number of tools (over 800 for GitHub, for example). Its tool search lets an agent query the catalog and pull schemas on demand, so a large catalog does not have to be loaded into context up front.

Important:

In May 2026, Composio disclosed a security incident. A compromised employee Gmail OAuth token let an attacker intercept a magic-link sign-in to an internal tool, register malicious tool definitions, and reach the execution sandbox and the credential cache behind it. Around 5,001 GitHub OAuth tokens and 5,241 API keys were compromised or likely exposed.

Best for

Internal and personal automation, where a team connects its own agents to APIs rather than shipping integrations to end customers.

Pros

Self-hosted deployment: Teams that cannot use the managed cloud can run Composio on their own infrastructure.
Detailed execution logs: Rich filtering and full request/response payloads through the API.
Broad framework support: MIT-licensed Python and TypeScript SDKs with adapters for popular agent frameworks.

Cons

Fallout from the May 2026 incident: Composio mandated API key rotation for every customer, not only those affected, and the cleanup broke integrations. Its own status page records roughly 32 hours of broken CLI authentication across three days, and API-key connections it could not revoke on customers’ behalf were left for each end user to rotate at the provider.
Closed-source runtime: The public repository holds SDKs and adapters only, so customers cannot audit what executes their tools.
Governance and audit behind the enterprise tier: Composio documents five roles with action-level RBAC and audit trails for every tool call, but as enterprise-tier features rather than defaults on the lower paid plans.
No HIPAA or BAA: Composio is certified for SOC 2 Type II and ISO 27001:2022, but its trust center lists no HIPAA compliance and it offers no Business Associate Agreement, so regulated health data is off the table.

For a direct comparison, see Composio vs Nango and Composio alternatives.

4. Pipedream Connect

Overview

Pipedream Connect offers the broadest app coverage in this comparison, 3,000+ apps and 10,000+ tools, each behind managed authentication so an agent can call it without handling credentials.

Important:

Pipedream Connect appears to be no longer actively maintained. Pipedream’s changelog lists no release since October 2025, and its self-hostable MCP reference implementation, last updated in November 2025, is documented as no longer maintained. Workday’s acquisition of Pipedream was announced in November 2025.

Best for

Teams that want a large, open-source component catalog and a signed HIPAA BAA, and can accept that Connect is no longer actively developed.

Pros

Auditable open-source components: Every Pipedream Connect component is defined as Node.js source in a public repository, so you can read exactly what a tool does before you ship it.
HIPAA with a BAA: Pipedream signs Business Associate Addendums with Business-tier customers, and Connect is on its documented list of services eligible to handle PHI.

Cons

No burst protection for tool calls: Pipedream’s tool calls run through the SDK, which its event queues do not cover, so a burst of calls hits cold-start delays instead of being queued.
End-user isolation delegated to your app: Pipedream separates end users by an ID your app passes in, so isolation between them is only as strong as your own authentication.

5. Workato Embedded

Overview

Workato is an enterprise automation platform built around a no-code visual builder and 1,200+ prebuilt connectors. Its Enterprise MCP offering exposes the recipes built there to agents as tools, with no integration code required.

Best for

Non-technical teams that want to expose recipes to agents through a visual builder, and value broad compliance coverage over a code-first workflow.

Pros

Broad compliance coverage: SOC 1 and SOC 2 Type II, ISO 27001, ISO 42001 for AI management systems, and HIPAA with signed BAAs.
Per-user identity with approvals: With Verified User Access, each action runs as the actual end user and inherits their own permissions, not those of a shared service account. Agent Guardrails can then route high-stakes actions to Slack or Teams for sign-off first.

Cons

No code-first tool definition: Agent tools are recipes built in Workato’s visual builder, not authored in code, so the integration logic never enters your repository or code review.
Cloud-only, with capacity you negotiate: The MCP server runs only in Workato’s cloud; the on-prem agent is a connectivity tunnel back to it, not a way to self-host. Recipe concurrency is capped at 30 jobs unless you ask support to raise it.

6. Paragon

Overview

Paragon is an embedded integration platform. Its ActionKit product exposes integration actions to agents as tools. Its Managed Sync product keeps synced files aligned with each source’s access rules, so a retrieval pipeline can respect third-party permissions without reimplementing each provider’s model. Workflows are written in Paragraph, a TypeScript framework that can sync bidirectionally with your GitHub repository.

Best for

Teams building RAG over file-storage sources like Google Drive and SharePoint. Paragon’s Permissions API keeps each source’s own access rules in place. It fits if you can accept that its SOC 2 report date and BAA terms aren’t stated publicly.

Pros

Documented self-hosting: Paragon publishes a full self-host guide, covering the architecture, system requirements, Terraform and EKS assets, and expected infrastructure costs, plus a code-first workflow through Paragraph and Git Sync.
Permissions travel with the data: The Permissions API records each file’s source access rules as it syncs, across Box, Confluence, Dropbox, Google Drive, OneDrive, and SharePoint. A RAG pipeline can then show each user only what they are allowed to see, instead of reimplementing every provider’s permission model.

Cons

HIPAA compliance without a BAA: Paragon claims SOC 2 Type II, GDPR, and HIPAA, but it does not offer a Business Associate Agreement, the contract you need before sending health data through it. Its SOC 2 report is only available on request.
No per-action authorization: JWT Permissions gate access at the integration and API-class level, all ActionKit requests on or off, for instance, with no rule for a single action. Action-level control falls to the underlying provider.

Comparison of solutions

Criterion	Nango	Arcade	Composio	Pipedream Connect	Workato	Paragon
Compliance	SOC 2, GDPR, HIPAA	SOC 2 only	SOC 2, ISO 27001	SOC 2, HIPAA	SOC 2, ISO, HIPAA	SOC 2, GDPR, HIPAA
Deployment	Cloud + BYOC + free self-host	Cloud + Paid self-host	Cloud + Paid self-host	Cloud only	Cloud only	Cloud + paid self-host
Security architecture	Isolated per customer	Undocumented	Closed runtime	Delegated	Isolation is paid	Per-user isolation
Governance	Comprehensive	Partial	Partial	Basic	Comprehensive	Partial
Observability	Comprehensive	None	Partial	Basic	Comprehensive	Basic
Tool-call overhead	Under 100ms	Not published	Not published	Not published	Not published	Not published
Tenant fairness	Yes	No	Partial	No	Partial	Partial
Ownership	Yes	Partial	No	Partial	No	Partial
Open source	Yes	Partial	Partial	Partial	No	Partial
Coding agents build integrations	Yes	Limited	No	No	No	No
Breadth	900+ APIs, 6,000+ tools	80+ toolkits	1,047 toolkits	3,000+ apps, 10,000+ tools	1,200+ connectors	79 integrations
Support	Yes	Partial	Partial	Partial	Yes	Partial

How we applied the criteria

We checked each entry against the vendor’s own documentation, terms of service, pricing pages, changelogs, and public repositories, treating documentation as authoritative where it disagreed with marketing. No vendor publishes a tool-call latency figure with a methodology behind it, so that row records each vendor’s own claim rather than a measured comparison.

FAQ: Enterprise-ready agent integrations

What is the best enterprise AI agent integration platform?

Nango is best for enterprise agent integrations. It is SOC 2 Type II, GDPR, and HIPAA compliant with a BAA, open source, so the runtime executing your tools can be audited, and self-hostable at feature parity with the managed cloud. On top of that, coding agents like Claude Code, Cursor, and Codex build API integrations as code in your own repository. Nango covers tool calls, data syncs, and webhooks across 900+ APIs. The comparison table covers how the others differ.

How do AI agents authenticate with external APIs securely?

Through a platform like Nango that holds the credentials. The platform completes the OAuth flow, stores the token encrypted, and injects it at call time, so the model sees tool inputs and outputs but never the token.

Which AI agent integration platforms are SOC 2 or HIPAA compliant?

All six claim SOC 2, though the scope varies. Nango, Workato, and Pipedream go further and sign a BAA for HIPAA. Nango publishes SOC 2 Type II, GDPR, and HIPAA evidence in its trust center, with a DPA that applies automatically to every cloud account.

Can I self-host an AI agent integration platform?

Every platform compared here offers some form of self-hosting except Workato, which is cloud-only. Nango offers free self-hosting, plus Enterprise bring-your-own-cloud that deploys a fully managed Nango into your own AWS, GCP, or Azure account and region, at feature parity with the managed cloud and with no maintenance or scaling on your side.

How do I control which users or agents can call which tools?

The main control is identity at runtime. Each end user should act through their own stored credentials, not a shared service account, so a tool call only reaches what that user connected. Team access is separate: RBAC sets what your members can do, and SSO handles their login. Nango covers both, and scopes API keys to specific permissions on top.

Can I audit what an AI agent did?

Only if the platform logs tool executions, not just administrative events. Look for a request-level record of every tool call, which user ran it, which tool, and what result, that you can export to your own SIEM over a standard like OpenTelemetry. Some platforms log admin actions but not the tool calls themselves, the compliance-critical event. Nango logs every tool call, sync, and webhook and exports over OpenTelemetry.

Conclusion

Enterprises adopting agent integrations need broad API coverage on a runtime they can put through a security review and deploy in their own region. Of the six platforms here, Nango is the strongest fit.

It connects agents to 900+ APIs with 6,000+ pre-built tool calls, customizable with code, and carries SOC 2 Type II, GDPR, and HIPAA with a BAA. It deploys in your own cloud via BYOC, with an open source runtime you can audit.

To get started, follow the Nango quickstart.

Best token vaults and credential management tools for AI agents in 2026

Sapnesh Naik — Fri, 31 Jul 2026 01:26:05 +0000

AI agents connect to APIs such as Salesforce, Slack, MS Teams, Drive, and Calendar to work on behalf of users or operate autonomously. These integrations use the same APIs that SaaS products traditionally use for embedded integrations.

The security model is different when connecting these APIs to AI agents. You need to grant agents API access without exposing credentials. You also need to handle authentication tasks such as token refresh and different auth types, including OAuth 2.0, OAuth 2.1, Basic auth, and API keys.

This post compares four secure credential management tools for AI agents to help you choose the right one for your use case.

TL;DR

A token vault is a credential store that sits between an AI agent and external APIs, much like a password manager for user accounts. Token vaults are necessary because most agents run without a browser for interactive logins and lack secure credential storage.

Top four agent credential management tools in 2026:

Nango: An open-source credential layer for AI agents that spans 900+ APIs and 6,000+ pre-built tool calls. It supports all auth types, multi-tenant credential scoping, and direct token access through the API or SDK. It can be self-hosted or run in your own cloud and region through BYOC.
Auth0: An OAuth-only token store from an identity provider, with 30+ pre-built providers. It’s closed-source and cloud-only. Your application receives a short-lived provider token and makes the API calls itself.
Arcade: An MCP-native tool-calling runtime for agents where each user connects their own accounts. Tool executions are not included in the audit log, and the platform is not open source.
Composio: A hosted platform for agent tool calls. The credential store is closed source, and a security incident in May 2026 exposed customer connections and API keys.

What is a token vault for AI agents?

AI agent authentication must support credential types designed for user interaction. OAuth, for example, is used by most APIs and assumes that a person is present to grant consent. API keys pose another issue: no one rotates them unless you automate it. It can also be difficult to determine whether the agent is acting on a user’s task or on its own.

A token vault moves credential storage and management into a separate service. It stores each token, refreshes and revokes it, and injects it only when a call is made. The agent never holds a raw secret, and every use of a credential is recorded in a single audit trail.

This keeps the agent’s workflow simple: the agent calls a tool without handling the raw credentials. The agent does not see the provider’s refresh token. The user connects and authorizes once, and the vault manages the rest.

An agent API tool-call execution model looks like this:

The responsibilities of a token vault cover the full lifecycle of a credential:

Store credentials encrypted at rest
Refresh, rotate, and revoke tokens throughout their lifecycle
Authenticate the agent and inject the right token into each request
Scope each credential to an identity and its permissions
Log every credential use for audit

How to choose a token vault for AI agents

For a customer-facing product, we compare token vaults on the criteria below. They cover the questions that security, platform, compliance, and product teams raise during an evaluation.

The bare minimum

These are the baseline capabilities a production token vault should meet.

Criterion	Why it matters	What to verify
Automatic OAuth refresh	Access tokens expire, so the vault has to refresh them for every connection or calls fail mid-task	Whether OAuth tokens are refreshed automatically, with no human in the loop
Rotation and revocation	A leaked or offboarded credential has to be rotated or revoked in one place, not chased across services	Whether tokens and keys can be rotated and revoked centrally, per connection
Encryption and isolation	Stored credentials must be encrypted at rest, and one tenant's tokens must never reach another	Encryption at rest and tenant isolation, expected of every vault as a baseline
Credential never leaves the vault	A credential your own runtime holds can be stolen from it, and a prompt injection can only leak what the agent can reach	Whether the vault runs the call with the credential or hands the credential to your application to use
Standards support	Open standards keep you portable and interoperable instead of tied to one vendor's scheme	OAuth 2.0/2.1, OIDC, and agent standards such as MCP Auth

Differentiating criteria

Criterion	Why it matters	What to verify
Deployment	Where your customers' tokens physically live sets data residency and the trust boundary	Managed cloud, deployment in your own cloud account, self-hosting, and how mature the self-host path is
Ownership and portability	Locked-in credentials mean you cannot switch vendors without every user re-authorizing	White-label authorization under your brand and API export of stored credentials
Open source	You can audit the code that holds credentials and keep running it no matter what happens to the vendor	Whether the runtime that stores and refreshes credentials is public and auditable
Credential types	An OAuth-only vault leaves every API-key or custom-auth integration for you to build	OAuth, API keys, basic auth, and custom schemes, not OAuth alone
Identity scoping	Each call must run under the right identity with only the access that identity was granted	Which identities a credential can be scoped to (user, org, workspace, or bot), and whether role-based controls apply per token or API
Authentication methods	The agent-to-vault connection is itself an attack surface, and a static key is the weakest option	Machine-first methods such as OpenID Connect, signed JWTs, or mTLS, beyond a static API key
Audit of credential use	After an incident, you need to see which agent used which credential and export the record for compliance	Request-level logs of credential use and external API calls, exportable to SIEM
Connection health notifications	A provider token can expire or be revoked at any time, and an unnoticed broken connection breaks the product for that customer	Webhooks or events for connection creation, refresh failure, and expiry, so your product can prompt the user to re-authorize
Service breadth	A thin catalog means building and maintaining OAuth flows the vault does not cover	The number of distinct services with a pre-built OAuth flow out of the box
Compliance	Regulated customers rule out vendors that lack the certifications their own audits require	SOC 2 Type II, HIPAA, and GDPR where needed

For more details, see our guide to secure AI agent API authentication.

Best token vaults and credential management tools for AI agents

1. Nango

Overview

Nango enables AI agents to connect to 900+ APIs and 6,000+ pre-built tool calls, with managed authentication and credential storage. Nango’s built-in token vault stores each credential, automatically refreshes it, and injects it when a call is made, thereby isolating it from the model. Webhooks notify your product when a connection needs reauthorization, and your backend can access stored tokens through the API or SDK when needed.

Hundreds of AI companies run Nango in production.

Best for

Teams securing authentication for AI agent integrations across many credential types, with a comprehensive and extensible API catalog and pre-built tools for agents. It also fits teams that need compliance, full audit logs, white-label authorization, or deployment in their own cloud and region.

Pros

Broad credential support: OAuth 2.0 and 1.0a, API keys, basic auth, custom auth, and MCP Auth.
Full credential lifecycle: Automatic refresh, central rotation and revocation, encryption at rest, standards support (OAuth 2.0 and MCP Auth), and server-side injection.
White-label, no lock-in: Users authorize under your brand, and you have full access to the tokens when needed.
Identity scoping and audit trail: Scope each credential to a user, org, workspace, or bot with RBAC, and log every credential use at request level, exportable over OpenTelemetry.
Wide API coverage and tool calls: 900+ APIs and 6,000+ pre-built tool calls, and the Nango builder skill lets Claude Code, Cursor, or Codex build and test whatever the catalog does not cover.
BYOC or self-host: Run Nango in your own cloud and region to control the data residency of your credentials. Enterprise self-hosting runs at feature parity with the managed cloud.
Open source: Nango is open source on GitHub, so you can extend, audit, or self-host it.
Compliant: SOC 2 Type II, HIPAA with a BAA, and GDPR, with evidence in the trust center.

Cons

More than a token vault: Beyond API authentication and credential management, Nango lets agents make authenticated API calls across 900+ APIs through its proxy, run data syncs for RAG, and run tool calls. If you only want a credential store, a dedicated vault is simpler.

2. Auth0

Overview

Auth0 is primarily an identity platform that manages how users log in and prove who they are. Auth0 for AI Agents provides an authorization layer for securely managing third-party tokens.

Best for

Teams whose main need is identity, want an OAuth-only token store alongside it, and will build and run the API calls themselves.

Pros

Machine authentication: Client secret, private key JWT, and mTLS for the agent-to-vault connection.
White-label authorization: Users authorize on your custom domain and brand.
Compliant: SOC 2 Type II, HIPAA with a BAA, GDPR, and ISO 27001.

Cons

Token returned to your app: The refresh token stays in the vault, but the exchange hands the provider’s access token to your application, so keeping it out of the model’s reach is left to you.
Few pre-built connections: 30+ pre-built connections, by Auth0’s own count.
OAuth only: OAuth 2.0 tokens only. No API keys, basic auth, or custom schemes.
Closed source and cloud only: Multi-tenant or dedicated single-tenant cloud, both operated by Auth0. No self-hosting, no deployment in your own cloud account, and no way to audit the code that stores your tokens.
No token export: There is no API for exporting stored tokens, so leaving means every user has to reauthorize every API.

3. Arcade

Overview

Arcade is an MCP-native tool-calling runtime for AI agents, built around per-user authorization. When an agent calls a tool, Arcade runs it as the user who connected the account and injects that user’s credentials at execution. Both the credential store and the runtime that executes the call run on Arcade’s managed platform.

Best for

Teams building chat-style agents that call tools as a specific user, where per-user OAuth is the main challenge and they do not need data syncs, provider webhooks, or an audit trail of tool calls.

Pros

Every baseline met: Automatic refresh, rotation and revocation, encryption at rest, standards support (OAuth 2.0 and MCP), and server-side injection.
Self-hostable: Available on the Enterprise plan.
Multiple credential types: OAuth 2.0 tokens, API keys, and secrets.

Cons

Arcade-branded auth: Users see Arcade on the auth screen.

Proprietary credential engine: The credential engine is closed source.
No credential-use audit log: The audit log covers administrative actions only, not tool executions.
Thin compliance evidence: Only SOC 2 Type II is documented.

For a fuller comparison, see Arcade.dev vs Nango.

4. Composio

Overview

Composio is a hosted platform that lets AI agents call third-party tools on behalf of a user. Each user connects their own accounts, and Composio stores those tokens, refreshes them, and injects the right token when a tool runs. Agents reach the tools through its SDKs or MCP, on a managed, closed runtime.

Important:

In May 2026, Composio disclosed a security incident. An attacker compromised the Gmail OAuth tokens of Composio employees and used them to access internal systems. Around 5,001 user connections and 5,241 API keys were compromised or likely exposed. Composio revoked user access tokens and required every customer to rotate their API keys.

Best for

Teams integrating internal company automations or personal AI agents such as Hermes, Claude, and Codex with APIs. It can also fit customer-facing products where a closed credential runtime and the May 2026 breach can pass a security review.

Pros

Credential management: Automatic refresh, rotation, revocation, and encryption at rest.
Multiple auth types: OAuth 2.0 and 1.0, API keys, and Basic auth.

Cons

Composio-branded auth: Users see Composio on the consent screen.

Closed-source backend: The credentials layer is closed source.
No standardized log export: There is no SIEM or OpenTelemetry export.

For a direct comparison, see Composio vs Nango.

Comparison of solutions

Differentiating criteria compared

Criterion	Nango	Auth0	Arcade	Composio
Deployment	Cloud, BYOC, self-host (free + Enterprise)	Cloud	Cloud, self-host (Enterprise)	Cloud, self-host (Enterprise)
Ownership and portability	White-label, token access	White-label, no export	White-label through your own OAuth app, no export	White-label through your own OAuth app, export
Open source	Full platform (ELv2)	None	Tool SDK only	SDKs and CLI only
Credential types	OAuth 2.0/1.0a, API key, Basic, custom, MCP Auth	OAuth 2.0	OAuth 2.0, API key, secrets	OAuth 2.0/1.0, API key, Basic
Identity scoping	Per-user, org, workspace, bot	Per-user, org isolation	Per-user, bot through secrets	Per-user, shared through ACL
Authentication methods	Static API key	Client secret, private key JWT, mTLS	Static API key	Static API key
Audit of credential use	Request-level logs, OTel export	Tenant logs, SIEM export	Admin actions only, no export	Tool-call logs, no standard export
Connection health notifications	Webhooks for creation, re-auth, refresh failure	None, errors at token exchange	None documented	Webhook on connection expiry
Service breadth	900+ APIs	30+ APIs	80+ APIs	1,000+ APIs
Compliance	SOC 2 II, HIPAA, GDPR	SOC 2 II, HIPAA, GDPR, ISO 27001	SOC 2 II	SOC 2 II, ISO 27001

Baseline criteria compared

Criterion	Nango	Auth0	Arcade	Composio
Automatic OAuth refresh	Yes	Yes	Yes	Yes
Rotation and revocation	Yes	Yes	Yes	Yes
Encryption and isolation	Yes	Yes	Yes	Yes
Credential never leaves the vault	Yes, injected server-side	No, short-lived token to your app	Yes, injected server-side	Yes, injected server-side
Standards support	OAuth 2.0/1.0a, MCP	OAuth 2.0/2.1, OIDC, MCP	OAuth 2.0, MCP	OAuth 2.0/1.0, MCP

How we applied the criteria

We tried every product hands-on and verified claims against each vendor’s documentation, security pages, changelogs, and public repositories. We treated documentation as authoritative where it disagreed with marketing.

FAQ: token vaults for AI agents

What is the best token vault for AI agents?

Nango. It handles every credential type across 900+ APIs, not OAuth alone, on a runtime that is open source and self-hostable. It is SOC 2 Type II, HIPAA, and GDPR compliant, and you have full access to your users’ tokens when needed.

How do AI agents store OAuth tokens securely?

An OAuth token vault holds the token instead of the agent. It runs the OAuth flow, stores the token encrypted at rest, refreshes it, and injects it when a call is made, so the model never sees it. See API auth is deeper than it looks.

How is a token vault different from a secrets manager?

Secrets management for AI agents needs more than a static store. A secrets manager, such as HashiCorp Vault or AWS Secrets Manager, stores a string and returns it on request. A token vault also runs the OAuth flow, refreshes tokens, tracks which token belongs to which user, and logs credential use. A plain secret store leaves all of that for you to build.

What credential types do AI agents need beyond OAuth?

Many APIs do not use OAuth. Services such as Stripe, SendGrid, and most analytics tools use API keys. Others use Basic auth (a username and password pair) or custom auth (a scheme with no standard grant, such as a session token from a login endpoint, a signed request, or a JWT assertion). Each custom scheme needs its own refresh logic, which the vault has to own. An OAuth-only vault, such as Auth0, leaves these methods to your application. Nango covers OAuth, API keys, Basic auth, custom auth, and MCP Auth.

Can a prompt injection make an agent leak its credentials?

When a token vault is used, the model sees only tool inputs and outputs, not the token, which is injected server-side. A hidden injection, such as instructions buried in a parsed PDF, cannot leak a secret the model does not hold. See API auth is deeper than it looks.

Conclusion

Choosing a token vault affects data residency, portability, the APIs you can support, and how you audit access. For agents that work with APIs, look beyond credential management and evaluate the complete integrations layer. Open-source, self-hostable, code-based tools give you more flexibility as the space evolves.

Best tools to integrate external APIs with AI coding agents in 2026

Sapnesh Naik — Thu, 23 Jul 2026 02:40:38 +0000

TL;DR

Coding agents like Claude Code, Cursor, and Codex write integration code well but ship broken API integrations on their own: they work from stale training data, invent endpoints, and have no way to run OAuth or test against the real API. You can fix that by configuring a set of supporting tools: docs-context MCP servers, agent skills, auth and testing utilities, and an integration platform that gives the agent real connections to build against.

We build API integrations with coding agents every day at Nango, and this list is the toolbox that makes that work. The focus is customer-facing API integrations, where your users connect their own Salesforce, HubSpot, or Slack accounts to your product, not editor productivity plugins. Every entry is something you configure for the agent, and they work together in one workflow.

Tool	What it gives the agent	Best for	Pricing and license
Nango	Managed auth, real-API testing, and a runtime across 900+ APIs, via skills for all coding agents	Building production integrations end to end	Free tier, paid from $50/mo; source-available (ELv2)
Context7	Up-to-date library and SDK docs in the prompt	Stopping stale-docs hallucinations	Free 1,000 calls/mo, Pro $10/seat/mo; MIT server, closed backend
Official provider MCP servers (GitHub, Atlassian, AWS)	Build-time operations on the provider: repos, issues, docs, infra	Working with providers you already use	Free; MIT / Apache 2.0
Agent skills and the skills CLI	Procedural knowledge: how to build an integration, step by step	Encoding repeatable workflows across agents	Free; open standard (agentskills.io)
Apidog MCP server	Your OpenAPI spec served as agent context	Generating code against a known API contract	Free; open source
Speakeasy Gram	Turns an OpenAPI spec into hosted MCP tools	API producers exposing their own API to agents	Free tier (1,000 tool calls); open source
RedirectMeTo, ngrok, mkcert	Working OAuth redirects on localhost	Testing OAuth flows during development	Free tiers; MIT / BSD

What it takes for a coding agent to ship an API integration

Prompting an agent to “build a HubSpot integration” fails without scaffolding, and the failure points are predictable. A production API integration needs four things that the agent does not have out of the box:

Current API knowledge: Models work from training data that lags the real API. In a 2025 benchmark of LLMs on web API integration tasks, models hallucinated endpoint URLs up to 39% of the time and parameter names up to 31% of the time. Docs-context tools close this gap.
Auth and credentials: The agent cannot click through an OAuth consent screen, register an OAuth app, or store and refresh tokens. Someone has to hand it an authorized connection, and OAuth is full of provider-specific quirks.
A test loop against the real API: Code that compiles is not an integration that works. The agent needs to execute its code against a real connection, read the actual response or error, and iterate.
A runtime and maintenance path: Token refresh, webhooks, retries, pagination, rate limits, and observability have to live somewhere after the agent is done writing code.

The seven tools below cover those four jobs. Most are complementary: a real setup uses three or four of them together, and the usage example at the end shows the full workflow.

1. Nango

Nango is the integration platform where coding agents build API integrations. Your agent writes integrations as code functions, tests them against real connections, and deploys them to a managed runtime that handles auth, syncs, webhooks, and tool calls across 900+ APIs with 5,000+ reusable templates.

Pricing: free tier (10 connections included), paid from $50/month
License: source-available (Elastic License 2.0), self-hostable
Works with: All coding agents, including Claude Code, Cursor, Codex, Gemini CLI, and OpenCode
Install: npx skills add NangoHQ/skills -s building-nango-functions-locally for repo-based builds; a remote Function Builder skill builds with no local project. The coding agent setup guide explains which fits your use case.

Best for

Teams whose coding agent should ship the whole integration: research the API, write the code, test it against a real connection, and deploy it to a runtime their product consumes through an MCP server or REST.

Pros

One skill covers the full build loop: The Nango skill gives the agent the integration patterns (auth, actions, syncs, webhooks) plus a test command. nango dryrun executes generated code against a real connection, so the agent iterates on real API responses instead of guessing.

Managed auth the agent cannot build: A drop-in UI handles OAuth, API keys, JWT, basic auth, and MCP Auth across 900+ APIs. Your users authorize under your brand, and the agent only ever sees a connection ID.
Docs built for agents: A public docs MCP server, llms.txt, and an agent-readable API catalog, so the agent grounds itself without scraping.
Integrations built from a prompt alone: The remote function builder (shipped June 1, 2026) compiles, dry-runs, and deploys over REST with no local project. This is what enables just-in-time integrations, where an agent inside your product builds an integration that a customer asked for.
The runtime is included: The deployed integration runs on a tenant-isolated runtime with data syncs, webhook ingestion, full request and response logs, and OpenTelemetry export. Your product’s agents consume it through a hosted MCP server with schema-validated tools, or REST.

Cons

Needs a Nango account: The free tier is enough to build and test, but the workflow assumes the Nango platform end to end.
Built for developers: Integrations are code in a repo. Teams that want a drag-and-drop builder are better served by a visual embedded iPaaS.

2. Context7

Context7, by Upstash, is the most widely used docs-context MCP server. It resolves a library name to an indexed ID, then injects current, version-specific documentation and code examples into the agent’s prompt. It is mainly used to stop the agent from hallucinating deprecated or nonexistent library APIs.

Pricing: free (1,000 calls/month), Pro $10/seat/month for 5,000 calls
License: MIT (MCP server); the crawling backend is closed source
Works with: Claude Code, Cursor, Codex, and most MCP clients, as an MCP server or a skill
Install: npx ctx7 setup, or the remote server at mcp.context7.com/mcp with an API key

Best for

Any agent writing code against SDKs and libraries that change faster than model training data: Next.js, Stripe, Supabase, provider SDKs, and similar.

Pros

Solves the stale-docs problem for LLMs: Version-specific docs arrive in the prompt at generation time. Community endorsement is unusually strong; a typical Hacker News assessment called it “so good it seems like magic.”
Low setup cost: One command installs it across your agents, and it stays out of the way until the agent queries a library.

Cons

Indexing lags bleeding-edge releases: Users report the indexed docs trail brand-new versions by days, which is exactly when you need them most.
The free tier shrank: In January 2026, the free allowance dropped to 1,000 calls per month (from roughly 6,000), so using it across a team effectively requires the paid tier.
A hosted dependency with a security history: Every query routes through Upstash. In March 2026, researchers disclosed ContextCrush, a prompt-injection vulnerability where unsanitized library “Custom Rules” reached every querying agent. Upstash patched it within days, but docs-context servers are part of your supply chain.

If Context7 does not fit, Ref.tools optimizes for token-efficient docs search, and DeepWiki MCP (by Cognition) answers questions over 50,000+ pre-indexed public GitHub repos for free.

3. Official provider MCP servers (GitHub, Atlassian, AWS)

When the provider you are integrating with ships an official MCP server, your agent can operate that provider directly while it builds: read API docs, inspect repos, file issues, provision infrastructure. Three matter most in 2026:

GitHub MCP server: MIT-licensed, remote server GA since September 4, 2025 with OAuth 2.1, plus a local Docker option. 50+ tools across 23 toolsets covering repos, issues, pull requests, and actions.
Atlassian Rovo MCP server: GA since February 4, 2026, hosted at mcp.atlassian.com. Exposes Jira, Confluence, and Bitbucket Cloud with tool groups that respect existing user permissions.
AWS MCP servers: The awslabs suite has 40+ Apache 2.0 servers (documentation, CDK, cost analysis), and the managed AWS MCP Server (GA May 6, 2026) exposes 15,000+ AWS API operations through a small fixed toolset, free.

Best for

Build-time operations on providers your team already uses: the agent researches the API, checks examples, manages the repo and tickets, and provisions the infrastructure the integration will run on.

Pros

Maintained by the provider: Official servers track API changes, and auth is first-party OAuth rather than a scraped token in a config file.
Tool-context discipline is improving: GitHub cut its default toolset from 101 tools to 52 in October 2025, and a January 28, 2026 update added OAuth scope filtering plus dynamic toolsets that start with 4 tools.

Cons

Context cost is still real: One user measured Claude Code’s context jumping from 34,000 to 80,000 tokens just from enabling the GitHub MCP server. Enable the minimal toolsets you need.
They authenticate you, not your customers: These servers run on the developer’s own OAuth token or PAT. They are build-time tools. None of them handles multi-tenant end-user auth, token refresh, or per-customer API calls in your shipped product.

If your product needs official MCP servers at runtime, Nango covers that side too: its catalog includes MCP-type integrations like HubSpot MCP, MCP Auth manages your users’ connections to them, and a generic MCP integration connects any spec-compliant server, all through the same auth and runtime as regular API integrations.

4. Agent skills and the skills CLI

A skill is a folder with a SKILL.md file that teaches an agent a workflow: instructions, scripts, and references it loads when relevant. Anthropic introduced Agent Skills on October 16, 2025 and published the format as an open standard on December 18, 2025 at agentskills.io. OpenAI added skills to Codex in December 2025, and the standard’s client list spans 40+ products, including Cursor and Gemini CLI.

Pricing: free
License: open standard; individual skills carry their own licenses
Works with: 40+ agents and clients via one SKILL.md format
Install: npx skills add <owner/repo> (the skills CLI by Vercel, announced January 20, 2026)

Best for

Encoding the procedure of integration work once, so every agent on the team follows it: which auth pattern to use, how to paginate, how to test.

Pros

One artifact, every agent: The same skill works in Claude Code, Codex, and Cursor, so the workflow does not depend on which agent a teammate runs.
Cheap on context: Skills load progressively; Codex budgets around 2% of the context window for the skills list. Hence the community rule of thumb: skills for defined workflows, MCP for live data.
Good API-integration skills exist: Anthropic’s mcp-builder scaffolds an MCP server that wraps an API in TypeScript or Python. Nango’s skills (covered above) go further and produce a deployed, tested integration.

Cons

Quality varies wildly: The skills.sh registry tracks installs, not correctness, and anyone can publish.
A skill alone still guesses: Instructions without a real-API test loop do not fix the hallucinated-endpoint problem. With mcp-builder, for example, you still host, auth, and maintain the resulting server yourself.

5. Apidog MCP server

The Apidog MCP server feeds an API specification to your coding agent: an Apidog project, a published docs site, or any plain OpenAPI/Swagger file. The agent then generates requests and types against the actual contract instead of its memory of it.

Pricing: free (the Apidog platform has a free plan for up to 4 users)
License: open source (MIT)
Works with: Cursor, Claude Code, VS Code, and other MCP clients
Install: npx apidog-mcp-server@latest with a spec path or project token

Best for

Teams that have (or can obtain) an OpenAPI spec for the API they are integrating: internal services, partner APIs, or well-documented public providers.

Pros

Grounds generation in the real contract: Field names, required parameters, and response shapes come from the spec, which removes the most common class of integration bugs.
Works with bare OpenAPI files: You do not need to adopt the Apidog platform; pointing it at a local or remote spec file is enough.

Cons

Only as good as the spec: Long-tail SaaS APIs often publish incomplete or outdated OpenAPI files, and many publish none.
No execution layer: The agent knows the contract but still cannot authenticate or verify behavior against the live API.

6. Speakeasy Gram

Gram, by Speakeasy, turns an OpenAPI document into a hosted MCP server with curated toolsets. It sits on the producer side of the ecosystem: if you want your own API to be callable by ChatGPT, Claude, and coding agents, Gram is the fastest path.

Pricing: free tier with 1,000 tool calls, then usage-based
License: open source, with a hosted service
Works with: any MCP client
Install: upload an OpenAPI spec, curate the toolset, get a hosted MCP URL

Best for

API producers who want a maintained, hosted MCP server for their own API without building one by hand.

Pros

Spec in, hosted MCP server out: Upload an OpenAPI document and Gram hosts the resulting server, so you skip building and operating one yourself.
Curation is first-class: Toolset curation and enriched descriptions are part of the workflow. Speakeasy’s own guidance notes that naive one-tool-per-endpoint conversion underperforms small, curated toolsets.

Cons

The consumer side stays unsolved: Generating an MCP server for an API you consume still leaves auth, multi-tenant credentials, and maintenance with you. For consuming many external APIs, an integration platform is the broader tool.

7. RedirectMeTo, ngrok, and mkcert (OAuth on localhost)

Many providers reject http://localhost OAuth redirect URLs (Slack, TikTok, and Microsoft OneDrive among them), which blocks the agent’s test loop before it starts. Three utilities fix it, and we cover them in depth in 3 easy ways to do OAuth redirects on localhost.

Pricing: RedirectMeTo is free; ngrok has a free tier, then $8/month (Hobbyist, billed annually); mkcert is free
License: MIT (RedirectMeTo), proprietary (ngrok), BSD-3-Clause (mkcert)
Works with: any OAuth provider and any local stack

Best for

Developing and testing OAuth flows locally, so the agent (and you) can complete a real authorization against a real provider during development.

Pros

RedirectMeTo is zero-setup: Prepend https://redirectmeto.com/ to your localhost callback URL and register that as the redirect URL. It forwards the redirect with query parameters intact.
ngrok gives you a stable HTTPS tunnel: Every free account includes one static dev domain, which doubles as a webhook receiver while you test event-driven integrations.
mkcert makes **`https://localhost**`{% endraw %}** real:** It installs a local CA and mints trusted certificates, no cloud dependency involved.

Cons

Trust and limits: A redirect service can see your authorization code in transit, ngrok’s free tier has an interstitial page and tight quotas, and mkcert’s last release was April 2022 (it still works, but it is in maintenance mode).
This solves redirects only: Token storage, refresh, and multi-tenant auth remain yours. With a managed auth layer you skip the problem, since the redirect URL is the platform’s hosted HTTPS endpoint.

Usage example: building a HubSpot sync with Claude Code and Nango

Here is how the toolbox works together on a real task: syncing HubSpot contacts into your product.

Set up auth once: Create a HubSpot integration in the Nango dashboard and add a test connection by completing the OAuth flow. No localhost redirect workarounds needed, because the redirect URL is Nango’s hosted endpoint.

Give the agent its tools: Install the Nango skill ({% raw %}npx skills add NangoHQ/skills -s building-nango-functions-locally). The skill points the agent at Nango’s docs MCP server, and Context7 covers any SDK questions along the way.
Prompt at the level of intent:

/building-nango-functions-locally Build a Nango sync that fetches all HubSpot
contacts. Backfill the full contact list on first run, then fetch only new and
updated contacts incrementally. Return id, email, first name, last name, and
last modified date.

The agent builds and tests against the real API: It researches the HubSpot API, writes the sync with pagination and checkpoints, runs nango dryrun against your test connection, reads real responses, and iterates until the sync passes.
Deploy and consume: nango deploy dev ships the sync to the runtime. Your product reads synced records over REST, your users connect their own HubSpot accounts through the white-label auth UI, and the agent reads execution logs when something needs a fix.

Docs tools ground the agent, the skill encodes the procedure, and the platform supplies credentials, a test loop, and a runtime. For a deeper walkthrough, see how to sync large amounts of contacts from the HubSpot API.

Keep the toolbox small

Every MCP server you add loads its tool definitions into every conversation. Anthropic measured a typical five-server setup at around 55,000 tokens of tool definitions before the conversation starts, and Claude Code added MCP tool search in January 2026 to load definitions on demand instead.

Two rules of thumb from teams running this in production:

Install only what the task needs: Three or four tools from this list cover an integration project. Add a docs-context server, the provider’s official MCP server if one exists, one integration skill, and the platform. Skip the rest until a task demands them.
Treat MCP servers as dependencies: In September 2025, the postmark-mcp npm package shipped an update that BCC’d every email to an attacker. Prefer official servers, pin versions, and keep production credentials out of the agent’s environment.

FAQ

Can Claude Code build API integrations?

Yes. Claude Code can build production API integrations when paired with a skill that encodes integration patterns and a way to test against the real API. Without those, models hallucinate endpoint URLs up to 39% of the time. With the Nango skill, Claude Code researches the API, writes the integration, tests it against a real connection with nango dryrun, and deploys it. The same applies to Cursor, Codex, and other agents.

What MCP servers do coding agents need to integrate external APIs with your product?

Three kinds: a docs-context server (Context7 or an OpenAPI-spec server like Apidog’s) so the agent stops guessing endpoints, the provider’s official MCP server (GitHub, Atlassian, AWS) for build-time operations, and the integration platform’s server (Nango’s docs MCP server for grounding, and its hosted MCP server for the tools your product’s agents call at runtime). Keep the total small; five servers can cost around 55,000 tokens of context before any work starts.

How do AI coding agents handle OAuth?

They don’t, directly: an agent cannot register an OAuth app or click through a consent screen. You either complete the flow yourself during development (with RedirectMeTo or ngrok solving the localhost redirect problem) or use a platform like Nango, where a human authorizes a test connection once and the agent builds and tests against that connection ID. In production, end users authorize through a hosted auth flow, and tokens stay hidden from your agent.

Should I give my coding agent a skill or an MCP server?

Use a skill for a defined, repeatable workflow and an MCP server when the agent needs discoverability or live data. Skills load on demand and cost almost nothing in context, while MCP servers front-load their tool definitions into every conversation. For API integration work, the strongest setup is one integration skill plus one or two MCP servers for docs and provider access. For the full comparison of integration skills, see 3 best API integration skills for Claude and Codex.

Conclusion

The gap between writing code and shipping API integrations is tooling, and in 2026, the toolbox has settled into clear layers: docs context (Context7, Apidog), procedure (agent skills), build-time provider access (official MCP servers), auth and testing utilities (RedirectMeTo, ngrok), and an integration platform that supplies real connections, a test loop, and a runtime.

Nango is the only tool that covers the last layer end to end, which is why the rest of the toolbox fits around it: the agent grounds itself with docs tools, follows a skill, and builds on Nango’s auth, testing, and runtime across 900+ APIs. To try the workflow, follow the coding agent setup guide with your favorite coding agent.

MCP vs tool calls for AI agents: which is better?

Sapnesh Naik — Wed, 15 Jul 2026 02:12:22 +0000

If you are building an AI agent in your product that needs third-party API integrations (fetch a customer from Salesforce, send a Slack message, update a deal in HubSpot), you have two ways to give it tools: connect it to MCP (Model Context Protocol) servers, or define custom tool calls (also called function calling).

The two are not alternatives at the protocol level: MCP is built on top of tool calling. This article explains both, how they differ, and which one to use in production.

TL;DR

Tool calls (function calling) are the base mechanism: you pass tool schemas to the model, the model picks one and returns arguments, and your code executes the call. You control tool design, auth, and execution, and you build all of it.

MCP is an open protocol on top of tool calling. It standardizes how agents discover and call tools from servers, so the same server works with agents built on Anthropic, OpenAI, LangChain, or any other stack with an MCP client. Generic third-party MCP servers are fast to wire up, but they cost context, reduce tool-selection accuracy, and add an auth and security surface you do not control.

The short answer:

Pick custom tool calls for the production agent inside your SaaS product. They win on reliability, token cost, and per-user auth. In our fall 2025 survey of several hundred teams building agent integrations, fewer than 10 kept MCP in production.
Pick MCP servers for prototypes, internal agents, and developer tooling, where setup speed matters more than per-request cost and your own engineers supervise the agent.
Use both by writing custom tools once and serving them over an MCP server. Nango supports this: use coding agents like Claude Code, Cursor, and Codex to build custom tool calls on the platform, and your agent consumes them via REST or Nango’s built-in MCP server.

What are tool calls?

Tool calling is an LLM feature. OpenAI shipped function calling on June 13, 2023, and Anthropic’s tool use reached general availability on May 30, 2024. The mechanics are the same everywhere:

You pass tool definitions (name, description, JSON Schema input) with your request.
Based on the user’s prompt, the model decides a tool is needed and returns the tool name plus arguments.
Your code executes the actual API call and returns the result to the model.
The model uses the result to continue or respond.

A tool has two halves. The first half is the schema the model sees. For a CRM lookup:

{
  "name": "get_customer",
  "description": "Fetch a customer record from the CRM by email address.",
  "input_schema": {
    "type": "object",
    "properties": {
      "email": { "type": "string", "description": "Customer email address" }
    },
    "required": ["email"]
  }
}

The second half is the function your code runs when the model calls the tool. The model only emits structured intent (the tool name and arguments as JSON). Nothing happens until your code matches that intent to real logic:

// Your agent loop routes the model's tool call to code you wrote
async function executeTool(name: string, args: any, user: User) {
  if (name === 'get_customer') {
    const token = await getAccessToken(user, 'salesforce'); // your auth layer
    return crm.searchContacts(args.email, token);           // the actual API call
  }
}

When you use Claude or ChatGPT and tools seem to run automatically, it is because this executor ships inside those apps. When you build an agent in your product, you own the executor. It is where authentication, retries, rate limits, and pagination live.

Schema adherence is largely solved: OpenAI’s structured outputs (August 6, 2024) guarantee arguments match your schema, and Anthropic offers the same with strict: true.

What is MCP?

MCP is an open protocol that Anthropic released on November 25, 2024. It standardizes how AI applications connect to external tools and data over JSON-RPC. Your agent (the MCP host) connects to MCP servers, which expose tools, resources, and prompts.

MCP does not replace tool calling. It rides on it. Your agent calls tools/list on each connected server, receives tool schemas, and passes them to the model as ordinary tool definitions. When the model returns a tool call, the agent forwards it to the server, and the server executes the API request.

So the agent still decides which tool to run by emitting structured intent, exactly as with plain tool calls. What changes is who supplies the schemas and who executes the call: the MCP server does both. That makes the real decision one about tool supply: generic tools from a public server someone else operates, or custom tool calls you design for your product.

MCP vs API: what is the difference?

An API is the interface a service exposes for software to call it. MCP is a protocol that describes those capabilities to an AI agent in a form it can discover and invoke. An MCP server sits between the two: it wraps one or more APIs and presents them to agents as tools. In practice, most MCP servers are API wrappers: a July 2025 study of 116 official MCP servers found 88.6% are backed by REST APIs.

MCP does not replace APIs. Someone still registers the OAuth app, makes the API requests, and handles errors inside the server. When you compare MCP vs API access for your agent, you are really comparing who wrote and operates that wrapper: a third party (an MCP server) or you (custom tool calls).

Using third-party MCP servers in your product’s agent

Connecting a pre-built MCP server to your agent takes minutes. These are the problems you hit once the agent runs inside your product:

Tool definitions consume context on every request: Every tool the agent can see adds its definition to every model request, and the model reads all of them before picking one. Generic MCP servers ship tools for every endpoint, so two or three connected servers add tens of thousands of tokens to each request before the agent does any work. You pay for that in tokens, and your customers feel it as latency.
More tools mean worse tool selection: The more tools the model sees, the more likely it picks the wrong one or hallucinates arguments. OpenAI recommends keeping fewer than 20 tools available per turn, and Anthropic documents accuracy dropping beyond 30 to 50 tools. From working with several hundred teams that build agent integrations, we see most SaaS agents need around 20 tools, customized to their use case.
Generic tools are not shaped to your product: Most public MCP servers wrap API endpoints one-to-one. Your product might need one tool like onboard_user_to_slack. With a generic Slack server, the agent instead chains search_user, create_channel, invite_user, and send_message, and every extra call is a chance to fail in front of a customer. We covered the fix in how to build reliable tool calls for AI agents.

Per-user auth is rarely supported: In your product, each customer connects their own Salesforce or Slack, and every action the agent takes must run with that customer’s token. Public MCP servers are mostly built for one user connecting their own accounts. MCP’s OAuth flow authorizes your agent to the server, and auth to the underlying API is whatever the server operator built. Multi-tenant, per-user auth across your customer base is rarely part of it, so you end up building that layer yourself anyway.
You do not control the code that touches customer data: The third party hosts the server and executes the tool calls. You cannot review, customize, or patch that code, and your customers’ tokens and records flow through it. In September 2025, the postmark-mcp npm package shipped an update that BCC’d every email it sent to an attacker’s address. If integrations are core to your product, you want to own the logic that executes tool calls.
Server quality varies: Across the roughly 10,000 active MCP servers, maintenance and quality are uneven.

Using custom tool calls in your product’s agent

With custom tool calls, the agent gets a small set of tools shaped to your product (an upsert_contact instead of four chained CRM calls), your users authorize their own accounts through your app, and only your code touches their data.

What you own:

The execution layer: OAuth apps, token refresh, retries, rate limits, and pagination for every API you integrate. Based on our experience implementing auth for 800+ APIs, this is deeper work than it looks.
Tool maintenance: The underlying API changes, your product’s use cases change, and the tools have to keep up.
The execution platform: Tool code needs hosting, scaling, secrets management, and logs, separate from your product’s core backend.

The build cost has dropped since coding agents became good at writing integration code. We built 200+ API integrations in 15 minutes with OpenCode and the Nango builder skill.

MCP vs custom tool calls: comparison

Dimension	Custom tool calls	Third-party MCP servers
Time to first call	Hours with a coding agent	Minutes
Tool design	Shaped to your use cases	Generic, endpoint-shaped
Context cost	Low: only the tools you define	High: all connected servers' definitions
Tool-selection reliability	High: small, curated set	Degrades as the catalog grows
Auth to the external API	You implement it (or use a platform)	Server operator implements it, quality varies
Per-user auth (your customers authorize their accounts)	Yes, under your control	Rarely supported
Security surface	Smaller: your code	Larger: third-party code plus untrusted tool descriptions
Maintenance	You maintain the tools	You depend on the server maintainer
Works with your agent framework	Yes, via REST or SDK call	Yes, if the framework has an MCP client

How to choose

Two questions decide it: who supervises the agent, and whose accounts does it act on?

Developer tooling and internal agents: Public MCP servers are a good fit. Your own engineers supervise the calls, a flaky tool is an annoyance rather than a customer incident, and if the API you need already has an MCP server, it is quick to wire up. You can switch to custom tools later anyway.
The production agent in your customer-facing product: Use custom tool calls. Your customers authorize their own accounts, the agent picks from a small set of tools that match your product, and requests stay fast and cheap because the context only carries tools you chose.

Custom tools can also be served over MCP. Write the tools once, then let your agent consume them over REST, or over an MCP server if your agent framework is MCP-native.

Build custom tool calls (and get an MCP server) with Nango

With Nango, you build custom tool calls against external APIs on infrastructure built for scale, and coding agents do most of the work. For your product’s agent, it works in three parts:

Build tools with coding agents: Use Claude Code, Cursor, or Codex with the Nango builder skill to research the external API, write the tool call as a typed function, and test it against a real connection, within minutes.
Nango runs them: Auth (OAuth, API keys, token refresh), retries, rate limits, and per-execution logs across 800+ APIs. Your users authorize their accounts in your app, credentials stay server-side, and your agent only ever holds a connection ID.
Your agent consumes them from any stack: Trigger tools over REST from OpenAI, Anthropic, the Vercel AI SDK, LangChain, or Mastra, or point an MCP-native agent at Nango’s built-in MCP server at https://api.nango.dev/mcp, which serves the same custom tools with strict typed schemas.

Here is how the pieces fit together at runtime:

If part of your integration surface is a third-party MCP server, Nango covers that side too: the MCP Generic integration manages your users’ OAuth to external MCP servers (dynamic discovery, PKCE, client registration).

For real examples of building custom tool calls and exposing them to an agent, see how we built GitHub, Notion, and Gmail integrations for AI agents.

FAQ: MCP vs function calling

Should I use MCP or tool calls for the AI agent in my product?

Use custom tool calls if the agent ships to customers, and MCP servers for internal agents and developer tooling. Custom tools give you per-user auth, a small reliable toolset, and control over the code that touches customer data. MCP servers get you running fastest when your own engineers supervise the agent.

How is MCP different from function calling?

Function calling is the LLM mechanism where a model returns a structured request to run a function you defined. MCP is a protocol built on top of it that standardizes how tools are discovered and executed across clients and servers. Every MCP tool still reaches the model as an ordinary function definition.

How does authentication work with MCP vs custom tool calls?

With custom tool calls, your app runs the OAuth flow with each customer and your executor attaches that customer’s token to every API call (a platform like Nango manages this). With MCP, the OAuth flow authorizes your agent to the MCP server, and auth to the underlying API depends on what the server operator built. For a deeper look, see our guide to secure AI agent authentication and how ID-JAG helps AI agents authenticate.

How much context do MCP tool definitions consume?

Often tens of thousands of tokens per request, because every connected server’s tool definitions load into the model request whether the agent uses them or not. Anthropic documents a typical five-server setup at around 55,000 tokens of tool definitions.

When should you not use MCP?

Avoid third-party MCP servers when your agent runs unattended inside a customer-facing product: token overhead hits every request, generic tools reduce reliability, per-user auth is rarely supported, and you cannot review the code that handles customer data. Use custom tool calls there, and serve them over your own MCP server if your agent stack expects MCP.

Conclusion

MCP and tool calls sit at different layers. MCP standardizes tool discovery and execution on top of function calling, and public MCP servers are the fastest route for internal agents and developer tooling. For the agent inside your product, custom tool calls are the safer choice: your customers authorize their own accounts, the agent works from a small set of tools built for your use cases, and you own the code that touches customer data. Build them with a coding agent, run them on a platform that handles auth and execution, and serve them over REST or MCP.

Related reading:

How to make AI agents react to API webhooks

Sapnesh Naik — Wed, 01 Jul 2026 14:53:52 +0000

Most AI agents only act when a user prompts them. They sit idle until someone types a message or calls them over an API. But a lot of real work happens in external systems: a deal moves to “closed won” in Salesforce, a customer sends a message in Slack, a payment fails in Stripe, or a new file lands in Google Drive.

To handle those cases, your agent has to react to events happening in external systems instead of waiting for a prompt. This post covers why event-driven AI agents matter and the main ways to make an agent react to external events, and what to do once an event arrives.

Why AI agents need to react to external events

An event-driven AI agent responds to changes in external systems in near real time, instead of waiting for a user to prompt it.

There are two ways to trigger an agent:

Pull (request-response): the agent runs when a user or another service calls it. This fits chat and on-demand tasks.
Push (event-driven): the agent runs when something happens in an external system. This fits automation that should not wait for a human.

The push model matters for three reasons. It reacts in seconds rather than on the next polling cycle. It avoids the wasted API calls and cost of checking for changes that did not happen. And it lets the agent do useful work in the background, with no human in the loop.

Common use cases for event-driven AI agents

Event-driven agents are useful anywhere a change in one system should trigger work in another. A few concrete examples:

CRM updates: a deal changes stage in Salesforce. The agent drafts a follow-up email and updates the next step.
Support tickets: a ticket arrives in Zendesk. The agent triages it, adds tags, and suggests a reply.
Team messaging: a customer posts in a shared Slack channel. The agent answers from your docs and CRM data.
Code review: a pull request opens in GitHub. A review agent reads the diff and comments.
Payments: a charge fails in Stripe. The agent retries, notifies the customer, and flags the account.
File processing: a file uploads to Google Drive. The agent extracts the text and syncs it to your RAG index.

They all share the same shape: an external event triggers the agent, the agent reads context, and the agent takes action through APIs.

Ways to make AI agents react to external events

There are three main mechanisms: polling on a schedule, webhooks from external APIs, and event streams. Most production systems combine at least two of them, depending on what the external API supports.

Mechanism	Latency	Efficiency	Best for
Polling	Minutes	Low (runs even when nothing changed)	APIs with no webhooks, and as a reliability safety net
Webhooks	Seconds	High (fires only on a real change)	Most real-time reactions to SaaS events
Event streams	Milliseconds to seconds	High at large volume	High-throughput pipelines and agent-to-agent workflows

Polling on a schedule

Polling means the agent, or a background job, checks an API on a fixed interval and reacts to anything new since the last check.

It is the simplest option and works with any API, even ones that offer no push mechanism. The tradeoffs are latency and waste: your reaction time is only as fast as the interval, and most requests return nothing new while still counting against rate limits.

Use polling when an API has no webhooks, or as a safety net behind webhooks (more on that below).

Webhooks from external APIs

A webhook is an HTTP POST that a provider sends to your endpoint the moment something changes. This is the push model, and for most real-time use cases it is the right default: reactions arrive in seconds, and the provider only calls you when there is an actual change.

The catch is that every provider does webhooks differently. Each one has its own registration flow, payload shape, signature scheme, and retry behavior. On top of that, you have to map each incoming event back to the right customer in your system, and some subscriptions expire and need renewal. Google Calendar push channels expire after 7 days, and Gmail’s push watch expires on the same cadence, so you have to re-register both before they lapse.

The mechanism is simple. The work is in the per-provider plumbing around it, which is where an integration platform helps (covered below).

Event streams and message queues

For high-throughput or multi-agent systems, events flow through a stream or message queue such as Kafka, Amazon SQS, or Google Pub/Sub. Agents subscribe to the stream and process events as they arrive.

This adds two capabilities that raw webhooks do not have. You can replay history, so an agent can reprocess past events after a bug fix. And agents can react to each other: agent A emits a task.completed event, agent B listens for it and continues the workflow. This is the choreography pattern, and it is how larger multi-agent systems stay decoupled.

The tradeoff is that you run and scale the streaming infrastructure yourself. Reach for this when volume is high or when you have several agents coordinating. It is overkill for a single agent reacting to a handful of SaaS events.

What to do when an event arrives

Once the event reaches your system, the agent usually does one of four things:

Execute a tool call: run a predefined, typed function like upsert-contact or create-issue via API or MCP. This keeps the action deterministic and safe, instead of letting the LLM build a raw HTTP request.
Trigger a data sync: refresh your local copy of the customer’s data (and your RAG index) for that connection, so the agent reasons over fresh context.
Call an API directly: for a one-off read or write, send a single request to the provider without managing auth yourself.
Start or resume an agent loop: hand the event and the right tools to the LLM and let it decide the next steps.

These are often chained. A common pattern is: event arrives, trigger a sync to pull the latest data, let the agent reason over it, then have the agent run a tool call to write something back.

Making event handling reliable

Reacting to events in production takes more than receiving an HTTP request:

Verify signatures: most providers sign webhooks with an HMAC of the payload. Compute the HMAC with your shared secret and compare it to the header, using the raw request body before any JSON parsing.
Deduplicate events: networks cause webhooks to arrive more than once. Track each event ID and skip anything you have already processed, so the agent does not act twice.
Return fast, process async: acknowledge the webhook with a 200 quickly, then do the real work in the background. Slow handlers cause providers to time out and retry.
Keep a polling safety net: webhooks get dropped. Google’s own docs note push notifications are “not 100% reliable”. A low-frequency poll catches anything the webhooks miss.
Map events to the right connection: a webhook usually identifies an account, not your internal customer. You need a reliable way to resolve which customer and credentials each event belongs to.

Reacting to external events with Nango

Nango is the integration platform where coding agents build integrations. Engineers use agent skills with coding tools like Claude Code, Cursor, and Codex to build integrations as code in a git repo, and Nango’s cloud runtime runs them securely and at scale. Integrations cover API auth, tool calls, data syncs, and webhooks across 800+ APIs, and it is open source.

For the event side specifically, Nango removes most of the plumbing described above. It gives each integration one webhook URL, attributes every incoming event to the right connection, verifies the provider’s signature, retries, and logs each event. You then choose what happens next:

Forward the event to your app: Nango sends you a normalized payload with the connectionId already resolved, and your backend handles the logic. Use this when you already have webhook handling. See webhook forwarding.
Process the event inside Nango: a webhook function runs as soon as the event arrives. It can update your synced data or trigger an incremental sync so your app reads fresh records. See real-time syncs.

A forwarded event arrives at your endpoint in a consistent envelope, regardless of provider. Nango wraps the provider’s raw event in payload and adds the resolved connectionId, so you always know which customer it belongs to:

{
  "from": "hubspot",
  "providerConfigKey": "hubspot",
  "type": "forward",
  "connectionId": "connection-123",
  "payload": {
    "subscriptionType": "contact.propertyChange",
    "objectId": 1024,
    "propertyName": "lifecyclestage",
    "propertyValue": "customer"
  }
}

Processing an event inside a sync function looks like this. The onWebhook handler runs when the provider sends an event, and the scheduled frequency acts as the safety net for anything the webhooks miss:

import { createSync } from 'nango';

export default createSync({
    description: 'Sync CRM contacts, react to changes in real time',
    frequency: 'every hour', // safety net for missed webhooks
    webhookSubscriptions: ['*'], // route provider webhooks to onWebhook
    // ...models and checkpoint config
    exec: async (nango) => {
        await syncContacts(nango); // scheduled poll
    },
    onWebhook: async (nango, payload) => {
        await syncContacts(nango); // same logic, triggered by the event
    },
});

Once the data is fresh, the agent acts. With Nango you can run a typed tool call (also exposed over MCP), or make a one-off request to any endpoint through the proxy without touching tokens:

// Run a predefined tool call for the connection that emitted the event
await nango.triggerAction('salesforce', connectionId, 'create-note', {
    dealId,
    body: draftedNote,
});

// Or make a direct API call through Nango's proxy (auth handled for you)
const res = await nango.get({
    endpoint: '/crm/v3/objects/contacts',
    providerConfigKey: 'hubspot',
    connectionId,
});

You do not write this integration code by hand. Nango ships skills for AI coding agents so Claude Code, Cursor, or Codex can research the API, write the webhook and sync functions, and test them against a real connection. That makes just-in-time integrations practical: an agent can build a new event-driven integration on demand, prompted by an engineer or even a customer, instead of your team pre-building one per provider.

Once events are flowing, every run shows up in the Nango dashboard, attributed to the connection it belongs to, so you can see which action, sync, and webhook fired for each customer:

Conclusion

Getting an AI agent to react to external events comes down to two decisions. First, pick how the event reaches you: polling for APIs without push support, webhooks for most real-time cases, and event streams for high volume or multi-agent workflows. Second, decide what the agent does with the event: run a tool call, trigger a sync, call an API directly, or start an agent loop.

The event mechanism is simple. Signatures, deduplication, connection mapping, renewals, and a polling fallback are where most of the effort goes, and they repeat for every provider. A code-first integration platform like Nango handles that layer so your agent code stays focused on what to do when something happens, not on the plumbing that tells it something happened.

Related reading:

Arcade.dev vs Nango: which platform for production AI agent integrations in 2026?

Sapnesh Naik — Tue, 30 Jun 2026 16:42:01 +0000

TL;DR

Arcade.dev is an MCP runtime for AI agent tool calling, built around agent authorization. It exposes a catalog of pre-built tools over MCP, handles per-user OAuth, and ships an SDK for writing your own MCP servers. But Arcade only has tool calls: no data syncs for RAG, no webhook ingestion, no polling triggers, and no coding-agent build loop.

Nango is the integration platform where coding agents build API integrations. Engineers use coding agents like Claude Code, Cursor, and Codex to write integrations as code in a repo. Nango’s cloud runtime runs them securely and at scale across 800+ APIs, with white-label auth, custom tool calls, an MCP server, durable data syncs, webhooks, and per-customer configuration on one platform.

Quick verdict:

Pick Nango if agent integrations are core to a product you ship to customers, or if you want coding agents to build and customize tool calls, syncs, and webhooks as you scale.
Pick Arcade.dev if your agent’s entire scope is MCP tool calling, your APIs are in its catalog, and you do not need data syncs, webhooks, or a coding-agent build loop.

Arcade.dev: an MCP runtime for agent tool calling and authorization

Arcade.dev is an MCP runtime that handles per-user OAuth, stores user tokens, and exposes a catalog of pre-built tools that agents call over the Model Context Protocol.

The catalog is large: 7,000+ pre-built tools across roughly 80 first-party MCP servers, split into hand-built (“Optimized”) and auto-generated (“Unoptimized”) tiers, and you can hand-write your own with the open-source arcade-mcp framework. The trade-off is scope. Arcade is built for the run side of one pattern, tool calls, so there are no data syncs or webhooks, the build process does not leverage AI, the Engine that stores tokens is proprietary, and several governance features are Enterprise-only.

Nango: build integrations with AI

Nango is a code-first platform where engineers use AI coding agents like Claude Code and Cursor to build API integrations for your product and the AI agents inside it. The integrations cover an agent’s full surface: tool calls and an MCP server the agents consume, plus the auth, data syncs, and webhooks behind them. The platform is a three-part system:

Integrations as code, written by your coding agent. Install the universal Nango builder skill once. The agent reads API docs, builds the integration, tests it against a real connection, and iterates on real errors.
A secure and scalable runtime. Functions run on Nango’s cloud with tenant isolation and resumable execution.
A single interface for every use case. API auth, tool calls, data syncs, webhooks, polling triggers, and custom unified APIs, all as functions in your repo.

Nango is open source, supports 4,400+ prebuilt tools across 800+ APIs and 30 categories, and is used in production by hundreds of fast-growing SaaS and AI companies. It also supports just-in-time integrations: a coding agent builds an integration on demand when a customer asks for one, instead of pre-building every one by hand.

Six limits with Arcade.dev

Arcade fits a narrow scope: an agent calls a few APIs as a real user, and those APIs are in the catalog. As the surface widens, six limits show up.

No coding-agent skill for building integrations

Arcade’s SDK is for a human developer hand-writing and packaging MCP servers locally. There is no skill for Claude Code, Cursor, or Codex, no testing loop against a real connection, and no path for a coding agent to author and ship a tool end-to-end.

Tool calls are the only pattern

Arcade covers tool calling and nothing else: no durable data syncs for RAG, no webhook ingestion, no polling triggers, no unified-API layer. So when your agent needs the freshest CRM records, or has to react when a deal closes in Salesforce, you build the sync, the schedule, the resume logic, and the webhook receiver yourself, outside Arcade.

Low API support

The 7,000+ figure counts individual tools. What matters for coverage is how many APIs you can reach: roughly 80 first-party MCP servers, with the rest of the registry made up of community and auto-generated ones that may need customization before they are production-ready. When your API is not covered, you hand-write an MCP server in the SDK. Generic, non-bespoke tools also inflate context and hurt reliability, because they are not tailored to your agent’s intent.

Your customers authorize Arcade and not your app

By default, end users see “Arcade” on the OAuth consent screen and sign in through arcade.dev. To put your brand on the flow, you register your own OAuth client per provider and build a custom verifier route. That is workable, but it is per-provider configuration you own, not a drop-in default, which matters when every customer connects their own account under your brand.

Governance, RBAC, SSO, and tenant isolation are Enterprise-gated

Arcade markets central governance, but the controls that back it up are Enterprise-only: audit logs and compliance reporting, role-based access control, SSO and SAML, and dedicated tenant isolation. On the free and usage-based tiers, you run on shared infrastructure without them.

The runtime that holds your tokens is proprietary

Arcade is not fully open-source. The Engine, the hosted runtime that stores user tokens, brokers OAuth, and executes tool calls, is proprietary, and self-hosting it (VPC, on-prem, or air-gapped) requires Enterprise deployment.

What engineers like about Nango

Nango covers agent authorization, custom tool calls, data syncs, webhook processing, and unified APIs on a single runtime, with code-level access and an AI coding agent build loop built in.

Coding agents build the integrations

Install the Nango builder skill once. Your coding agent reads API docs, writes the integration, tests it against a real connection with nango dryrun, and iterates on real errors before deploying. The skill works the same way for any of the 800+ APIs Nango supports.

A prompt like this is enough:

/building-nango-functions-locally Build a real-time Google Calendar integration with webhook support.

Every integration use case on one platform

API auth, data syncs, webhook processing, polling triggers, tool calls, and an MCP server all run on Nango. A Nango sync is the same kind of function as a Nango tool call. Both share the same runtime, observability, and build loop. Arcade is tool-call only; the rest of your integration surface lives elsewhere.

Built-in MCP server with custom tools

Nango’s MCP server exposes your custom tools to AI agents inside your product, with strict typed input and output schemas. Because the tools are yours, you can author intent-shaped tool calls that match your product’s exact intent instead of chaining generic ones. The MCP server enforces per-user and per-customer permissions through the same runtime that runs your auth and syncs.

White-label auth across 800+ APIs

A drop-in Connect UI handles OAuth, API keys, JWT, basic auth, and the MCP Auth standard. End users authorize against your brand, not Nango’s, by default. Headless auth is available if you want to ship your own UI. Token refresh, concurrency-safe refresh, and custom credential validation ship on every plan.

Deep observability with OpenTelemetry

Every operation generates structured logs with full external API request and response details, custom log messages, full-text search, and OpenTelemetry export, on every plan. A Claude Code session can read a failing dry run, see the exact response that broke parsing, and ship a fix in the same turn.

Open source, compliance, and self-hosting

Nango is open source and SOC 2 Type II, GDPR, and HIPAA compliant. Self-hosting is available for teams with data residency or risk-management requirements. Tenant isolation, structured audit logs of every external API call, and encrypted credentials at rest ship by default.

Arcade.dev vs Nango for AI agents and LLM tool calling

If you are building AI agents that call third-party APIs in production, three things matter: how new tools get built, whether those tools can be customized to your product’s intent, and whether the rest of the integration stack (auth, syncs, webhooks) lives on the same runtime.

Arcade has a fixed catalog. It handles per-user OAuth, checks permissions before a tool runs, and exposes a large set of pre-built tools over MCP. The constraints are that you build with the catalog Arcade ships, custom tools are hand-written in the SDK, and the surface stops at tool calls. There is no coding-agent skill that authors and deploys a new tool, and no data syncs or webhooks when your agent needs more than a single call.

Nango has custom tool calls, an MCP server, agent auth, and AI coding agent support. Your coding agent writes tool calls as TypeScript functions in your repo. Each function deploys to Nango and is exposed through the Nango MCP server with strict typed schemas. Per-user and per-customer permissions are enforced by the same runtime that runs your auth and syncs. When the agent needs fresh data, it queries a Nango sync, not a polling cycle you wrote yourself.

For the full pattern, see best agentic API integrations platform in 2026.

Arcade.dev vs Nango: feature comparison

Here is how Arcade.dev and Nango compare across each agent integration pattern: tool calls, MCP, data syncs for RAG, webhooks and triggers, developer experience, customizability, open source, and self-hosting.

Feature	Nango	Arcade.dev
Catalog	4,400+ prebuilt tools across 800+ APIs (30 categories)	7,000+ tools across ~80 first-party MCP servers (~157 in registry incl. community)
Build model	Code in your repo, written by your coding agent	Hand-written MCP servers in the Arcade SDK
AI coding agent skill (Claude Code, Cursor, Codex)	Yes (universal builder skill, dryrun against real APIs)	No
Custom tool calls deployed to runtime	Yes	Yes (hand-written via SDK)
MCP server	Built-in, exposes your custom tools	MCP-native, exposes catalog and custom servers
Agent authorization (per-user OAuth)	Yes	Yes
Data syncs for RAG	Durable, incremental syncs	No
Webhooks and triggers	Real-time webhook ingestion and polling triggers	No
Per-customer configuration	Yes, in code, every plan	Limited
Observability with full request/response logs and OpenTelemetry export	Yes, every plan	Basic
RBAC, SSO, audit logs	Available	Enterprise-only
Open source	Yes (platform and templates)	Partial (MIT framework and SDK; proprietary Engine)
Self-hosting	Yes (Enterprise)	Enterprise (VPC, on-prem, air-gapped)
Pricing	Free tier, transparent usage-based	Free tier, usage-based on tool executions

When Arcade.dev is the right pick

Arcade.dev is a good fit when MCP tool calling is the entire job. Your agent acts on behalf of users across a handful of APIs, those APIs are in the catalog, per-user authorization is the hard part, and you do not need data syncs, webhook processing, per-customer configuration, or a coding agent to build new tools for you. For an internal or personal-productivity agent that lives inside the catalog, Arcade does what it advertises.

When Nango is the right pick

Nango is the right pick when your AI agent is a core part of a product you ship to customers, when you want coding agents to build and customize integrations in your repo, or when your agent needs more than tool calls: data syncs for RAG, real-time webhooks, custom unified APIs, white-label auth across hundreds of APIs, or per-customer configuration.

Nango covers the same starting point Arcade offers (an MCP server, managed per-user OAuth, custom tools) and adds the build loop, the runtime patterns, and the API breadth that a production AI product grows into. Transparent usage-based pricing and a free tier come built in.

How to migrate from Arcade.dev to Nango

To migrate from Arcade.dev to Nango:

Build any new integrations on Nango first. Do not start new work on Arcade. This caps the scope of what eventually needs to be migrated.
Install the Nango builder skill in your coding agent (supports Claude Code, Cursor, Codex, Gemini CLI, OpenCode, and others).
Have the coding agent migrate existing tools one by one. Prompt it with the intent of each Arcade tool or MCP server. The skill reads the API docs, drafts the function, tests against a Nango test connection, and iterates on real responses. Auth, retries, pagination, and observability are handled by the runtime.
Wire the agent to Nango. Expose the new tools through Nango’s REST API or MCP server. For most frameworks, this is a one-line config change.
Add the patterns you were missing on Arcade. Move RAG context loading to Nango syncs. Move event-driven behavior to Nango webhooks or polling triggers.
Migrate customer connections. Use Nango’s white-label Connect UI to re-authorize customers under your brand.
Cut traffic over behind a feature flag. Run Nango and Arcade side by side, ramp up the share of calls on Nango, and verify in the logs that behavior matches.
Decommission Arcade at the renewal boundary.

FAQ

Is Nango an Arcade.dev alternative?

Yes. Nango is the agentic API integrations platform that production AI teams pick when they outgrow Arcade.dev. The most common reasons for the switch are a coding-agent build loop, data syncs for RAG, webhook processing, white-label auth across more APIs, deep observability, and per-customer configuration. Nango supports 800+ APIs, ships an MCP server with custom tools, and runs auth, tool calls, syncs, webhooks, and unified APIs on one runtime.

What is the difference between Arcade.dev and Nango?

Arcade.dev is an MCP runtime for AI agent tool calling, built around per-user agent authorization. It exposes a catalog of pre-built tools and an SDK for hand-writing custom MCP servers, and its surface stops at tool calls. Nango is an integration platform where coding agents write integrations as code in your repo, and the runtime covers auth, tool calls, data syncs, webhooks, and unified APIs across 800+ APIs.

Does Arcade.dev support data syncs or webhooks?

No. Arcade.dev supports tool calls only. There is no data sync capability for RAG, no webhook ingestion for provider events, and no polling trigger for providers that do not ship webhooks. Nango supports all of these on the same runtime, so one platform covers the full integration surface an AI product needs.

Which platform handles agent authorization better?

Both handle per-user OAuth so an agent can act as a real user. Arcade focuses its product on this for its tool catalog. Nango handles auth across 800+ APIs with a drop-in white-label flow, supports OAuth, API keys, JWT, basic auth, and the MCP Auth standard, and uses the same auth layer to power tool calls, data syncs, and webhooks. For an AI agent that only calls a few catalog APIs, Arcade is enough; for a product that authenticates across many APIs and needs more than tool calls, Nango is broader. See best AI agent authentication platforms in 2026.

Arcade.dev vs Nango: which is better for building API integrations for AI agents?

Nango. For an engineer building API integrations for AI agents, Nango is the better choice: it covers every integration pattern an agent needs (tool calls, MCP, data syncs for RAG, webhooks, and triggers) on one runtime, and coding agents like Claude Code and Cursor build and customize those integrations in your repo across 800+ APIs. Arcade.dev is limited to MCP tool calling against its catalog, with no data syncs, no webhooks, and no coding-agent build loop. Pick Arcade only when tool calling is your agent’s entire scope.

Conclusion

Arcade.dev is a good choice for wiring an AI agent to a catalog of pre-built tools for an internal or personal-productivity agent whose main scope is tool calling.

Nango is the integration platform you pick when your AI agent is a core part of a product you ship to customers. Coding agents build the integrations in your repo across 800+ APIs. The same runtime exposes custom tool calls, an MCP server, durable data syncs, webhooks, white-label auth, and deep observability. The build side is the differentiator now that every platform ships an MCP server, and Nango is the one where the code your agent writes today runs unmodified in a hardened, tenant-isolated runtime tomorrow.

3 best API integration skills for Claude and Codex in 2026

Sapnesh Naik — Tue, 23 Jun 2026 17:44:14 +0000

TL;DR

Coding agents write code well but build API integrations poorly on their own. They refer to old training data, invent endpoints and parameters, skip token refresh and pagination, and ship code that compiles but fails in production. A good API integration skill closes that gap: it encodes the patterns, points the agent at a way to test against the real API, and deploys to a runtime.

The skills compared here:

Nango Function Builder skill (local): Build full integrations as code in your repo with any of 18+ coding agents, test against a real connection with nango dryrun, then deploy to Nango’s runtime. Broadest option.
Nango remote function builder: The same skill over the Functions API, with no local project. An agent (inside your product) builds, tests, and deploys an integration straight from a prompt. This is how just-in-time integrations work.
Prismatic Skills for Claude Code: Builds Prismatic low-code workflow integrations from Claude Code. Claude Code only, and tied to the Prismatic platform.

What is a skill?

A skill is a packaged capability for a coding agent like Claude. Skills contain instructions, plus optional bundled scripts and reference files the agent loads when needed.

Anthropic introduced Agent Skills in October, 2025, and published the format as an open standard. OpenAI then added native Agent Skills to Codex using the same SKILL.md format, and treats skills as the recommended way to give Codex reusable instructions.

Why coding agents need skills to build API integrations

Coding agents are good at writing code, but building a production API integration is difficult.

In a 2025 study benchmarking LLMs on web API integration tasks, models hallucinated endpoint URLs up to 39% of the time and parameter names up to 31% of the time, and none of the open-source models tested solved more than 40% of the tasks. The same pattern shows up in dependencies: a 2025 USENIX Security study of 576,000 generated code samples found that 19.7% of the packages the models recommended did not exist.

There is also the part that is not code at all. A real integration has to handle OAuth and token refresh, pagination, retries, rate limits, webhook delivery, incremental syncs, and observability. An agent can write a fetch call, but it cannot reliably reproduce the infrastructure that keeps that call working across providers and customers. Code that compiles is not an integration that runs in production.

A skill addresses the first problem by encoding procedural knowledge: the patterns, decision trees, and provider quirks an experienced integration engineer already carries.

But a skill on its own is still not enough. Two things separate a skill that produces a working integration from one that produces a plausible draft:

A test loop against the real API: The agent needs to run its code against a real connection, read the actual response or error, and iterate. Without that loop, it guesses, and the 39% endpoint-hallucination rate is what you get.
A runtime to deploy to: Auth, scaling, webhook ingestion, and logging have to live somewhere. A skill that ends at “here is some code” leaves you to build and operate all of that yourself.

How we evaluated these skills

Each skill is scored on the questions that decide whether an agent ships a working integration or a draft:

Does it build a real integration as code? Auth, actions, syncs, triggers and webhooks.
Does it work with all coding agents? A cross-agent skill fits whatever your team already uses; a single-agent skill locks you in.
Does it test against a real provider API? With real credentials and real responses, so the agent iterates on actual errors.
Does it deploy to a managed runtime? Or does it leave you to host, scale, and monitor the result.
Does it cover the run side too? A built-in MCP server and typed tool calls, so the agents in your product can consume what was built.
Is it open and portable? Open-standard skill format, open-source platform, integration code you own.

The 3 best API integration skills for Claude and Codex

1. Nango Function Builder skill (local)

Nango is the integration platform where coding agents build integrations. Agents like Claude Code and Codex, write integrations as code in your repo. Nango’s cloud runtime runs them securely and at scale, covering API auth, tool calls, data syncs, and webhooks across 800+ APIs.

The local Function Builder skill is the build side of that platform. Install it once and it works across all coding agents, including Claude Code, Codex, Cursor, Gemini CLI, and OpenCode. The agent researches the API, writes the integration as a code function, tests it against a real connection, and iterates on real errors until it passes.

Best for

Teams that want a coding agent to build and ship production integrations against any API, with one skill that covers auth, actions, syncs, and webhooks, and a runtime that exposes them to the agents inside their product.

Pros

One skill, 18+ agents: A single install gives Claude Code, Codex, Cursor, Gemini CLI, OpenCode, and others the same context to research an API, write the integration, and test it.
Tests against the real API: nango dryrun runs generated code against a real connection, returns the real response, and lets the agent fix real errors. This is the test loop most agents lack, and it is what closes the endpoint-hallucination gap.
Deploys to a managed runtime: The same code runs unmodified in a tenant-isolated runtime with managed auth (OAuth, API keys, JWT, basic auth, MCP Auth), durable syncs that resume across millions of records, and webhook ingestion at scale.
Covers the run side: Every action is exposed as a typed tool call over REST and a built-in MCP server, so the AI agents in your product consume what the coding agent built.
Observability the agent can read: Full request and response logs with OpenTelemetry export, so a coding agent can read a failing run and ship a fix on its own.
Open and reviewable: The platform is open source, integrations are code in your repo under normal review and CI/CD, and you keep your customers’ tokens.

Cons

Needs Nango account: You need to create a free Nango account to try this Skill.

To try it, install the Nango CLI, scaffold an integrations folder, then add the skill:

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

Then describe the integration in plain English and invoke the skill:

/building-nango-functions-locally Build a Nango action that fetches the last 5 emails
from the Gmail address passed as a parameter, returning subject, timestamp, and plaintext body.

The agent researches the Gmail API, writes the action, runs nango dryrun <action> '<CONNECTION_ID>' -e dev against the real connection, and iterates until it works. See the end-to-end walkthroughs for Google Calendar and GitHub with Codex.

2. Nango remote function builder

The remote function builder is the same Nango skill operating on REST API without a local project. This lets you build, test and deploy API integrations from chat only LLMs like Claude.ai, ChatGPT, or Gemini without the need to give access to your source code.

This is what makes just-in-time integrations possible. You can pair the skill with an agent inside your product, so when a customer asks for an integration that does not exist yet, the agent builds it on demand, tests it, and deploys it for immediate use. The work shifts from building each integration by hand to running a factory that produces them.

Best for

Products that need integrations built on demand, straight from a prompt, by an agent rather than a human picking each one off a roadmap. Useful for integrations where the integration behavior depends on what the customer needs at that moment.

Pros

No local project required: Compile, dry run, and deploy over REST endpoints, so an agent with no checkout (including one running inside your product) can build a complete integration.
Real-API testing still applies: The remote dry run executes against a real connection, so the same test loop that grounds the local skill grounds the remote one.
Powers per-customer integrations: An agent builds the integration a customer asked for, deploys it, and the AI agents in your product call it minutes later, all on the same platform.
Same runtime and auth: Remote-built integrations run in the same tenant-isolated runtime, with the same managed auth and observability, as locally built ones.

Cons

Less suited to heavy source-control workflows: When you want reviewable diffs and CI/CD as the primary path, the local skill is the better default. The remote builder shines for dynamic, on-demand, and in-product generation.

3. Prismatic Skills for Claude Code

Prismatic, an embedded iPaaS, launched Skills for Claude Code on May 4, 2026. It is a Claude Code plugin that helps you build for Prismatic’s low-code platform.

Best for

Teams that mainly want a low-code platform but want to speed up work using Claude code instead of the low-code UI.

Pros

End-to-end on Prismatic: Scaffold, generate, compile, deploy, and test, all from the IDE.
Backed by a dev MCP server: A bundled MCP server gives the agent access to your Prismatic environment while it builds.

Cons

Skill for a low-code platform: Prismatic is mainly a low-code platform. So the agent skill it provides eventually translates down to their low-code schemas. This is not helpful if you’re looking for real code-based scalable integrations.
Claude Code only: No support for Codex, Cursor, Gemini CLI, or OpenCode. If your team uses anything other than Claude Code, the skill does not apply.
No free-standing real-API test loop: The agent imports the integration into Prismatic and tests it inside Prismatic’s runner, and that path needs an already-authorized connection first. You lose the standalone dry run against the provider with your own tokens, where the agent iterates on real responses the way nango dryrun allows.

Comparison of API integration skills for Claude and Codex

Capability	Nango (local)	Nango (remote)	Prismatic Skills
Builds a full integration as code	Yes (auth, actions, syncs, webhooks)	Yes (auth, actions, syncs, webhooks)	Yes (Prismatic workflows)
Works with Claude Code	Yes	Yes	Yes
Works with Codex	Yes	Yes	No
Cross-agent (18+ agents)	Yes	Yes	No
Build with no local project (JIT)	No	Yes	No
Tests against the real provider API	Yes (`nango dryrun`)	Yes (remote dry run)	Partial (in Prismatic's runner)
Managed auth (OAuth, API keys, JWT)	Yes	Yes	Yes
Durable data syncs	Yes	Yes	No
Webhook ingestion at scale	Yes	Yes	Limited
Deploys to a managed runtime	Yes	Yes	Yes (Prismatic)
Built-in MCP server for consumption	Yes	Yes	Yes
Open-source platform	Yes	Yes	No

Choosing the right skill

If you want a coding agent to build, test, and ship integrations end to end against any API, with one skill across Claude, Codex, and 16 other agents: use the Nango Function Builder skill.
If you want integrations built on demand from a prompt, including by an agent inside your product: use the Nango remote function builder.
If you are looking for low-code tools: Prismatic Skills can speed up building Prismatic workflows.
If your agent integrates with a long tail of APIs and you need the build side and the run side on one platform: use Nango. The open-source integration templates and code-first model are built for the long tail.

FAQ

What is the difference between a skill and an MCP server for API integrations?

A skill teaches a coding agent how to build an integration at build time; an MCP server gives an AI agent access to that integration at run time. The two are complementary. You use a skill (like the Nango Function Builder skill) so Claude or Codex can author and test an integration, and an MCP server so the AI agents in your product can call it. A single platform can provide both, which is why Nango ships a build skill and a built-in MCP server.

Do API integration skills work with both Claude and Codex?

Yes, because skills are an open standard. The Nango Function Builder skill works across 18+ agents, including Claude Code, Codex, Cursor, Gemini CLI, and OpenCode. Some vendor skills are narrower: Prismatic’s skill, for example, runs only in Claude Code.

Which coding agent is best for building API integrations?

The agent matters less than the skill and platform behind it. Claude Code, Codex, Cursor, Gemini CLI, and OpenCode are all capable of building API integrations when given a skill that encodes the patterns and a way to test against the real API. Across hundreds of integration builds, the differences between agents were small. See using AI coding agents for building API integrations for the full comparison.

Can a coding agent test an integration against a real API without leaking customer data?

Yes. With Nango, the agent runs nango dryrun against a sandbox or developer connection, gets real API responses, and iterates on real errors, while production tokens stay out of the agent’s reach. You can also issue a narrow-scoped API key so the agent’s build surface is isolated from the production runtime.

Do I need to host my own MCP server to give agents API access?

Not with Nango. The runtime and a built-in MCP server are managed for you, so the integrations a coding agent builds are immediately callable by the AI agents in your product without standing up new infrastructure. If you hand-build your own MCP server instead, you own its hosting, scaling, and maintenance.

Conclusion

Using coding agents like Claude, Cursor and Codex to build API integrations significantly speeds up the work. But these coding agents need the right skills to build reliable API integrations.

The skills enable your coding agent to hook into a provider platform like Nango and leverage the integrations infra for Auth, Syncs, Webhooks and triggers to build production-ready integrations.

Nango Function Builder local and remote skills are great examples of this. If you want to try it with your favorite coding agent, follow the Nango functions guide to get started.

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.