DEV Community: Sapnesh Naik

Top Zapier and Make alternatives for customer-facing agent integrations in 2026

Sapnesh Naik — Fri, 02 Oct 2026 16:34:05 +0000

Your users can connect third-party apps directly to your SaaS product through customer-facing integrations. For instance, a customer can connect their Salesforce, HubSpot, or Slack account to an AI agent in your product. The agent can then retrieve customer data, respond to events, or perform actions on their behalf.

Zapier and Make are well-established and popular automation platforms. Zapier provides APIs and embeddable components to bring its automation ecosystem to SaaS products. Make focuses on visual workflow automation across thousands of applications. It also supports custom apps, code, and AI agents. I’ve used both Zapier and Make for internal workflow automation, and I’m a fan of both platforms.

But from experience, I know customer-facing integrations require more than connecting a few workflow steps. Your product has to manage a separate authenticated connection for each customer. It needs to run continuous data syncs, react to webhooks, and execute actions reliably. SaaS products should also support custom API behavior and keep integration logic in your existing development and deployment workflow.

That is why you should consider Zapier and Make alternatives built specifically for agents and product integrations.

TL;DR

The right Zapier or Make alternative depends on how you want to build and expose integrations:

Nango: Best suited to teams building customer-facing products and AI agent integrations that need broad API coverage. Nango supports every integration type, including authentication, tool calls, triggers, syncs, API proxying, and execution, in one platform. Teams can start quickly with pre-approved OAuth apps and prebuilt functions, then extend integrations as needed.
Pipedream Connect: This platform suits products and AI agents that want access to a catalog of ready-made API actions and tools, with managed authentication and an API proxy.
Paragon: This platform suits SaaS products that need embedded integration workflows, managed authentication, sync pipelines, actions, and webhooks.
Prismatic: Prismatic suits B2B SaaS teams that want to build integrations using a visual designer.
Merge: Merge suits teams that prefer a unified API for SaaS use cases in categories such as CRM, HRIS, ATS, accounting, ticketing, and file storage and do not have agent-related integration needs.

These platforms solve different parts of the integration problem. Common approaches include prebuilt actions, broader API catalogs, custom integration logic, and embedded workflows. Platforms like Nango cover a wider range of these requirements. The sections below compare these approaches so you can choose based on what your product actually needs.

Zapier and Make alternatives compared

These five platforms take different approaches to product and agent integrations. Nango covers the full integration lifecycle across 1,000+ APIs, while the other platforms focus more specifically on prebuilt actions, embedded workflows, or normalized APIs.

Platform	Best for	How you build	Integration capabilities	Deployment and control	AI / agent support
Nango	Customer-facing products and AI agents that need broad API coverage and quick access to tools, triggers, syncs, and execution	Start with pre-approved OAuth apps and prebuilt functions, then extend in TypeScript when needed	Authentication, tool calls, triggers, syncs, webhooks, API proxy, retries, rate-limit handling, and execution	Nango Cloud, BYOC, or self-hosted; direct API access and control over integration logic	Built for agent integrations with 7,000+ prebuilt tools, MCP, custom tools, and agent SDK support
Pipedream Connect	Products and AI agents that need ready-made API actions and tools	SDKs and APIs using prebuilt actions, triggers, and an API proxy	Managed authentication, actions, triggers, workflows, and API proxying	Managed Pipedream runtime with access to underlying APIs through its proxy	Strong focus on MCP and prebuilt tools for agent actions
Paragon	SaaS products that need embedded workflow automation	Visual workflows with JavaScript, custom connectors, and direct API calls when needed	Managed authentication, workflows, actions, sync pipelines, webhooks, and polling	Managed cloud with self-hosted and forward-deployed options on higher tiers	ActionKit, MCP, and agent-oriented actions
Prismatic	B2B SaaS teams that want visual integration development	Low-code designer or code-native TypeScript SDK	OAuth connections, multi-flow integrations, triggers, sync workflows, monitoring, and custom connectors	Managed cloud with private and on-prem deployment options on higher tiers	Agentic flows and MCP tooling
Merge	SaaS teams that want one normalized API across providers in supported categories	Build against Merge's Unified API and Common Models	Managed authentication, normalized data models, recurring syncs, webhooks, and Authenticated Passthrough	Primarily Merge-hosted, with additional deployment options on higher tiers	Supports MCP and agent tool execution, but its core model is the Unified API

Zapier/Make vs customer-facing integration platforms

Zapier and Make are primarily automation platforms. They work well for internal workflows, such as sending a Slack message when a lead is added to HubSpot. In those cases, the platform usually manages a small number of connections owned by your team.

Customer-facing integrations are different. Your product or AI agent may need to manage authentication, tokens, webhooks, API calls, syncs, and tool execution across hundreds or thousands of customer accounts. That introduces different requirements around reliability, monitoring, permissions, and embedded UX.

Agent integration platforms

Agent integration platforms are designed for AI agents inside your product that need to act and learn across external APIs on behalf of your users.

Instead of handling only authentication or individual API actions, these platforms can support the broader integration lifecycle, including authentication, tool calls, triggers, syncs, API proxying, webhooks, and execution.

For instance, Nango supports quick integrations across 1,000+ APIs and lets teams start with pre-approved OAuth apps and prebuilt functions. Later, you can extend to lower-level API access and custom logic when needed. It also supports Nango Cloud, BYOC, and self-hosting for teams with additional deployment requirements.

Learn more about how Nango is different from embedded iPaaS or other unified APIs.

The platforms compared below take different approaches to solving parts of this problem, from prebuilt actions and embedded workflows to unified APIs.

What to look for in a customer-facing agent integration platform

When integrations are part of your product, the integration platform needs to handle more than authentication and API calls. It should support the full lifecycle of building, running, and maintaining integrations for many customers.

You need to look for the following in your agent integration platform:

Authentication and credential management: The platform should support OAuth, API keys, token refresh, and secure credential storage for each customer connection.
API coverage and direct API access: Providing a broad catalog is useful. But the platform should also let you call unsupported endpoints or work directly with the underlying API when needed.
Custom business logic: You may need provider-specific transformations, mappings, validation, or workflows that go beyond prebuilt actions. So your integration platform should support that.
Syncs, webhooks, retries, and rate limits: The platform should handle background syncs, event-driven updates, transient failures, and provider limits reliably.
Testing and local development: Developers should be able to test integrations before deployment and reproduce failures without debugging directly in production.
Observability and debugging: Logs, execution history, error details, and monitoring are essential when integrations fail for individual customers.
Deployment options: Depending on your security and compliance requirements, you may need managed cloud, BYOC, private networking, or self-hosting. Check whether these features are available in the platform you choose.
Customer onboarding: The platform should let your users connect and configure integrations without leaving your product or requiring manual setup from your team.
Agent-specific controls: For AI agents, consider how tools and actions are exposed, how permissions are scoped per user, and whether the agent can safely access only the APIs and operations it needs.

The best platform gives your engineering team enough control without forcing you to rebuild authentication, execution, and reliability infrastructure yourself.

5 best Zapier and Make alternatives for customer-facing integrations

I tested more than 25 Zapier and Make alternatives and compared what each does well. Based on that research and my experience with customer-facing integrations, I narrowed the list down to five platforms.

Let’s look at where each one fits best, how development works, what the customer-facing experience looks like, and the main pros and cons to help you choose the right fit for your project.

1. Nango: Best for AI agent integrations

Overview

Nango is an integration platform for AI agents and customer-facing products that need to connect with external APIs. It provides authentication, tool calls, triggers, syncs, webhooks, API proxying, and execution across 1,000+ APIs, with a catalog of 7,000+ prebuilt tools.

Best for

Teams building AI agent integrations and customer-facing products that need broad API coverage and support for authentication, tools, triggers, syncs, and execution, with deeper API and deployment control available when needed.

How development works

Teams can get started quickly using pre-approved OAuth apps and prebuilt functions. Nango handles infrastructure such as authentication, token refresh, retries, rate limits, sync state, and execution.

When more control is needed, developers can extend integrations with TypeScript and keep that logic in their existing Git and CI/CD workflows. Coding agents such as Claude Code, Cursor, and Codex can also help research APIs, build integrations, test them against real connections, and deploy them.

Customer-facing experience

Customers can authorize their third-party accounts without leaving your product. Nango’s embedded auth UI can be customized and white-labeled to match your branding.

Pros

Broad API and tool coverage: Nango supports 1,000+ APIs and 7,000+ prebuilt tools. AI agents can use these integrations to retrieve data, call tools, and perform actions without teams building every integration from scratch.
Direct access when prebuilt functionality is not enough: Developers can work with underlying APIs and add provider-specific logic for custom endpoints, mappings, or workflows.
Covers the broader integration lifecycle: Authentication, tools, triggers, syncs, webhooks, retries, rate-limit handling, observability, and execution are available within the same platform.
Flexible deployment options: Nango supports Nango Cloud, BYOC, and self-hosting for teams with security, compliance, or data residency requirements.
Designed for agent integration use cases: Agents can authenticate to user accounts, retrieve and sync data, react to external events, and perform actions across connected APIs. Nango also supports MCP for exposing integrations to agents. Learn more about building AI agent integrations using the Nango Management MCP.

Cons

Built primarily for engineering teams: Teams without development resources may prefer a platform centered more heavily on visual integration building.
No drag-and-drop workflow builder: Nango does not provide a visual workflow-building experience.

2. Pipedream Connect: Best for prebuilt API actions

Overview

Pipedream Connect is a developer toolkit to add third-party integrations to your SaaS products and AI agents. It also provides managed authentication, prebuilt actions and triggers, an API proxy, and access to 10,000+ tools through its MCP server.

Best for

Teams that primarily want to expose ready-made API actions and tools to their SaaS product or AI agent through managed authentication and MCP.

How development works

Developers can use Pipedream’s SDKs and APIs to authenticate users and execute prebuilt actions on their behalf. You can also send custom requests through the Connect proxy when a prebuilt action does not cover your use case.

Pipedream also supports developing and deploying multi-step workflows with its visual builder.

Customer-facing experience

Each end user can connect their own third-party accounts through the Client SDK or Connect Link. Pipedream associates those connections with your application’s users through an external user ID.

Pros

10,000+ tools available for AI agents through MCP: You can expose a large number of app actions to AI agents through Pipedream’s MCP server. You don’t have to define every tool yourself manually.
Managed authentication for end-user accounts: Pipedream handles OAuth and other credential flows for customer connections. So your application does not need to build and maintain those authentication flows independently.
SDKs make it relatively quick to expose integrations inside a product: Pipedream’s SDKs and APIs let teams add authentication, actions, and triggers to customer-facing applications. They don’t have to build the entire integration layer themselves.

Cons

Less deployment flexibility for enterprise requirements: Pipedream Connect runs on Pipedream’s managed infrastructure. Teams that require BYOC or self-hosting for security, compliance, or data residency may need a platform with more deployment options.
Continuous syncs may require additional orchestration: If your product needs long-running data syncs, you may need additional logic for pagination, checkpoints, retries, and sync state.
Prebuilt actions may not cover every provider-specific requirement: When a use case goes beyond the available actions, teams may need to use the API proxy or add more custom logic around the integration.

See our comparison of Pipedream Connect vs. Nango.

3. Paragon: Best for embedded workflow automation

Overview

Paragon is an embedded integration platform for B2B SaaS products. It combines managed authentication, 130+ prebuilt connectors, workflows, real-time actions, sync pipelines, webhooks, and embedded integration UX.

Best for

B2B SaaS teams that want customers to configure embedded integrations and workflows directly inside their product.

How development works

Teams can build event-driven workflows using Paragon’s workflow tooling and extend them with custom logic. Paragon also supports custom connectors and direct requests to third-party API endpoints when its prebuilt connectors do not cover a requirement.

For agent use cases, Paragon provides ActionKit for exposing third-party actions to AI agents.

Customer-facing experience

You can embed and white-label Paragon’s Connect Portal inside your application. So your customers can authenticate and configure integrations without leaving your product. It also offers a headless implementation option.

Pros

Embedded and white-labeled integration experience: Paragon lets SaaS teams place the connection and configuration flow inside their own product. So your customers can set up integrations without openning a separate third-party interface.
Visual workflows with support for custom logic: Teams can build multi-step integration workflows visually. They can also extend them with custom connectors, direct API calls, and JavaScript when the prebuilt components are not enough.
Managed syncs, actions, and agent tooling: Paragon supports recurring data syncs, real-time actions, and agent-facing integrations through ActionKit. This makes it suitable for both traditional SaaS integrations and AI agent use cases.

Cons

Smaller prebuilt connector catalog than broader integration platforms: Paragon currently lists 130+ prebuilt connectors. Teams that need coverage across a much wider range of APIs may have to build more custom connectors themselves.
Self-hosting and forward deployment are enterprise features: Paragon’s self-hosting and forward deployment options are listed under its Enterprise plan. Teams with strict infrastructure or data-residency requirements may need a higher-tier contract.
Its capabilities are split across several product primitives: Paragon separates real-time actions, data syncs, and orchestration across ActionKit, Managed Sync, and Workflows. You may need to work across multiple Paragon products when an integration combines agent actions, syncs, and long-running workflows.
Workflow-centric development may not suit every engineering team: This platform doesn’t suit for the teams that prefer most integration logic to live directly in application code.

4. Prismatic: Best for configurable B2B integrations

Overview

Prismatic is an embedded iPaaS designed for B2B SaaS companies. It supports product integrations built with either a low-code designer or a code-native TypeScript SDK. This platform also provides the infrastructure required to deploy and operate them.

Best for

B2B SaaS teams that want a configurable integration marketplace with visual development options.

How development works

Developers can build integrations entirely in TypeScript using Prismatic’s code-native SDK or assemble them visually using its low-code designer. Both approaches support OAuth connections, configuration, multiple flows, logging, monitoring, and deployment on the same platform.

Prismatic also supports agentic flows that can be exposed to AI agents as MCP tools.

Customer-facing experience

Prismatic’s embedded marketplace lets customers browse, configure, deploy, and manage integrations inside your application. Teams can customize the marketplace branding or build their own integration UI using Prismatic’s APIs.

Pros

Choice between TypeScript and low-code development: Engineering teams can build integrations in code, while other team members can use the visual designer for simpler workflows.
Embedded and customizable integration marketplace: Prismatic lets customers discover, configure, and manage integrations inside your product. You can also customize the experience to match your branding.
Strong extensibility for complex integrations: Developers can create custom connectors, use npm packages, and expose agentic flows as MCP tools when the built-in components are not enough.

Cons

The platform introduces several concepts to manage: Teams need to understand integrations, instances, configuration, marketplaces, and deployment models. It adds complexity compared with simpler integration platforms.
It may be too advanced and complex for basic use cases: If you only need managed authentication and a few API actions, Prismatic may provide more functionality than you actually need.
Pricing can be harder to estimate as usage grows: Prismatic pricing can depend on factors such as deployed integration instances and plan limits. Teams with many customers or integrations may need to model expected usage carefully to understand how costs scale.

5. Merge: Best for unified API integrations

Overview

Merge takes a different approach from the other platforms in this list. Its Unified API provides you with normalized data models across categories such as CRM, HRIS, ATS, accounting, ticketing, and file storage.

Instead of implementing each provider independently, you can build against Merge’s Common Models.

Best for

Teams that prefer integrating once against a normalized API instead of building and maintaining separate integrations for every provider.

How development works

Your application calls the Merge Unified API using the same endpoints and data models regardless of the underlying provider. Merge manages the provider integrations, authentication, recurring data syncs, and normalization.

When you need functionality outside the normalized API, Merge’s Authenticated Passthrough can provide access to provider-specific endpoints.

Customer-facing experience

Your customers can connect their accounts through Merge Link, an embeddable authentication UI. Each connection becomes a Linked Account that your application can access through the Unified API.

Pros

One API can cover many providers within a supported category: Instead of building and maintaining separate integrations for every CRM, HRIS, ATS, or accounting platform, your application can work through a single Unified API.
Common Models reduce provider-specific integration work: Merge normalizes similar objects and fields across providers. This simplifies your application logic and reduces the amount of custom mapping you need to maintain.

Cons

Common Models do not expose every provider-specific feature: If you need functionality that falls outside the normalized schema, you may need to use Authenticated Passthrough or another provider-specific approach.
Coverage is organized around specific integration categories: Merge is a strong fit for areas such as CRM, HRIS, ATS, accounting, ticketing, and file storage. But it isn’t designed to provide the same kind of broad API coverage as a general integration platform.
Some advanced use cases still require provider-specific logic: When customers rely on unique fields, endpoints, or workflows, the Unified API may not support them.
Direct provider API access is gated to higher-tier plans: Authenticated Passthrough is available only on Professional and Enterprise plans. If you need provider-specific endpoints that are not represented by Common Models, accessing them may require moving beyond the Launch plan.

Which type of integration platform do you actually need?

You can’t choose the best integration platform based only on how many integrations it offers. The right choice depends on what your product or AI agent needs to do across external APIs and how much of the integration lifecycle the platform should handle for you.

When your AI agent needs broad integration support to start quickly:

Choose a platform like Nango when your AI agent or customer-facing product needs to work across many APIs and handle more than individual actions. Nango supports authentication, tool calls, triggers, syncs, API proxying, webhooks, and execution across 1,000+ APIs. Teams can start quickly with pre-approved OAuth apps and prebuilt functions, then extend to lower-level API access when needed. It also supports BYOC and self-hosting for teams with additional enterprise requirements.

If your team prefers visual embedded workflows:

An embedded iPaaS such as Paragon or Prismatic can be a good fit when your team wants to design workflows visually and let users configure integrations inside your product. These platforms are useful for embedded marketplaces, multi-step workflows, and low-code integration development.

When you mainly need ready-made actions:

An action or connect platform such as Pipedream Connect can work well when your main requirement is to expose prebuilt API actions and tools to a SaaS product or AI agent.

When you want one schema across multiple providers:

A unified API such as Merge is useful when the providers you support expose similar data models and you want to integrate once instead of maintaining separate implementations for each vendor.

For AI agents, also consider whether you need tool calls, event triggers, background syncs, customer-scoped authentication, direct API access, or control over where integration workloads run. These requirements can quickly narrow down which platform is the best fit.

FAQ

Can Zapier be embedded in a SaaS product?

Yes. Zapier provides embed tools and a Workflow API that let SaaS companies bring Zapier-powered automation into their own products. Users can discover, create, and manage workflows without leaving the application, and Zapier can also handle authentication for connected apps.

Is Make suitable for customer-facing integrations?

Make can support customer-facing automation scenarios, especially if your product has a public Make app that customers use to build their own workflows. However, its core model still centers on scenarios and automation inside Make. It doesn’t provide the same embedded integration infrastructure as platforms such as Paragon, Prismatic, or Nango.

What is the difference between embedded iPaaS and unified APIs?

An embedded iPaaS helps SaaS teams build and expose integrations inside their product. It usually provides workflow builders, managed authentication, embedded configuration, connectors, monitoring, and customer-specific deployment.

A unified API takes a different approach. It maps multiple providers in the same category to a shared schema and common set of endpoints. This reduces provider-specific development, but you work within the abstraction and data model defined by the unified API.

What is the difference between embedded iPaaS and integration infrastructure?

Embedded iPaaS platforms usually focus on visual or low-code workflows, embedded marketplaces, and customer-configurable integrations.

Integration infrastructure is generally more developer-focused. It provides building blocks such as authentication, syncs, webhooks, execution, retries, and observability. And it let developers keep more integration logic in code.

Are there self-hosted Zapier alternatives?

Yes. Some customer-facing integration platforms support self-hosting or private deployment. Nango supports Nango Cloud, BYOC, and self-hosting, while Paragon can run in your own AWS, GCP, or Azure environment. Prismatic also offers private cloud deployments in a customer’s AWS account.

Which Zapier alternative is best for AI agents?

It depends on how your agent needs to interact with external APIs. Nango is suitable when you want custom tools, per-user authentication, direct API access, syncs, webhooks, and MCP on the same platform. Pipedream Connect is better suited when your priority is quickly exposing a large catalog of ready-made actions and tools.

Zapier itself also supports AI agents through its MCP platform and developer tools. So it’s worth comparing the architecture and control you need without excluding Zapier by default.

Do customer-facing integrations require separate OAuth connections for each customer?

Usually, yes. Each customer is connecting their own account. So the platform needs to maintain a separate authenticated connection and credentials for that user or tenant.

For example, Nango manages OAuth credentials separately for each user connection. And Merge creates a separate Linked Account and account token when each end user completes Merge Link.

Best custom tool-call providers for agent API integrations

Sapnesh Naik — Tue, 29 Sep 2026 19:43:20 +0000

TL;DR

Nango: The best custom tool-call provider for agent API integrations. Start with prebuilt tools, customize them with coding agents and native API access, and run them with managed customer authentication. It supports managed execution, backend-hosted handlers, and enterprise deployment options.
Arcade: A fit for teams building Python MCP tools that want managed hosting and per-user authorization through its MCPApp framework.
Pipedream Connect: A fit for teams that want private Node.js actions discovered and executed alongside catalog tools through an API or MCP. Publishing custom tools requires the Business plan.
Paragon ActionKit: A fit for teams keeping custom handlers and schemas in their application while using managed API authentication.
Composio: A fit for SDK-based agents combining catalog tools with application-local functions. Your team hosts the functions; the custom-tools extension is experimental.

Building API integrations for agents often means adapting provider operations to your product’s workflows. You may need customer-specific filters, custom fields, or several API requests behind one tool call. These requirements make control over tool behavior an important part of choosing an integration provider.

For example, a support agent may call a list_urgent_tickets tool to find tickets that need attention. The tool must restrict the search to the customer’s approved project and return up to five tickets with their titles, priorities, and links. To produce that result reliably, it also needs authenticated API access, pagination, and error handling.

Custom tool-call providers differ in how much of this work they handle. Some host your custom code and manage its execution. Others provide authentication and API access while your application runs the handler. This guide compares five providers on that division of responsibility and the control they give you over your tools.

How to evaluate custom tool-call providers

To compare these approaches, follow an operation your agent needs from development through execution. For the ticket-search tool above, that means checking how you implement customer-specific filters, deploy the code, and investigate a failed request. Use these criteria to assess the full workflow:

Coverage beyond the catalog: Can you change an existing tool and add missing endpoints or APIs? Verify the required operations, including whether a custom field can be created, read, and updated, rather than relying on a provider’s logo in the catalog.
Control over custom behavior: Look for editable schemas, provider requests, filters, and outputs. Confirm that your code can use the native API when a packaged action is insufficient.
Tool discovery and schema quality: Check how agents find relevant custom tools and retrieve their current input schemas. Test whether tool names, descriptions, and outputs help the agent select and use the intended operation.
Execution and scale: Establish who hosts custom code and handles retries, rate limits, and logs. Test the expected workload across several customer connections.
Customer isolation: Your backend should select the connection for the authenticated customer. Check how the provider restricts each execution to that connection and its allowed operations. Hiding a tool from discovery must not be your only access control.
Development workflow: Check how engineers and coding agents test changes with development connections and deploy reviewed code.
Enterprise deployment: Determine whether BYOC or self-hosting covers the custom execution runtime, credentials, and logs. Clarify who operates each component.

Best providers for custom agent tool calls

Nango combines a workflow for building custom tools with managed execution and native API access. Arcade and Pipedream also host custom tools, using their respective server and component frameworks. Paragon ActionKit and Composio’s SDK leave custom handlers in your application, so evaluating them also means accounting for the runtime your team operates.

1. Nango

Overview

Nango is the best custom tool-call provider for agent API integrations. It provides 7,000+ prebuilt tools for 1,000+ APIs, with managed authentication and a runtime for custom tools. You can start with an existing action, customize its behavior, or build a new tool for an operation outside the catalog.

To make those changes, use Nango’s integration builder skill with Claude Code, Cursor, or Codex. The coding agent can customize the tool, test it against a real development connection, and deploy it. The source stays in your repository, so your team can review changes and release them through CI/CD.

Once deployed, the tool runs on Nango’s infrastructure with token refresh, configurable retries and rate-limit handling, and execution logs. Set the retry policy in your custom code. Each execution uses a specific customer connection, keeping provider credentials out of the agent. Your application invokes the tool through an API or SDK from any backend language. If your agent uses MCP, agent sessions let your backend choose the connections and tools it can access.

Best for

Teams shipping custom API tools across agents and products that need control over tool behavior, customer authentication, and deployment. Nango supports both adapting prebuilt actions and building new operations, with coding-agent development and infrastructure for running them at scale.

Pros

Start quickly and extend beyond the catalog: The quickstart takes you through authorizing a connection and calling a prebuilt tool. Then customize and test the operations your product needs. Custom tools run on Nango’s infrastructure built for scale and security.
Control over custom behavior: Customize action inputs, outputs, and logic, including per-customer filters. Drop down to native API requests through the authenticated proxy for endpoints or fields a packaged tool does not expose.
Choice of where custom logic runs: Deploy tools to Nango’s runtime, or keep handlers in your own backend and use its authenticated proxy for API requests. Both approaches can use the same customer connections, so existing handlers can work alongside Nango actions.
Auth, tool calls, triggers, and syncs together: A ticket-change trigger can start an agent workflow that invokes your custom tool. A sync can keep a local copy of ticket data ready for searches, reducing API requests during tool execution.
Logs for debugging custom tools: Function and request logs help trace a failed tool call to the underlying API request. Inspect the customer connection, error, and execution duration when investigating a failure.
Deployment control on Enterprise: Deploy Nango in your cloud with Nango-managed BYOC or a self-managed instance. Both require Enterprise, so include that plan requirement when evaluating data residency needs. BYOC lets Nango operate the instance; self-managed deployment leaves operations with your team.

Cons

Customer-specific behavior still needs engineering review and maintenance. Nango’s builder skill helps implement and test that logic against development connections; your team owns the access rules and expected results.

2. Arcade

Overview

Arcade provides a Python framework for custom MCP servers. Each tool you define through MCPApp specifies its inputs and authentication requirements, which Arcade uses when executing the tool for a user.

Best for

Teams building Python MCP tools that want per-user authorization and managed server hosting through one framework.

Pros

Python tool definitions support custom behavior and per-user authorization.
Arcade Deploy hosts compatible MCP servers and registers their tools in the catalog. Gateways let you select which tools to expose to MCP clients.

Cons

The documented arcade deploy path expects a Python MCPApp entrypoint. Check compatibility with your integration codebase before choosing it as your tool execution runtime.

3. Pipedream Connect

Overview

Pipedream Connect lets you publish private Node.js actions through its Components API. You package custom logic in Pipedream’s component format, then invoke the published action for a specific external user. That user’s connected account supplies the credentials for execution.

Best for

Teams that want custom Node.js actions to appear alongside catalog actions in the same discovery and execution interfaces, including hosted MCP.

Pros

Published custom actions appear in Connect’s list, retrieve, and run APIs and are automatically exposed through its hosted MCP server for the relevant app.
Public component source provides implementation examples.

Cons

Publishing custom tools through Connect requires Business, so confirm plan access before evaluating a custom action in Connect.
Custom tools are Node.js components built with the Pipedream Components API. Existing handlers need to fit that format before publication.

4. Paragon ActionKit

Overview

Paragon ActionKit supports custom tools through schemas defined in your application and its authenticated Proxy. Your handler uses the Proxy to make authenticated API requests, then shapes the response for the agent. Because your application defines these tools, it also supplies their schemas to the agent.

Best for

Teams that want authenticated API access while keeping custom tool execution and schemas in their own application.

Pros

The authenticated Proxy lets custom handlers use existing Paragon connections.
A handler can combine provider requests into one operation.

Cons

The documented ActionKit custom-tool path leaves orchestration and response shaping in your application.
ActionKit’s List Tools endpoint excludes these custom tools. Your application must maintain and supply their schemas separately.

5. Composio

Overview

Composio’s custom-tools SDK feature adds application functions to a session’s tool set, with execution in your application process. For custom tools accessed through its MCP gateway, a separate feature connects a server that you host.

Best for

Teams combining catalog tools with application-local functions and accepting responsibility for hosting those functions.

Pros

SDK agents can use catalog tools alongside functions that query your application’s database or internal services, within the same session.
Custom handlers can extend toolkit behavior through authenticated proxy calls.

Cons

Composio’s hosted MCP endpoint cannot execute local callbacks. Using its external MCP path requires you to host a server and resynchronize tool definitions after changes.
Both custom-tool extension paths are documented as experimental.

How to choose and validate a provider

Choose Nango for custom tool calls that need editable behavior, customer-scoped authentication, and a managed runtime. Its prebuilt catalog and coding-agent support help you build the tool, while native API access lets you extend it as requirements change. If part of the logic needs to stay in your backend, use Nango’s authenticated proxy with the same customer connections. BYOC and self-hosting extend that deployment control to the integration infrastructure.

An alternative may fit a narrower requirement. Arcade suits Python MCP tools that need managed server hosting and per-user authorization. Pipedream puts private actions into the same discovery and execution interfaces as its catalog tools. ActionKit supplies authenticated API access for application-owned handlers, while Composio combines local functions and catalog tools in an SDK session. With ActionKit or Composio’s SDK, plan to operate the custom handlers in your own backend.

Validate your choice by implementing one tool that exercises your actual constraints. For the ticket-search example, verify that another customer’s project ID cannot expand access, pagination stays within the request budget, and the response contains only the intended fields.

A successful connection does not establish that every operation will work. Test the required reads and writes with realistic customer roles, OAuth scopes, and field mappings. Repeat after revoking a permission or reconnecting the account. Nango’s connection validation functions can check required permissions during connection creation and reconnect; operation-level tests still matter.

Test authorization through each execution path. Backend proxy handlers must enforce permitted methods and endpoints in trusted code. Nango’s generic session proxy is disabled by default; enabling it permits endpoints beyond the tool allowlist. Keep it disabled for agents that should only call your selected tools.

Choose the data access pattern for the operation. Live reads suit a current ticket status or a record check before a write. Repeated searches across many records may benefit from synced data to reduce request volume and latency, but require an acceptable freshness window and a way to handle revoked access.

After checking the tool’s output and access restrictions, test how it recovers from API failures. Errors should distinguish a disconnected account, insufficient permission, a missing record, and a transient failure, with a clear next step for the agent or user. Confirm that the agent requests reconnection or permission, or stops, when retrying cannot help.

Simulate a provider 429 response and confirm you can see the failed request and retry outcome. For a write tool, also test a timeout after the provider has accepted the change. Since retrying could repeat that change, establish how your application checks the outcome or uses an idempotency key.

Frequently asked questions

When should you customize a prebuilt tool?

Customize a tool when its inputs, outputs, or behavior do not match your product’s requirements. You might need to enforce a customer’s project restrictions, include custom fields, or return fewer fields to the agent. With Nango, you can adapt an existing action and use native API requests for operations outside the catalog.

Do custom tool calls require MCP?

No. You can define a tool in your agent framework and have its handler invoke a Nango action through the API or SDK. If your agent uses MCP, Nango’s agent sessions expose selected actions through that protocol. Choose the interface that fits your application’s execution and access-control requirements.

Can a custom tool call several APIs?

Yes, if the execution environment supports access to each required connection. Nango’s action functions support workflows with multiple API requests. When those requests span providers, authorize each connection separately. Writes across APIs are not transactional, so the tool also needs to handle cases where only some requests succeed.

Should the agent handle pagination itself?

Keep predictable pagination inside the custom tool. With Nango, you can customize an action to fetch up to a specified number of records and return only the fields the agent needs. Include a continuation indicator if more results are available, so the agent can explicitly request them.

Can the same custom tool serve multiple customers?

Yes. With Nango, you can reuse an action across customer connections and store customer-specific settings in per-connection metadata. Your backend selects the authorized connection, and the action applies its project filters or field mappings. Keep those access restrictions in a trusted configuration so agent-supplied inputs cannot override them.

Build your first custom tool with Nango

To try this workflow with Nango, start with a prebuilt tool for an operation your agent needs. Use your coding agent to adapt its behavior and test it against a development connection. Once it returns the expected results and handles failures correctly, deploy it to Nango’s runtime and invoke it from your agent or product. The Nango quickstart walks you through getting started.

Related posts

Best observability tools for AI agent integrations in 2026

Sapnesh Naik — Wed, 23 Sep 2026 13:12:21 +0000

TL;DR

Nango is the best platform for building, running, and observing AI agent integrations. Teams can investigate a failed operation and change the integration that produced it on the same platform.

Datadog, LangSmith, Langfuse, Arize Phoenix, and Braintrust address application tracing or evaluation needs. Use them alongside your integration runtime when you need additional visibility into model behavior, agent control flow, or response quality.

Why AI agent integrations need execution visibility

An agent that takes thirty seconds to create a support ticket might be waiting on the model, retrying an API request, or recovering from an expired access token. A useful observability setup lets you identify which step caused the delay and which customer’s connection was affected.

Finding that cause requires evidence from each stage of the request. An agent observability tool collects and analyzes traces, logs, and metrics across model calls, tool executions, and application services. For agent integrations, this includes the external requests, retries, and customer connection context behind each tool call.

Best AI agent observability tools at a glance

Tool	Best for	Main strength	Main tradeoff
Nango	Building, running, and observing customer API integrations	Auth, tools, triggers, syncs, and execution context	Add evaluation tooling for model quality
Datadog	Existing Datadog monitoring setups	Agent and service trace correlation	API execution stays in your application or integration runtime
LangSmith	LangGraph and LangChain debugging	Agent traces and evaluations	Provider-level detail depends on instrumentation
Langfuse	Teams operating their own tracing stack	Sessions and prompt workflows	Self-hosting includes several storage services
Arize Phoenix	Local trace analysis and evaluation	OpenTelemetry and OpenInference	Production operations and API execution remain your responsibility
Braintrust	Regression testing from production examples	Trace-to-dataset workflows	Enterprise self-hosting retains a hosted control plane

What to look for in observability tools for agent integrations

The tools above cover different parts of an agent’s execution. To choose between them, check what each can tell you about a failed or incorrect API operation.

Start with a tool call such as create_ticket. An agent trace can show its arguments, output, duration, and error. To investigate a provider failure, you also need the HTTP requests inside that call: the response status, failed attempts, and the connection used. A single successful tool span can conceal retries that slow the operation.

Those request details must also identify the affected customer. If one account starts returning 403 Forbidden, you need to isolate that account’s failures. Connection identifiers and integration names help you follow the same customer’s background activity, including a sync that stops updating records when no agent request is running.

Evaluation answers another question: did the agent take the right action? Creating a ticket in the wrong project can produce a successful API response. Deterministic checks, human review, and model-based evaluations help assess correctness using the evidence in your traces.

To make those investigations possible in production, check how much instrumentation you must supply, where telemetry is stored, and how long you can retrieve it. A customer report may arrive weeks after the original run, so retention and deployment requirements should be included in the comparison.

1. Nango

Best for: Teams that need visibility and control for multi-tenant, customer-facing agent integrations.

Nango provides 7,000+ prebuilt tools for 1,000+ APIs, with managed auth and all integration patterns covered: tool calls, triggers, and syncs. For observability, that means you can investigate the connection, the operation an agent called, and the background work that supplies its data within the same integration platform.

You can quickly get started with prebuilt tools, then customize them as needed using coding agents such as Claude Code, Cursor, and Codex. Nango’s runtime handles authentication, retries, rate limits, and execution.

Once an integration is running, Nango records its activity as operations with associated HTTP requests, errors, and custom messages. You can filter these records by integration, connection, function, and status to isolate a customer’s failed tool call or sync. The observability documentation describes these filters. In the GitHub example below, list_issues and update_issue actions appear alongside webhook operations, with execution times and connection identifiers.

If an update_issue action fails, those filters let you locate the run for the affected customer and inspect its HTTP requests and error messages. Because you own the action’s code, you can use that evidence to adjust its behavior or add logging for the next run.

When the fix requires access beyond a prebuilt tool, you can drop down to native API requests through the request proxy. The proxy uses the same customer connections and logs as actions and syncs, preserving that context as you customize the integration.

Coding agents can access execution evidence too. Nango’s Logs MCP tools let compatible clients list and filter operations and retrieve their messages through the Management MCP server. This gives the agent modifying an integration access to its logs during debugging.

For investigations that extend into your application monitoring stack, Nango exports OpenTelemetry traces for action executions, sync executions, third-party webhook executions, and proxied requests. Send them to a compatible collector to use your backend’s dashboards and alerts. Export alone does not guarantee that integration operations appear as child spans of an agent trace; verify context propagation and correlation in your setup.

Enterprise teams may also need control over where the integration runtime and telemetry operate. BYOC provides a Nango-managed deployment in your choice of cloud and region.

Pros

Build, run, and investigate auth, tool calls, triggers, and syncs on one platform.
Start with 7,000+ pre-built tools, then customize functions and native API requests as requirements grow.
Give coding agents access to execution evidence through the Nango Management MCP.
Choose enterprise BYOC or self-hosting to gain control over the runtime and telemetry infrastructure.

Cons

Model response quality and prompt experiments need a separate evaluation tool.

2. Datadog

Best for: Teams that already monitor their application and infrastructure in Datadog.

Datadog Agent Observability collects model, tool, and workflow spans alongside application performance monitoring (APM). This lets teams already using Datadog investigate agent activity within their service monitoring workflow. It also supports evaluations, datasets, and experiments.

To connect agent activity with service traces, send spans through Datadog’s SDK instrumentation or HTTP ingestion API. Its span API includes an apm_trace_id field for that relationship. Your instrumentation still needs to capture the relevant operations.

Pros

Correlates agent spans with application traces.
Includes evaluations and experiments.

Cons

Free and Pro include 15-day trace retention; longer retention adds cost.
Budget for the Datadog products you use across the complete application, including APM and logs.
Agent Observability consumes telemetry; your application or integration runtime remains responsible for executing customer API calls.

3. LangSmith

Best for: Teams building with LangGraph or LangChain that want tracing and evaluations in the same development workflow.

LangSmith captures nested agent traces, groups interactions into threads, and connects trace inspection with evaluation datasets. Its close integration with LangGraph and LangChain suits teams already using those frameworks. It also supports other frameworks and custom applications through SDKs and OpenTelemetry ingestion.

For API integrations, trace inspection helps identify runs where an agent chooses the wrong tool or supplies incorrect arguments. You can use problematic runs as evaluation examples when revising a tool description or routing strategy. Capturing the provider requests inside the tool remains part of your instrumentation work.

Pros

Integrates with LangGraph and LangChain.
Supports evaluations and framework-agnostic tracing.

Cons

Self-hosted and hybrid deployments require Enterprise.
On LangSmith Cloud, base traces have 14-day retention; longer investigation windows require extended retention.
Agent traces need additional execution detail to explain failures inside external API calls.

4. Langfuse

Best for: Teams that want control over their tracing infrastructure while managing prompts and evaluations in the same platform.

Langfuse records traces, nested observations, and sessions, with prompt management and evaluation workflows. Sessions connect multiple conversation turns; metadata helps filter the records.

To connect those observations to API failures, attach customer and integration identifiers so you can find the corresponding execution logs. The details within each tool call depend on your instrumentation, including any spans sent via OpenTelemetry.

You can store and inspect these traces in Langfuse Cloud or operate the platform yourself. Self-hosting gives your team responsibility for the application and supporting storage services.

Pros

Groups traces into conversation sessions.
Offers cloud and self-hosted deployment options.

Cons

Self-hosting requires operating the application services, PostgreSQL, ClickHouse, Redis or Valkey, and object storage.
Cloud billing counts traces, observations, and scores, so one agent run can consume multiple units. Estimate usage against a representative workflow.
Visibility inside custom integration logic depends on the spans your instrumentation emits.

5. Arize Phoenix

Best for: Engineers who want local or self-managed agent trace analysis and evaluation using OpenTelemetry and OpenInference.

Phoenix traces model, tool, and retrieval operations using OpenTelemetry and OpenInference. It supports local analysis, evaluations, datasets, and experiments.

In a local debugging workflow, you can inspect those spans, evaluate selected steps, and compare changes against saved examples. Moving that workflow into production adds requirements for persistent storage, authentication, backups, and availability.

When planning that deployment, distinguish Phoenix from Arize AX. They are separate products, so an Arize AX plan does not describe what a Phoenix installation includes.

Pros

Supports OpenTelemetry and OpenInference instrumentation.
Runs locally for trace inspection and evaluation.

Cons

Your team operates storage, upgrades, and availability when self-hosting Phoenix.
Its source-available code uses Elastic License 2.0, which matters if your requirement specifies a particular software license.
Provider connection management and API execution remain separate responsibilities.

6. Braintrust

Best for: Teams that want production failures to feed directly into agent regression testing.

Braintrust connects production logs with evaluation datasets. Logs and experiments share a data structure, allowing teams to save a failed interaction and test changes against it.

To help identify interactions worth investigating, Braintrust’s September 2026 release added Patterns for recurring issues and Debugger for individual runs.

Once you identify a failure, turn it into a regression case. For integrations, that might be an agent that successfully calls an API but selects the wrong destination account. Preserve the input, tool arguments, and expected outcome, then use that case to compare changes to the agent’s instructions or tool schema.

Pros

Turns production examples into evaluation cases.
Supports scoring, feedback, and OpenTelemetry ingestion.

Cons

Starter includes 14-day retention and Pro includes 30-day retention; plan for the history your team needs.
Its Enterprise self-hosting architecture keeps the data plane in your infrastructure and the control plane hosted by Braintrust.
Scores and processed data are separate usage dimensions to estimate.

How to choose your observability setup

The comparison comes down to the failure you need to explain. For customer-facing API integrations, start with Nango: its runtime and execution logs capture connection issues, provider requests, syncs, and webhooks that affect agent reliability.

Then identify what you need to investigate beyond those operations. Add Datadog for correlation with an existing APM setup, or an agent tracing and evaluation platform for model behavior and tool selection. Each addition should answer a specific question that your integration logs do not cover.

Test the division of responsibilities before committing. Run a small proof of concept in a test environment with three cases:

A provider returns 429 Too Many Requests, and the tool succeeds after retrying. Can you inspect the failed attempt and the total delay?
A tool receives valid arguments for the wrong customer account. Can you find the account context and evaluate the mistake?
A background sync fails before an agent uses its data. Can you connect the stale result to the earlier integration failure?

For each case, check how much custom instrumentation you need and whether an engineer can retrieve the evidence within your required retention window.

Frequently asked questions

What should you record when monitoring AI agent tool calls?

Record the tool name, duration, outcome, customer connection identifier, and a correlation identifier. For external API requests, include HTTP status codes, retry attempts, and provider errors. Capture arguments and results where appropriate, with credentials and sensitive customer data removed. This lets you distinguish incorrect tool use from failed API execution.

Does OpenTelemetry automatically connect agent and integration traces?

OpenTelemetry provides mechanisms for recording and transporting telemetry. Connecting operations across services also requires context propagation. Verify that your services preserve trace context and that your backend maps the incoming spans correctly. Where automatic linking is unavailable, use recorded connection identifiers, operation identifiers, and timestamps to correlate records.

Can LLM observability replace tool call monitoring?

LLM observability helps inspect model inputs, outputs, usage, and quality. Agent integrations also need visibility into authentication failures, HTTP requests, retries, syncs, and webhooks. A platform can display both when it receives the relevant telemetry; confirm that your instrumentation actually captures those operations.

Start observing your agent integrations with Nango

Put these checks into practice with a prebuilt Nango tool. Connect a test account, run the tool, and inspect its execution logs before extending the integration for your application. Follow the quickstart for setup and the observability guide for logs and telemetry export.

Top 5 MCP gateways for AI agents in your product in 2026

Sapnesh Naik — Fri, 11 Sep 2026 18:15:43 +0000

Model Context Protocol (MCP) is an open standard for connecting AI agents to external tools. As MCP adoption has grown, MCP gateways have emerged to manage and govern traffic between agents and MCP servers.

There are two main use cases for MCP gateways:

Internal and enterprise governance: Organizations use MCP gateways to govern how employees’ AI agents access MCP servers. Examples include TrueFoundry, Lunar.dev MCPX, and Microsoft MCP Gateway.
Agents in SaaS products: SaaS companies need to connect customer-facing agents to each user’s third-party accounts, such as Salesforce, Gmail, or Notion. For this use case, a gateway needs to support end-user authorization, isolate credentials between tenants, and prevent credentials from being exposed to the model.

In this article, we evaluate MCP gateways specifically for the second use case: AI agents embedded in your product.

What is the best MCP gateway?

The best MCP gateway depends on your project requirements. Arcade.dev is a strong choice if you need agent-native authentication and tool execution. Composio combines a large catalog of pre-built integrations with managed authentication and tool execution. Pipedream MCP stands out for connecting agents to a broad range of APIs.

However, if your main goal is to give customer-facing agents authenticated access to SaaS APIs, you may not need an MCP gateway. An integration platform like Nango provides pre-built and custom tools with per-user authentication, exposing them to agents over MCP. It removes the need to build, authenticate, and operate underlying MCP servers yourself.

TL;DR

Arcade.dev: An MCP runtime and gateway with a large catalog of agent-optimized tools and built-in end-user authentication. It handles per-user authorization, tool execution, and governance while keeping credentials out of the LLM and MCP client.
Composio: A managed MCP gateway with 1,500+ managed toolkits and support for custom MCP servers behind a single endpoint. However, a May 2026 security incident compromised about 0.3% of its active connections, including more than 5,000 GitHub connections.
Pipedream MCP: A hosted MCP integration layer offering 10,000+ tools across 3,000+ APIs, with managed authentication for connecting end-user accounts.
When to skip a gateway entirely: If your main requirement is connecting each customer’s account to third-party APIs, you may not need a separate MCP gateway. An integration platform like Nango with per-user authentication, pre-built tools, and MCP support can handle the API integration layer and expose those tools directly to your agents.

What is an MCP gateway?

An MCP gateway is a service between AI agents (clients) and the MCP servers they call. It routes MCP traffic through a single governed endpoint instead of connecting each agent directly to individual servers. It applies authentication, access policies, rate limits, and logging.

This service is different from the related components around it. An MCP server exposes tools, resources, or prompts to clients. An MCP registry helps clients discover available servers. Routers and proxies primarily route traffic or provide a common endpoint in front of multiple servers. However, some products add gateway-like policy and governance features.

Also read the distinctions between MCP gateway vs MCP proxy, including when a gateway is not worth operating.

The July 2026 MCP specification also made gateways easier to operate at scale. MCP now supports stateless requests and exposes the method and tool name in HTTP headers. It allows gateways to route, authorize, and rate-limit requests without inspecting the JSON-RPC body.

How we evaluated these MCP gateways

End-user auth, not platform auth: Does your gateway support per-user OAuth for every connected account? Does it provide white-labeling and isolated tokens per tenant, and never expose them to the model? This is the biggest gap in governance-first gateways, which assume the caller is an employee.
Tool governance at agent granularity: Can you control which tools an agent can use for each tenant and require user approval before it performs sensitive actions?
Catalog and custom tools: How many pre-built servers are available, and can your engineers build and deploy custom tools when the catalog doesn’t cover what you need?
Context discipline: Giving an agent a large catalog of tools at once consumes context and can make tool selection less reliable. Look for gateways that can expose only relevant tools dynamically instead of loading the entire catalog into the model’s context. This helps reduce the token and accuracy costs of exposing too many tools.
Protocol fidelity: The gateway should support Streamable HTTP and stateless operation so it can scale horizontally. It should also support the OpenAI tool format alongside MCP because many agent frameworks still do not support MCP.
Deployment and compliance: Check whether the provider offers the deployment model you need, such as SaaS, self-hosted, or BYOC. For compliance requirements, look for SOC 2, BAA availability if you handle health data, and EU data residency.
Pricing legibility: Will you pay per tool call, per connection, or per seat? Model an agent that makes 50 tool calls in one session before you choose.

The 5 best MCP gateways for product-embedded agents

1. Arcade.dev

Overview

Arcade.dev is an MCP gateway and runtime for AI agents, with built-in end-user authorization. It offers more than 8,000 agent-optimized tools. It also lets developers build and deploy their own MCP tools. Arcade MCP Gateways can combine its hosted tools with tools from custom or third-party MCP servers behind a single endpoint.

Best for

Arcade is best for teams building customer-facing agents that need per-user authentication and access to a large catalog of ready-made tools. It is particularly suitable when end-user OAuth and governed tool execution are core requirements.

Pros

End-user OAuth as the default: Arcade runs the authorization flow per user, stores the tokens, and keeps them out of the model and the client.
Custom tools on the same runtime: The arcade-mcp framework lets engineers build MCP servers.
Deployment options for residency: This tool supports managed deployments in your AWS or Azure account, as well as self-hosting with Helm on your own Kubernetes cluster.

Cons

Focused on tool execution: Arcade focuses on tool calls rather than data syncs for RAG, webhook ingestion, or polling-based triggers.
Advanced governance requires Enterprise: Features such as Role-Based Access Control (RBAC), Single Sign-On (SSO), audit logs, and self-hosted deployment are available only on Arcade’s Enterprise plan.
Arcade appears on the consent screen by default: If you want users to see your own brand instead of Arcade during authorization, you need to configure your own OAuth client for each provider and set up a custom verifier route.

Arcade Cloud is US-only, and training is opt-out: The managed Arcade Cloud stores data in the United States. Tool queries, execution inputs, and results may be used as training data and retained for up to five years unless the organization opts out.
Per-call pricing adds up at agent volume: the Team plan bills $0.10 per auth event and $0.01 per tool call, so a session with 50 tool calls costs about $0.50 before the model bill.
Usage-based pricing can add up at scale: The Team plan charges $0.10 per auth event and $0.01 per tool call, on top of a $25 monthly platform fee. At that rate, 50 tool calls add $0.50 in usage charges before authentication and model costs.

For a detailed head-to-head, see Arcade.dev vs Nango.

2. Composio

Overview

Composio is a managed tool and MCP platform that gives AI agents access to 1,500+ integrations. It handles end-user authentication and provides just-in-time tool search. This lets agents find the tools they need without loading the entire catalog into context. Its MCP Gateway can also bring managed tools and custom MCP servers behind a single endpoint, with access controls, dynamic tool selection, and logging.

Best for

Composio is best for teams that want a large catalog of agent-ready integrations with managed end-user authentication and tool execution. It is particularly useful when broad API coverage and just-in-time tool discovery are priorities.

Pros

A large managed catalog: Composio offers 1,500+ integrations reachable through one MCP URL.
Just-in-time tool search: It lets agents search for tools when they need them, instead of receiving the full catalog at once.
Payload retention controls: Its zero data retention control keeps request and response bodies out of Composio’s store, metered per tool call.

Cons

White-label OAuth requires your own provider apps: End users see Composio on the OAuth consent screen. To show your own product instead, you need use your own OAuth app.

Custom tools don’t run on Composio’s hosted runtime: You can write custom tools, but they run inside your application rather than being deployed to Composio. If you want custom tools over MCP, you need to operate your own remote MCP server.
Compliance features add usage costs: A BAA is available on Pro and Enterprise for an additional $0.0003 per tool call. Zero Data Retention is also a paid add-on, costing $0.0001 per tool call and $0.0005 per trigger event.

Important: Composio disclosed a security incident on May 21, 2026. An attacker gained a foothold in an internal agentic tool, escalated through the sandboxed execution environment, and reached an auxiliary credential cache. The incident affected 5,001 GitHub connections, and a cache containing 5,241 API keys was also considered potentially exposed. Composio revoked affected credentials and required customers to rotate their API keys. Teams evaluating the platform should account for both the incident and Composio’s remediation in their security review.

Read the best Composio alternatives to see the alternatives for this platform.

3. Pipedream MCP

Overview

Pipedream MCP is Pipedream’s hosted MCP integration layer for developers building AI applications. This platform gives agents access to 10,000+ tools across 3,000+ APIs. It handles authentication for each end user through Pipedream Connect.

Pipedream also offers a separate MCP gateway, Conduit. It primarily targets internal enterprise use with centralized access policies, SSO, audit logs, and observability.

Workday has announced its acquisition of Pipedream on November 19, 2025.

Best for

Pipedream MCP is best for teams that prioritize broad integration coverage. With 10,000+ tools across 3,000+ APIs and managed authentication for end users, it is particularly useful for agents that need to take actions across many third-party applications.

Pros

A broad catalog: Pipedream offers a broad catalog with managed auth across every app in it.
Per-user connections without building the flow: If a user needs to connect to an account, Pipedream MCP can handle the authorization through a Connect Link. You don’t have to build the connection flow yourself.

Cons

Non-standard tool schemas: Instead of plain JSON schemas, Pipedream has created its own schema for action input with non-standard data types like dynamic and external props. This limits compatibility with agent tooling.
Auth is not white-label: End users see Pipedream on the connection screen. Pipedream’s team has confirmed on its community forum that this holds even when you register your own OAuth client.
Per-user pricing on top of the plan: Connect is $99 per month plus $2 per additional user. So cost scales with your customer count rather than usage.
Roadmap uncertainty: Pipedream has been part of Workday since November 2025. So its long-term direction may increasingly align with Workday’s agent ecosystem instead of customer-facing embedded use cases.

4. Klavis AI

Overview

Klavis AI’s Strata provides a single MCP endpoint for connecting agents to tools across multiple MCP servers.

Strata does not expose every tool definition to the agent at once. It progressively discovers server, action, and tool details as needed. This helps avoid large tool catalogs overloading the model’s context.

Strata can work with Klavis-hosted integrations as well as custom and third-party MCP servers. Teams can self-host this Strata if they want to run the gateway on their own infrastructure.

Best for

Klavis AI is best for teams that need to give agents access to many tools without overloading the model’s context. Strata is useful for discovering tools as needed and combining different MCP servers behind one endpoint.

Pros

Progressive tool discovery: Strata exposes tools as the agent needs them. It doesn’t list the catalog on every request.
White-label OAuth: You can run the flows under your own branding and your own OAuth applications.
Open source and self-hostable: The Strata server runs on your own infrastructure.

Cons

Progressive discovery adds extra steps: Strata reduces context usage by discovering tools in stages. But this means the agent may need several tool calls before it reaches and executes the final action.
You still operate custom MCP servers: Strata can connect to custom and third-party MCP servers. But it does not host those external servers for you. You remain responsible for deploying and maintaining them.
Limited public compliance information: Strata resources do not provide details on certifications such as SOC 2, HIPAA/BAA support, or regional data residency. You need to confirm them with Klavis for enterprise deployments.

5. Docker MCP Gateway

Overview

MCP Gateway is Docker’s open-source solution for orchestrating MCP servers. It acts as a centralized proxy between clients and servers. It handles server lifecycle, routing, authentication, configuration, credentials, and access control. It also provides built-in logging and call tracing.

This gateway runs MCP servers in isolated Docker containers.

Best for

Docker MCP Gateway is best for teams already using Docker that want to run and isolate MCP servers in containers. It is particularly suitable when your team wants to operate the gateway and control how MCP servers are deployed.

Pros

Container-per-server isolation: Each MCP server runs in an isolated Docker container with restricted privileges, network access, and resource usage.
Control which servers are exposed: Docker profiles determine which MCP servers are available through a gateway instance.
Built-in observability: The gateway provides logging and call tracing for MCP tool activity.

Cons

Some enterprise functionality is invite-only: Since MCP Gateway is part of Docker AI Governance, it currently requires access through Docker Sales.
Self-managed deployments require operations work: If you run the gateway directly with Docker Engine, your team is responsible for deploying and operating it.
Profiles work at the server level: The documented profile mechanism determines which MCP servers a client can access. This page does not describe the kind of per-user or per-tool authorization policies offered by some managed gateways.

Do you need an MCP gateway or an integration platform that supports MCP?

MCP gateways govern traffic between agents and MCP servers. But they do not handle all the API integration work behind those servers. You still need to handle OAuth, token refresh, rate limits, pagination, and API-specific behavior. The MCP specification also forbids token passthrough: an MCP server cannot simply forward the token it receives from an MCP client to an upstream API. Therefore, you need a separate layer to manage each customer’s credentials and API access for the agents embedded in your product.

Nango connects your AI agent to 1000+ APIs with 7,000+ pre-built tool calls and managed auth behind each one. You can use the catalog as it ships, then customize what you need with code on infrastructure built for scale. Hundreds of AI companies run it in production.

You need to consider three things for this comparison:

A pre-built catalog: Nango provides 7,000+ tool calls across 1000+ APIs. It supports white-label authentication for OAuth, API keys, JWT, and MCP Auth for external MCP servers. Customers authenticate from your app under your brand, while credentials remain server-side. The agent uses a connection ID instead of credentials.

Enterprise deployment and controls: Each agent session gets its own MCP endpoint, with one connection per integration. You can control the tools available to the agent with allow and deny lists. The nango_tool_search meta tool lets the agent find tools when needed instead of loading the full catalog into context. Nango logs each execution, including requests and responses, and supports OpenTelemetry export. For enterprise deployments, Nango supports SOC 2 Type II, GDPR, HIPAA with a BAA, self-hosting, and BYOC deployments in your own cloud account and region.

Code and developer-first: Nango Functions are written in TypeScript and deployed through the CLI. The AI builder skill works with Claude Code, Cursor, Codex, and other coding agents. The agent can research an API, write the integration, test it against a real connection, and deploy it. Nango used this approach to generate around 200 integrations across five APIs in 15 minutes. The same approach can also support just-in-time integrations, where new integration functionality is built when a customer needs it.

When to use a gateway instead: Nango is not designed to route or aggregate arbitrary third-party MCP servers. If you already have MCP servers and need a central layer for routing and access policies, use an MCP gateway. Fine-grained RBAC for connections shared across multiple users is also still being developed.

Comparison of MCP gateways

Capability	Arcade.dev	Composio	Pipedream MCP	Klavis AI	Docker MCP Gateway	Nango (not a gateway)
Per-user OAuth	Yes	Yes	Yes	Yes	No	Yes
White-label auth	Partial	No	No	Yes	Not applicable	Yes
Pre-built catalog	80+ servers, 7,500 tools	1,500+ integrations	3,000+ APIs, 10,000 tools	~100 integrations	None	1000+ APIs, 7,000+ tools
Custom tools on the runtime	Yes	No	Partial	No	Yes	Yes
Coding agents build tools	No	No	No	No	No	Yes
Tool allow and deny lists	Enterprise	Partial	No	Partial	Yes	Yes
Just-in-time tool exposure	No	Yes	No	Yes	No	Yes
Syncs and webhooks	No	No	Partial	No	No	Yes
Open source	No	No	No	Yes	Yes	Yes
Self-host or BYOC	Enterprise	Enterprise	Partial	Yes	Yes	Yes
SOC 2 / BAA	SOC 2 II / unverified	SOC 2 II / paid add-on	SOC 2 II / confirm	Unverified	Not applicable	SOC 2 II / on request
Pricing model	Per auth event and tool call	Per tool call	Per month and external user	Contact vendor	Free	Per connection

FAQ

What is an MCP gateway and why do you need one?

An MCP gateway sits between your AI agents and MCP servers. It gives you one place to manage authentication, control which tools agents can use, route requests, and log activity. A gateway becomes useful when multiple clients or teams use many MCP servers and need the same policies across them. If one team uses only a few MCP servers it manages directly, a gateway may not be necessary.

What is the difference between an MCP gateway, an MCP server, and an MCP registry?

An MCP server executes tools against one system, such as Salesforce or GitHub. An MCP gateway sits in front of many servers and governs the traffic to them. An MCP registry is a directory that lists servers and doesn’t route requests.

Is an LLM gateway like LiteLLM or Portkey the same as an MCP gateway?

No. An LLM gateway manages requests to model providers, including API keys, costs, and fallbacks. An MCP gateway manages the connection between agents and MCP servers, including tool access and routing. They solve different problems, and you may need both in the same agent architecture.

Are there SOC 2 compliant managed MCP gateways?

Yes. Arcade.dev and Composio are both SOC 2 Type II compliant, and Composio also holds ISO 27001 certification. When comparing providers, look beyond the certification itself. Check what the audit covers, whether you can review the report, and whether the provider offers agreements such as a BAA.

Nango is also SOC 2 Type II compliant and supports GDPR and HIPAA requirements. You can review its compliance information in the Nango Trust Center, and a BAA is available on request. Its runtime is open source, which also lets security teams inspect the code.

How do MCP gateways handle OAuth for end users?

MCP authentication and authentication to the underlying API are separate. Your agent may authenticate with the MCP gateway. However, a customer still needs to authorize access to an application such as Salesforce. The MCP specification does not allow the gateway to simply forward the token it received from the MCP client to that API.

For customer-facing agents, check how the gateway handles these end-user credentials. Tokens should remain on the server, be kept separate for each customer, and only be used when the agent executes a tool on that customer’s behalf. See our guide to secure AI agent authentication.

What is the most scalable MCP setup for embedded SaaS integrations?

For embedded SaaS integrations, use a stateless MCP endpoint and keep each customer connection separate. This lets requests run on any available instance without mixing customer credentials. As you add more tools, expose them only when the agent needs them rather than loading the full catalog into context.

Nango follows this approach with agent sessions. Each session gets its own MCP URL and uses one connection per integration. You can also control which tools are available using allow and deny lists.

Do I need an MCP gateway if my agent only uses a few tools?

Probably not. If your agent uses only a few tools or MCP servers, you can usually connect them directly and manage authentication for each one. A gateway introduces another service to deploy, monitor, and maintain. It becomes more useful as you add more MCP servers or clients and need consistent access policies, credential isolation, and logging across them.

Can AI agents in my product use my customers’ existing MCP servers?

Yes, as long as the MCP server supports an authentication flow your application can use. Nango’s MCP Auth can handle authentication with compatible MCP servers and securely store each customer’s credentials. Your agent can then call the MCP server through Nango using the correct customer connection, without handling the credentials itself.

Conclusion

MCP gateways are useful when you already have MCP servers and need a central place to manage access, routing, and policies. For agents embedded in a SaaS product, another requirement is that each customer connects their own accounts without exposing credentials to the agent.

The five products in this article handle that problem differently. Before choosing one, check its end-user authentication model, tool controls, deployment options, and pricing against your own architecture.

If you need to build and maintain the API integrations behind your MCP servers, an integration platform may be better than an MCP gateway. Nango provides managed authentication and pre-built tools for 1000+ APIs, supports custom tools, and exposes them to agents through MCP. You can try it with the Nango quickstart.

Related reading:

Best webhook infrastructure and management tools for SaaS integrations in 2026

Sapnesh Naik — Fri, 04 Sep 2026 19:27:18 +0000

When your SaaS product connects to the third-party tools your customers already use, such as a CRM, a calendar, or a ticketing system, enterprise deals often require that data move between the two within seconds. If a deal closes in HubSpot, the customer expects your product to reflect it before the next polling cycle runs. Polling every API on a tight schedule is slow and expensive at scale. Webhooks reduce that delay and cost, but they can arrive late, more than once, or not at all.

Webhook infrastructure needs to cover receiving events from third-party APIs and sending events to your customers. Each problem requires a different kind of tool.

TL;DR

Top webhook infrastructure picks for 2026:

Nango: Best for receiving third-party API webhooks, with provider-specific subscription functions, verification, connection attribution, and polling fallback within a broader catalog of 900+ APIs.
Hookdeck: Best for high-volume ingestion of events that already reach a webhook URL, with 160+ pre-configured sources, durable queueing, and replay.
Svix: Best webhooks-as-a-service platform for sending webhooks to your customers; it co-created the Standard Webhooks specification.

Receiving vs. sending: which webhook problem do you have?

Receiving webhooks (inbound) is part of the API integration layer. Your product accepts events from external providers, and each provider defines its own subscription, verification, and delivery rules.

For example, HubSpot configures webhook subscriptions at the app level, so one configuration applies to every customer who installs your app. Google Calendar push-notification channels expire after seven days by default, and you must create a replacement before each one expires. Salesforce’s core REST API exposes no generic record-change webhook, so teams use Change Data Capture, Platform Events, or outbound messaging instead.

Verification also varies by provider. Many providers sign payloads with an HMAC (hash-based message authentication code) secret, but their headers, hash algorithms, and timestamp rules differ. Some use a challenge-response handshake to verify that you control the endpoint. Others provide no cryptographic signature.

A multi-tenant SaaS must then attribute each event to the correct customer connection and handle events that arrive late, more than once, out of order, or not at all. Production systems often pair webhooks with low-frequency polling to reconcile missed changes.

Sending webhooks (outbound) reverses the direction. Your product generates an event and delivers it to endpoints registered by your customers. The delivery layer must fan out events, sign requests, retry failures, and record each attempt. A customer portal lets users register endpoints, manage signing secrets, inspect attempts, and replay failed events. Svix is designed for this model. Outbound services start after your application generates an event, so they do not manage provider subscriptions or attribute incoming events to customer connections.

For a broader view of integration platforms, see best embedded iPaaS platforms for product integrations.

How we evaluated webhook infrastructure tools

At Nango, we work with hundreds of teams that run product integrations in production. We drew these criteria from their incidents and platform evaluations, then tested each product against them with a free account and checked every claim against its official documentation.

Delivery reliability: Webhooks can be dropped, duplicated, or delivered out of order. For one CRM-data team, the resulting gaps in synced data became a critical incident. We compared each platform’s retries, delivery semantics, deduplication, and ordering guarantees.
Burst handling and backpressure: One team’s Attio integration generated bursts that pushed monthly egress costs into tens of thousands of dollars, so events had to be queued and processed in 15 to 30-minute batches. Another team lost a customer to GoHighLevel webhook-processing bottlenecks. We looked at queueing, throttling, and per-integration controls.
Subscription lifecycle management: We checked whether each platform can register, renew, and remove provider webhook subscriptions, including for providers that require one per connected account. Delivery-focused platforms leave this to your team.
Verification and security: Providers use different signature and endpoint-verification schemes. We checked for provider-specific verification, replay protection, and controls that keep payloads out of logs.
Multi-tenant attribution: Every incoming event must be mapped to the correct customer connection. We checked whether each platform does this itself or leaves the routing to your team.
Polling fallback and reconciliation: The production pattern we recommend pairs webhooks for low latency with periodic polling to catch missed events. Several teams cut compute costs by replacing 30-second polling with webhooks and hourly reconciliation. We checked which platforms can poll the provider’s API, since the same pattern underpins reliable two-way data syncs.
Observability and recovery: Teams have cited unclear error messages as a reason for switching platforms. We looked for searchable event logs, replay, alerting, and OpenTelemetry export.
Deployment and compliance: Self-hosting, BYOC, and data residency can decide deals. One prospect made self-hosted webhook forwarding a deciding requirement. We checked each vendor’s deployment options and its SOC 2, GDPR, and HIPAA status. For a deeper review, see top AI agent integration tools for compliance.
Direction coverage: We recorded whether each platform receives webhooks, sends them, or supports both directions.

Best webhook infrastructure and management tools

Nango comes first as our top pick for the inbound use case.

1. Nango

Overview

Nango gives each external API one integration-specific webhook URL and attributes incoming events to the right customer connection. Receiving webhooks from external APIs is one of its core use cases. Nango is a platform for building product integrations as code with coding agents, and its cloud runtime handles authentication, data syncs, tool calls, and webhook processing across a catalog of 900+ APIs. Hundreds of teams use Nango to run product integrations in production.

Best for

Teams that need to receive third-party API webhooks and manage provider subscriptions, connection attribution, code-based processing, and polling reconciliation.

Pros

Provider-side webhook orchestration: Each integration gets a dedicated Nango webhook URL. Webhook support and setup vary by provider within the broader 900+ API catalog. When a provider requires a separate subscription per connected account, event functions can register it after connection creation and remove it before deletion. Scheduled sync functions can renew subscriptions that expire, such as Google Calendar channels.When an event arrives, Nango maps it to the correct customer connection if the payload contains the required identifiers, verifies supported provider signatures when the secret is configured, and records the event in its logs. Real-time syncs combine webhook processing with polling-based reconciliation, and the ignore_if_modified_after merging strategy stops older polled data from overwriting newer webhook updates.
Enterprise-ready and built for scale: Nango handles billions of API requests each month. Webhook and function runs produce detailed logs. Nango can also export webhook, sync, action, and proxy executions as OpenTelemetry traces.Nango is SOC 2 Type II, GDPR, and HIPAA compliant, with a BAA available. Enterprise customers can deploy through BYOC in their own cloud account and region, including the EU, or self-host the Enterprise edition with the same features as Nango Cloud.
Code and developer first: Webhook logic lives in your repository as code functions. You can forward provider events to your application or process them in a webhook function that updates synced records. Nango signs forwarded events and retries failed deliveries to your endpoint. The Nango skill lets Claude Code, Cursor, or Codex write and test this logic against a real connection, and the Salesforce webhook guide walks from subscription registration to event processing. Nango is open source.

Cons

Not a customer-facing webhook delivery service: Nango sends signed webhook notifications to your application, but it provides no customer-facing fan-out or endpoint portal. Pair it with an outbound platform such as Svix when your customers need to manage their own endpoints.

2. Hookdeck

Overview

Hookdeck Event Gateway sits between webhook providers and your application. You create a source per provider and add its Hookdeck URL to the provider’s webhook settings. Hookdeck then verifies supported signatures, applies your filters, queues the event, and delivers it to your endpoint with retries. For outbound delivery, Hookdeck offers a separate Apache 2.0 product called Outpost, also available as a managed service.

Best for

Teams that already manage provider subscriptions but need reliable, high-volume webhook ingestion with spike protection, durable queueing, and replay in front of their handlers.

Pros

160+ pre-configured sources: Hookdeck provides built-in verification for providers such as Stripe, Shopify, GitHub, and Slack. Generic sources support HMAC, basic authentication, and API key checks.
Delivery controls: Hookdeck provides at-least-once delivery, configurable retries, and best-effort deduplication. When a destination reaches its configured rate limit, Hookdeck queues additional events instead of dropping them, provided they remain within the plan’s retention window.
Debugging and monitoring: Full request logs and event tracing show how each event moved through the pipeline. Hookdeck exports metrics to Datadog and Prometheus, and its CLI forwards events to a local development server.

Cons

Starts after the webhook arrives: Hookdeck does not register or renew provider subscriptions, or poll APIs without webhook support. Your team owns that provider-side lifecycle.
No automatic customer attribution: Hookdeck does not know how your application models customers, so you must build the routing that maps each event to the correct customer connection.
Limited retention and US-only hosting: Plans below Growth retain events for three or seven days, and the managed Event Gateway offers no EU data residency.

3. Svix

Overview

Svix is a webhooks-as-a-service platform for the outbound problem: delivering webhooks from your product to endpoints managed by your customers. Its main product, Svix Dispatch, handles fan-out, signing, retries, replay, and endpoint management. Svix also helped create the Standard Webhooks specification.

The core Svix server is open source under the MIT license.

Best for

Teams that need to send webhooks to their customers with reliable retries, ordered delivery, replay, and an embeddable endpoint-management portal.

Pros

Outbound delivery controls: Svix retries failed deliveries with exponential backoff over roughly 28 hours, preserves order on FIFO endpoints, replays events in bulk, and automatically disables endpoints that keep failing.
Customer-facing portal: An embeddable portal lets customers register endpoints, inspect delivery attempts, and investigate failures without contacting your support team.
Compliance and residency: Svix is SOC 2 Type II, HIPAA, and GDPR compliant. It offers data residency in the US, EU, Australia, Canada, and India.

Cons

Provider-side orchestration remains yours: Svix Ingest, a separate product from Dispatch, receives webhooks from external providers, verifies supported signatures, and forwards them to your application. It does not register provider subscriptions, attribute events to customer connections, or poll provider APIs for missed changes. Its Polling Endpoint lets your application poll events stored in Svix, not the external provider.

4. Convoy

Overview

Convoy is a webhook gateway written in Go that supports both inbound ingestion from external providers and outbound delivery to customer endpoints. It moved to Elastic License 2.0 in September 2024 and follows an open-core model, with some features unlocked only by a paid licence key.

Best for

Teams that want to self-host one webhook gateway for both inbound and outbound delivery.

Pros

Both directions in one gateway: Outgoing projects support fan-out, retries, rate limiting, and idempotency keys. Incoming projects verify requests with HMAC signatures, basic authentication, or API keys before routing events to your app.
Straightforward self-hosting: Convoy runs as a Go binary with PostgreSQL and Redis, deployable with Docker or Kubernetes. The project was actively maintained as of August 2026.

Cons

Limits in the community edition: The community edition supports one user, one organization, and two projects. Customer portals, Prometheus metrics, retention policies, and RBAC require a paid licence.
No provider-side orchestration: Convoy does not manage provider subscriptions, poll provider APIs for missed changes, or map incoming events to customer connections. You configure its incoming URL with each provider and build the routing yourself.

5. Hook0

Overview

Hook0 is an open-source webhooks-as-a-service platform for outbound delivery, written in Rust and licensed under the SSPL. Its managed webhook data plane runs in France, inside the EU, and it can also be self-hosted.

Best for

European teams that need customer-facing webhook delivery through an EU-hosted cloud service or a self-hosted deployment.

Pros

Full feature parity when self-hosted: Hook0 provides the same feature set in its self-hosted and managed cloud versions.
Core outbound delivery features: Hook0 supports event-type subscriptions, automatic retries, HMAC-SHA-256 signatures, delivery logs, event replay, and a subscriber portal.

Cons

Outbound only: Hook0 sends webhooks to customer endpoints but does not receive events from third-party providers. Your team must manage the provider-side integration separately.
No Hook0 SOC 2 attestation: Hook0 is GDPR-ready and provides a DPA. Its hosting provider holds ISO 27001 and SOC 2 certifications, but those do not cover Hook0 itself.
Limited self-serve retention: Hook0’s self-serve cloud plans include no more than 30 days of event history.

Webhook testing tools

During development, simpler tools help you inspect payloads and route events to a local server. webhook.site provides a temporary public URL and displays every request it receives. ngrok exposes your local server through a public tunnel, and Webhook Relay forwards events to localhost or a private network through its relay agent. Both also offer production gateway features, but none of these tools manages provider subscriptions, customer-connection attribution, or polling fallback.

Comparison of webhook infrastructure tools

Criterion	Nango	Hookdeck	Svix	Convoy	Hook0
Direction	Receive	Both (receive first)	Both (send first)	Both	Send
Provider subscription management	Via provider-specific functions	No	No	No	No
Multi-tenant connection attribution	When routable	Manual	Manual	Manual	n/a
Polling fallback	Yes (syncs)	No	No	No	No
Queueing and replay	Forwarding retries + polling reconciliation	Yes	Yes	Yes	Retries + replay
Self-host	Enterprise edition (full parity)	Outpost only	Core server (MIT)	Yes (open core)	Yes (full parity)
Compliance	SOC 2 II, GDPR, HIPAA (BAA)	SOC 2 II, GDPR, HIPAA	SOC 2 II, GDPR, HIPAA	SOC 2 Type I, GDPR; HIPAA not publicly claimed	GDPR; no Hook0 SOC 2 attestation; HIPAA not publicly claimed
Pricing model	Tiers + usage	Tiers + per event	Tiers + per message	Flat plans + caps	Tiers + per event

How we applied the criteria

Each cell records what the vendor’s documentation states. Where documentation and marketing pages disagreed, we followed the documentation.

“When routable” means Nango attributes an event to a customer connection when the payload identifies it. “Manual” means your team builds that routing.
Queueing and replay: Nango does not replay stored payloads. It retries forwarded events and reconciles missed changes by polling the provider’s API.
“Full parity” means the self-hosted version includes every feature of the managed service.
“Not publicly claimed” means we found no statement on the vendor’s site, not that the vendor is non-compliant.

FAQ: webhook infrastructure for SaaS integrations

What is the best webhook ingestion platform for SaaS apps?

Nango is the best webhook ingestion platform for SaaS apps that receive events from third-party APIs. A gateway such as Hookdeck starts after the provider sends an event to its public URL, so your team still owns each provider’s subscription and API-specific logic. Nango, by contrast, provides an integration-specific webhook URL and routes events when the payload identifies the relevant customer connection. Lifecycle functions run your registration and cleanup code. Periodic syncs reconcile missed events. If your problem is sending webhooks to your own customers instead, Svix is the better fit.

How do I receive webhooks from APIs that don’t support them?

You cannot receive a webhook from a provider that does not send one. Instead, poll its API on a schedule and persist a cursor or watermark between runs. With Nango, a sync polls at the frequency you define, writes changed records to its cache, and can notify your application after each run. This gives you change notifications without the provider’s original event semantics.

Webhooks vs. WebSockets vs. polling: when should I use which?

Use webhooks when the provider supports them and updates within seconds are fast enough. Use polling when the provider offers no webhooks or you need to reconcile missed changes. Use WebSockets when both systems must exchange low-latency messages over a persistent connection, which few SaaS APIs offer for integration events.

What is a webhook endpoint?

A webhook endpoint is a URL that your application exposes to receive event requests from a provider. In production, it should verify the provider’s signature when one is available, return a 2xx response quickly, and process the payload asynchronously. It should also handle duplicate and out-of-order events safely.

Svix vs. Hookdeck: which one do I actually need?

It depends on the direction of the events. Svix Dispatch sends webhooks from your product to your customers. Hookdeck receives webhooks from providers you have already configured to send events to its source URL. Neither manages provider subscriptions or polling fallback. If you need to receive events from many third-party APIs, Nango is a better fit.

Are there open-source webhook tools I can self-host?

Yes, though most self-hostable webhook services cover outbound delivery only. Convoy uses Elastic License 2.0, with some features behind a paid licence. Hook0 uses the SSPL with full parity between cloud and self-hosted. The Svix core server is MIT licensed, and Hookdeck Outpost is Apache 2.0 for outbound delivery. Nango is open source under Elastic License 2.0, and its Enterprise edition self-hosts with the same features as Nango Cloud.

How do I test webhooks locally?

Use ngrok to expose your local server through a public URL so providers can send events straight to your handler. Use webhook.site to inspect a provider’s real headers and payload before writing the handler. With Nango, coding agents can use the Nango skill to write and test webhook functions against a real connection.

Conclusion

Most webhook platforms begin after an endpoint or provider subscription exists. Third-party API webhooks require more than reliable delivery. Your integration may need to register and renew subscriptions, verify provider-specific signatures, attribute events to customer connections, and poll for missed changes. Nango supports this lifecycle alongside authentication and data syncs across 900+ APIs, and its code-based model lets coding agents help write and test the provider-specific logic. For SaaS products that integrate with many external APIs, Nango is our top pick.

Evaluate each platform against the failures you expect in production: an expiring subscription, a traffic burst, a missed event, and a provider with no webhook support.

Related reading:

Best API integration platforms for engineering teams in 2026

Sapnesh Naik — Fri, 21 Aug 2026 13:20:30 +0000

Our conversations with more than 300 engineering teams evaluating API integration platforms showed a consistent pattern. Teams care about more than how quickly they can ship the first integration. They evaluate control over integration logic, catalog depth, auth handling, reliability at scale, observability, security, and AI agent readiness.

We used those real-world criteria to compare six platforms for building customer-facing integrations: Nango, Merge, Paragon, Composio, Workato, and Apideck.

The differences become clearer when requirements move beyond the happy path: a customer needs a custom field or endpoint, a sync hits production scale, or an enterprise customer requires specific security or data residency controls.

TL;DR

Nango: An API integration platform with a pre-built catalog of 900+ APIs and 6,000+ tool calls, customizable with code. Coding agents build and change integrations, and Nango’s runtime executes them at scale.
Merge: A unified API across nine categories, plus a separate agent tool layer. Both stay inside Merge’s fixed schema and pre-built catalog.
Paragon: An embedded iPaaS built on a visual workflow engine, with separate products for syncs and agent tool calls. Custom tools cannot be deployed to its runtime.
Composio: A hosted catalog of agent toolkits behind one endpoint. Suits internal and personal automation more than customer-facing integrations.
Workato: An enterprise automation platform with a no-code recipe builder. Integration logic lives in its cloud, not in your repository.
Apideck: A pre-built unified API across common business categories. Coverage per category is thin and integrations cannot be extended.

What teams actually compare

Shipping the first integration is rarely where platforms differ most. The bigger differences appear when requirements move beyond what the platform supports out of the box.

A customer needs a Salesforce_Region__c field that the normalized schema drops. A provider adds an endpoint the connector does not expose. An enterprise customer requires data to stay in the EU.

These cases test whether your team can adapt the integration within the platform or has to build around it.

What to evaluate

Five criteria came up repeatedly in the evaluations we saw.

Control over integration logic: Can you read and edit the integration code, or only configure it? Normalized schemas can become limiting when you need provider-specific data. For example, Salesforce and HubSpot contacts share only about five fields out of the box, despite both representing the same type of business object.
Catalog depth: “Supported” can mean a complete integration with pagination and rate-limit handling, or just authentication to an API. Check the APIs and use cases on your roadmap, not only the catalog size.
Reliability at scale: Providers do not guarantee webhook delivery. Stripe does not guarantee event ordering and Shopify states delivery “isn’t always guaranteed”. Ask how the platform reconciles gaps and what happens to a backfill that exceeds an execution limit.
OAuth ownership: Check whose OAuth application your customers authorize and whose name appears on the consent screen. This matters for branding, security reviews, and how much control you have over the authorization flow.
Coding agent support: Check whether coding agents such as Claude Code, Cursor, and Codex can build and modify integrations on the platform. This matters as teams use coding agents to expand their integration catalog without hand-building every connector.

Best API integration platforms for engineering teams

1. Nango

Overview

Nango is an API integration platform with a pre-built catalog for 900+ APIs. This platform was built for engineering teams that need integrations they can customize and run at scale. Integration logic is written in TypeScript and runs on Nango’s managed runtime, with built-in infrastructure for authentication, retries, rate limits, and observability.

Teams can build and modify integrations directly in code or use coding agents such as Claude Code, Cursor, and Codex to do it for them.

Nango is open source and used in production by hundreds of SaaS and AI companies.

Best for

Nango is best for engineering teams looking to ship and scale customer-facing integrations with a large API catalog and prebuilt, customizable tools. It’s ideal for teams that need reliable data syncs and webhooks without sacrificing control over their integration logic.

Pros

Broad catalog you can extend yourself: 900+ APIs and 6,000+ pre-built tool calls, covering OAuth, API keys, JWT, ID-JAG, and MCP Auth. You can add a provider without waiting on a roadmap.
Coding agents build the integrations: Nango provides excellent control over integration logic. Install the builder skill once, and Claude Code, Cursor, or Codex researches the API, writes the integration, and tests it against a real connection. We built 200+ integrations in 15 minutes with this loop.

Runtime built for scale: For reliability at scale, each customer’s syncs and tool calls run isolated and fairly queued on a multi-tenant runtime, with durable checkpoints so a large backfill resumes where it stopped.
Request-level observability: For debuggable observability, every sync, tool call, and webhook produces logs with full request and response details. Logs are exportable over OpenTelemetry on every plan.

White-label auth by default: Your customers authorize your app, not Nango, through a drop-in Connect UI or your own headless flow.
Enterprise deployment and compliance: SOC 2 Type II, GDPR with a DPA, and HIPAA with a BAA, documented in the trust center. Enterprise bring-your-own-cloud runs a managed Nango in your AWS, GCP, or Azure account and region.

Cons

Integrations are code: Teams that want non-technical staff building integrations in a drag-and-drop editor are better served by a visual builder.

2. Merge

Overview

Merge is best known for its unified API, which normalizes integrations into common schemas across categories such as HRIS, ATS, CRM, accounting, and ticketing. Its separate Agent Handler product provides pre-built tools for AI agents over MCP, with authentication, security controls, and observability built in.

Best for

Teams looking to integrate a unified API for SaaS use cases. It’s ideal for teams that just need standardized data models rather than deep custom object access in APIs.

Pros

Fast first integration: Merge has decent catalog depth in popular categories. One schema covers a whole category, so a basic HRIS or ATS read ships in days.
Established catalog: Mature connectors for the common HR, ATS, and accounting systems.

Cons

The schema drops what you need: The common model only holds fields most providers expose. Custom fields require the Professional plan, and custom objects work for Salesforce, HubSpot, and Zendesk Sell only.
You cannot extend a connector: Adding a field, an endpoint, or a new provider means filing a request and waiting.
Your customers authorize Merge: White-label auth is Enterprise-only, so on lower plans the OAuth grant goes to Merge, which introduces a third-party processor into security reviews.
Two products, two contracts: The unified API and Agent Handler are sold separately, and Agent Handler ships no data syncs or webhook ingestion.

For the head-to-head, see Merge.dev vs Nango.

3. Paragon

Overview

Paragon is an embedded iPaaS built around a visual workflow engine, with roughly 130 connectors. Its ActionKit product exposes around 1,000 pre-built actions to AI agents, Managed Sync handles data ingestion for RAG, and Paragraph expresses workflows in TypeScript that parses back into workflow blocks.

Best for

Teams looking to build integrations with prebuilt connectors and low-code visual workflows. It’s ideal for teams that want managed orchestration and embedded configuration rather than owning the integration runtime.

Pros

Permissions travel with synced files: Managed Sync records source access rules across Google Drive, SharePoint, Box, and similar sources, so retrieval respects them.
Embedded configuration UI: Connect Portal lets your customers connect accounts and configure each integration themselves.

Cons

Custom tools cannot reach the runtime: ActionKit serves a fixed catalog. An intent-shaped tool such as a single onboard-customer call has to be chained from pre-built actions, which inflates agent context and hurts tool-call reliability.
Syncs are polling-based: Managed Sync polls on a cadence with a one-minute floor, so agents reading mid-conversation see stale records.
Production features are Enterprise-gated: Per-customer field mapping, SAML SSO, and self-hosting all require the Enterprise plan.
Four products for one integration stack: Workflows, Connect Portal, Managed Sync, and ActionKit are billed and debugged separately.

For the head-to-head, see Paragon vs Nango.

4. Composio

Overview

Composio is a hosted catalog of agent toolkits reachable through one endpoint, with managed auth for the supported apps. Its catalog listed 1,089 toolkits in August 2026, exposing more than 20,000 individual tools.

Best for

Composio is best for engineering teams building AI agents for internal company and personal automation across a large catalog of agent-ready tools. It’s ideal for teams that prioritize managed authentication and action execution over deeply customizable customer-facing integrations and data syncs.

Pros

Large catalog, quick to wire up: One hosted endpoint reaches the full toolkit list, with adapters for common agent frameworks.
Detailed execution logs: Composio provides debuggable observability through request and response payloads available via its API.

Cons

Security incident history: Composio’s security posture has been shaky. In May 2026, an attacker reached Composio’s execution sandbox and the credential cache behind it. Around 5,001 GitHub OAuth tokens and 5,241 API keys were compromised or likely exposed, and every customer was made to rotate API keys.
Custom tools run in your process: Session-bound custom tools execute in your application, not Composio’s sandbox, so you provide the hosting, scaling, and isolation.
Closed runtime and gated governance: The public repository holds SDKs only. RBAC, audit trails, private deployment, and BAA support depend on the enterprise tier.
Pricing reset in August 2026: A restructure effective August 15, 2026 cut tool-call allowances and raised overage rates sharply, with existing customers grandfathered only through December 31, 2026.

For the head-to-head, see Composio vs Nango.

5. Workato

Overview

Workato is an enterprise automation platform built on a no-code recipe builder with 1,200+ connectors. Its Enterprise MCP offering exposes those recipes to agents as tools, and its embedded tier white-labels the builder inside your product through iframes.

Best for

Internal IT and operations teams looking to automate complex internal processes across a broad app ecosystem with a visual, low-code platform. It’s ideal for organizations that prioritize centralized governance, security, and compliance over developer-owned, customer-facing integration code.

Pros

Broad compliance coverage: SOC 1 and SOC 2 Type II, ISO 27001, ISO 42001, and HIPAA with signed BAAs.
Per-user identity with approvals: Verified User Access runs each action as the actual end user, and high-stakes actions can be routed to Slack or Teams for sign-off.

Cons

Platform-managed integration logic: Control over integration logic centers on recipes managed within Workato rather than code in your application repository. Workato supports versioning and CI/CD through its own platform and lifecycle tools.
Cloud-only with negotiated capacity: The MCP server runs only in Workato’s cloud, and recipe concurrency is capped at 30 jobs unless you ask support to raise it.
No durable sync primitive: Recipes handle triggers and batches, not incremental syncs with pagination, change detection, and deduplication. The embedded builder also ships as an iframe, which makes automated testing difficult.

6. Apideck

Overview

Apideck provides unified APIs across categories including CRM, HRIS, accounting, ATS, file storage, and e-commerce. It normalizes provider data into common schemas, while Vault handles authentication and provides an embeddable interface for customers to connect their accounts.

Best for

Teams looking for accounting integrations through unified APIs and an embeddable connection UI. It’s ideal for standard read-and-write use cases where most requirements fit normalized data models rather than deeply customized integration logic.

Pros

Broad category coverage: Covers multiple business software categories behind normalized APIs.
Embeddable Vault UI: Provides a customizable interface for customers to connect their accounts. Full white-labeling is available on the Enterprise plan.

Cons

Uneven coverage across categories: Connector and endpoint coverage varies by category and provider.
Limited control over integration logic: Custom Field Mapping can extend normalized models, and the Proxy API provides access to endpoints outside them. However, engineers do not directly own and modify the underlying connector logic as code.
Provider OAuth setup can still be required: Apideck provides auth handling for OAuth flows, token refresh, and credential management. Production integrations can still require teams to register and configure their own OAuth applications with individual providers.

Comparison of API integration platforms

Criterion	Nango	Merge	Paragon	Composio	Workato	Apideck
Catalog	900+ APIs	~220 connectors	~130 connectors	1,089 toolkits	1,200+ connectors	~160 connectors
Edit integration logic	Yes, in code	No	Workflow blocks	No	No	No
Add a provider yourself	Yes	No	Yes (custom builder)	No	Partial	No
Coding agents build integrations	Yes (AI skills)	No	No	No	No	No
Custom tool calls on the runtime	Yes	No	No	In your app	Recipes only	No
Data syncs	Durable, incremental	Category-scoped	Polling	No	No	Pass-through
Webhook ingestion	Yes	Partial	Yes	Triggers only	Rate-limited	Partial
End user authorizes	Your app	Your app (production)	Your app	Your app/Session	Your app	Your app (production)
Observability	Request-level, OpenTelemetry	Enterprise APIs	Basic	Partial	Comprehensive	Basic
Deployment	Cloud, self-host, BYOC	Cloud only	Cloud, paid self-host	Cloud, paid self-host	Cloud only	Cloud only
Open source	Yes	No	Partial	Yes (SDK/Core)	No	No

How we applied the criteria

We checked each platform against its documentation, pricing pages, changelogs, and public repositories. For implementation details, we prioritized technical documentation over marketing pages.

Catalog numbers use each vendor’s own unit. A Composio toolkit and a Merge connector are not equivalent, so their counts are not directly comparable.

Where we could not verify a capability through documentation or testing, we report only what we could confirm.

FAQ

What is the best API integration platform for engineering teams?

Nango is the broadest fit for engineering teams building integrations into their product. It combines a pre-built catalog of 900+ APIs and 6,000+ tool calls with the ability to change any integration in code, and coding agents like Claude Code, Cursor, and Codex do that work on the platform. Auth, tool calls, data syncs, and webhooks run on one runtime with request-level logs.

What is the difference between a unified API and an embedded iPaaS?

A unified API gives you one normalized schema across a category, so Salesforce and HubSpot look identical to your code. An embedded iPaaS gives you a workflow builder to compose integrations one at a time inside your product. Five ways to build product integrations compares both against building in-house.

Can AI coding agents build API integrations on these platforms?

Nango is the only platform in this comparison with a builder skill that lets coding agents such as Claude Code, Cursor, and Codex research an API, write the integration, test it against a real connection, and deploy it to the platform’s runtime.

Merge Agent Handler can connect coding agents to pre-built tools over MCP and supports custom MCP servers. However, it does not provide the same coding-agent workflow for authoring, testing, and deploying new integration logic to Merge’s runtime.

Which API integration platform handles custom fields and custom objects?

Platforms with full API access handle them directly, because you read whatever the provider returns. Nango maps one to one with the provider API, so custom fields and custom objects come back in the response. Unified APIs handle them through field mapping or passthrough requests, with coverage that varies by connector.

Which API integration platforms can run in the EU or in our own cloud?

Nango is the only platform in this comparison that offers free self-hosting, and its Enterprise bring-your-own-cloud option runs a managed deployment inside your own AWS, GCP, or Azure account and region. Paragon and Composio document self-hosting on paid plans. Merge, Workato, and Apideck are cloud-only, so EU residency depends on what each vendor offers in its own regions.

Do I need a platform, or should we build integrations in-house?

Building in-house makes sense with a small number of integrations and permanent capacity to own maintenance. Most of that cost lands after the first version ships, in provider changes you did not choose. Operating auth for 900+ APIs, we found that 16% of commits to our provider configurations are fixes for changes providers never announced.

Conclusion

Run the evaluation on your hardest integration rather than your easiest. Add a custom field, call an endpoint the platform does not cover, revoke a token mid-sync, then read the logs and judge whether you could have debugged it without a support ticket.

Nango is the broadest option here: a catalog of 900+ APIs and 6,000+ tool calls, customizable in code by your coding agents, on a runtime built for scale with white-label auth, syncs, webhooks, and enterprise deployment. Merge and Apideck fit fixed-schema reads inside their categories, Paragon fits permissions-aware retrieval and visual workflows, Composio fits internal agent automation, and Workato fits non-technical enterprise operations.

To try it on one of your harder integrations, start with the Nango quickstart.

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: