DEV Community: Nango

Best social media and ads API integration platforms for AI agents (2026)

Sapnesh Naik — Wed, 28 Oct 2026 14:25:14 +0000

TL;DR

This guide compares social media and ads API integration platforms for developers who connect customers’ Facebook, Instagram, LinkedIn, Meta Ads, and Google Business Profile accounts to a SaaS product or AI agent.

Nango fits the most use cases: social, ads, CRM, and 1,000+ other APIs on one platform, with pre-built tools agents can call and full control in code. The other four fit narrower niches.

Nango: The broadest option. 10,000+ pre-built tools across 1,000+ APIs, including Facebook Page and LinkedIn posting tools and a Meta Ads MCP connection. Start with Nango’s pre-approved OAuth apps or bring your own, and coding agents can extend any tool.
Ayrshare: A social publishing and engagement API across 14 networks. Ads are limited to boosting Facebook and Instagram posts, and customers authorize Ayrshare’s app.
Composio: A hosted tool catalog for agents with social and ads actions. It has no social or ads event triggers, no Google Business Profile toolkit, and no token export.
Zernio: Social publishing, inbox, and ads in one vendor-managed API. Customers connect through Zernio’s apps, with one shared rate limit and no per-tool agent scoping.
Unified.to: A pass-through unified API with normalized ad campaigns and reports. Social writes are patchy, and you build change detection yourself.

Why use an integration platform for social media and ad integrations

A marketing agent can draft a good Instagram caption. But to actually publish, it needs access to customers’ social media accounts.

Meta Ads, Instagram, Facebook, LinkedIn, and Google Business Profile each have separate APIs, with their own authentication, permissions, and app review. Connecting a Facebook Page for publishing doesn’t grant access to Meta’s advertising APIs. A LinkedIn posting integration doesn’t cover LinkedIn ads.

Platform	Operations to evaluate	Key access requirements
Meta Ads	Read ad accounts and insights; create and manage campaigns, ads, budgets, and ad sets	Marketing API permissions (`ads_read`, `ads_management`), app review, and often business verification
Instagram	Publish images, carousels, and Reels; check publishing status; retrieve insights	A professional account and Instagram publishing permissions
Facebook	Discover Pages; publish posts, photos, and videos; schedule posts; manage comments	Page permissions such as `pages_manage_posts`; personal-profile publishing isn't supported
Google Business Profile	Manage locations, publish updates, reply to reviews, update hours, and retrieve performance data	Google Business Profile API access approval and the `business.manage` scope
LinkedIn	Publish member and organization posts; manage comments; retrieve analytics; manage ads	Separate permissions for organization management and advertising

How to evaluate a social media and ads API integration platform

We evaluated each platform on the workflows a marketing agent or social SaaS product runs in production:

Coverage per operation: Check the exact operations you need, such as Instagram Reels, Facebook multi-photo posts, LinkedIn organization posts, and Google review replies. Support for a network doesn’t mean support for every operation.
Paid ads depth: Boosting an existing post is different from creating campaigns, ad sets, and budgets. Check reporting fields, attribution windows, and time zones too.
OAuth app options: Pre-approved apps let customers connect before you finish provider app review. Your own app puts your brand on the consent screen and keeps connections with you if you switch vendors. The best platforms offer both.
Asset and agent scoping: Customers often manage many Pages and ad accounts. Each agent should see only the assets and tools its customer approved.
Failure handling: A post or budget change must not run twice after a timeout. Check retries, duplicate protection, and final status checks.
Fresh data and events: Check for syncs and webhooks on new comments, reviews, and post status, beyond live reads.
Custom operations: When a feature isn’t built in, check whether you can build it yourself and where that code runs.
Integrations beyond social: Most marketing products also need CRM, analytics, or commerce data. Check whether the same platform covers them.
Deployment and compliance: Check where tokens and data live, and whether you can run the platform in your own cloud.

The best social media and ads API integration platforms in 2026

We compared five platforms on the marketing assistant scenario above, using the evaluation criteria. To support it, a platform needs reliable API access, customer-specific permissions, and controls that prevent unauthorized actions.

1. Nango

Nango connects AI agents to 1,000+ APIs with 10,000+ pre-built tools. It covers every integration type a marketing agent needs: auth, tool calls, triggers, and syncs. You can also customize pre-built tools with coding agents such as Claude Code, Cursor, and Codex.

For social and ads, the catalog includes Facebook Page actions and syncs, such as create-page-post, create-page-photo, create-scheduled-page-post, and list-post-comments, plus LinkedIn actions for member and organization posts, comments, and likes. Nango also connects customers to Meta’s Ads MCP server and handles auth for Instagram, Google Business Profile, Google Ads, TikTok Ads, Microsoft Ads, Pinterest, and YouTube.

Best for

Any social media or ads integration for your agent, alongside 1,000+ other APIs. Start with pre-built tools, customize them in code, and run them in your own cloud.

Pros

Social, ads, and CRM on one runtime: An agent can read Meta Ads insights, publish to a Facebook Page, and pull CRM data from HubSpot or Salesforce through the same auth, execution, and logging. You don’t add a second vendor when customers ask for CRM-attributed results.

Meta Ads through Meta’s own MCP server: Each customer’s Meta ad account connects to Meta’s Ads MCP server for campaigns, ad sets, ads, insights, and catalogs. The same connection model works with the Marketing API through the proxy, so reporting and campaign changes use one customer authorization.
Build custom operations with coding agents: Nango’s skills for coding agents help Claude Code, Cursor, and Codex research provider APIs, generate integration functions, test them against real connections, and deploy them.

/building-nango-functions-locally Build a Nango action for the facebook integration
that publishes a multi-photo Page post: upload each image unpublished, then create
the feed post with attached_media. Add retry protection and return the post ID.

Scoped agent access: Agent Sessions limit each agent to one customer’s connections and an allowlist of tools, with an expiry you set. Your application controls approvals for posts and budget changes, and provider credentials never reach the model.
Pre-approved OAuth apps, or bring your own: Start with Nango-managed OAuth apps for popular providers like Facebook, Google, and LinkedIn, so customers can connect before you register an app or wait on provider review.
Fresh context and events: Syncs keep Page posts, scheduled posts, and videos current, and webhooks trigger your agent when something changes. The proxy reaches any endpoint without a pre-built tool, including Google Business Profile hosts via Base-Url-Override.
Per-customer debugging: Logs filter by integration, connection, and function, so support can see why one customer’s post or budget change failed.

Enterprise-ready deployment: Nango is source-available (Elastic License 2.0) and SOC 2 Type II certified. Run it on Nango Cloud, or in your own cloud and region with BYOC or self-managed deployment on Enterprise.

Cons

Extra scopes and your own branding need your own app: Nango-managed apps can show Nango on the consent screen. For consent under your own brand you can bring your own OAuth keys. Nango’s app registration guide walks through the requirements.

2. Ayrshare

Ayrshare is a unified social media API for publishing, analytics, comments, DMs, and Google Business Profile reviews across 14 networks. Each of your customers is a User Profile that links accounts through an Ayrshare-hosted page, or through an embedded Connect widget with the $300/month Max Pack add-on. A Meta-only Ads add-on boosts Facebook and Instagram posts, and a hosted MCP server exposes 33 fixed tools.

Best for

SaaS products that schedule posts and manage engagement across many social networks, and only need Meta post boosts on the ads side.

Pros

Network-specific publishing formats: Instagram Reels, Stories, and carousels, plus Facebook Reels, Stories, and multi-image carousels, through one post call.
Engagement in one API: Comments, DMs, Facebook and Google Business Profile reviews, and post history, including posts not made through Ayrshare.
Signed webhooks: HMAC-signed webhooks with retries cover post status, account link changes, messages, comments, and mentions.

Cons

Customers authorize Ayrshare’s app, not yours: LinkedIn consent names Ayrshare, and Facebook Page admins see “Published by Ayrshare” on posts. There’s no documented bring-your-own Meta, LinkedIn, or Google app, and no token export.
The MCP server can’t be locked to one customer: Every connection uses the account API key, which can reach every User Profile under it. A per-call profile argument overrides the default, and there’s no tool allowlist, so a prompt-injected agent could reach another customer’s accounts.
No escape hatch for missing operations: There’s no passthrough or proxy for raw provider calls, so any Meta, LinkedIn, or Google field Ayrshare doesn’t wrap is out of reach.
Ads are Meta boosts, not campaign management: The Ads API covers Facebook and Instagram only, with no campaign creation, no budget edits after a boost, and no LinkedIn or Google Ads.
Social-only, with stacked add-ons: There’s no CRM or commerce data to join results against. Embedded linking ($300/month), Ads ($100/month), and messaging are each billed on top of the base plan.

3. Composio

Composio is a managed tool-calling platform for AI agents, with 1,600+ toolkits reached through MIT-licensed SDKs or a per-user MCP endpoint. For social and ads, it has pre-built tools for Facebook Pages, Instagram, LinkedIn, Meta Ads, Google Ads, TikTok Ads, Pinterest, and YouTube. Credentials are stored and tools run in Composio’s cloud.

Best for

Internal or personal agents that call ready-made social and ad-platform actions on request, without reacting to social events or owning customers’ tokens.

Pros

Pre-built ads actions: Meta Ads and Google Ads toolkits include campaign, ad set, and budget actions plus insights and reporting, so an agent can act on ads from the start.
Session-level tool scoping: Sessions can allow or deny toolkits and specific tools per user, and the filters are enforced when a tool runs.
Quick start with managed OAuth: Composio-managed apps cover Facebook, Instagram, LinkedIn, Google Ads, TikTok Ads, and Pinterest for testing.

Cons

No social or ads event triggers: The Facebook, Instagram, LinkedIn, Meta Ads, Google Ads, and TikTok toolkits list zero triggers. New comments, mentions, and ad events have to be polled with read tools, and there is no data-sync primitive.
No Google Business Profile toolkit: An agent can’t post updates or reply to reviews. Custom integrations are Enterprise-only, and SDK custom tools run inside your own app.
You can’t export customer tokens: Since June 2026, the API no longer returns access or refresh tokens, even when you bring your own OAuth app. Moving to another platform means every customer reconnects.
Managed social apps hit limits in production: The managed Instagram app lacks Meta’s comment-management permission, so comment replies fail until you bring your own approved app. The shared LinkedIn app has strict rate limits, and Meta Ads and LinkedIn Ads have no managed OAuth at all.
Closed runtime with a recent breach: Composio’s May 2026 security incident exposed about 10,242 credentials and forced customers to rotate keys and have users reconnect. Self-hosting and VPC deployment are Enterprise arrangements.

4. Zernio

Zernio, renamed from Late (getlate.dev) in March 2026, is a unified API for social publishing, inbox, analytics, and paid ads. Its Ads API, launched in early 2026, covers Meta, Google, LinkedIn, TikTok, Pinterest, X, OpenAI, and Reddit Ads. It also ships a hosted MCP server, and customers connect through Zernio’s own platform apps.

Best for

Social media tools and agencies that want posting, an inbox, and basic ad management from one vendor-managed API.

Pros

Organic and paid in one API: Publishing, Google Business Profile posts and reviews, and ad campaign creation share one schema, with the most depth on Meta and Google Ads.
Simple per-account pricing: Two accounts are free, then each connected account is billed on a graduated rate. Ads cost $0.01 per active ad after the first 500, with no cut of ad spend.
Built-in multi-tenant setup: One profile per customer, API keys scoped to a profile, and webhooks routed per profile.

Cons

Customers authorize Zernio’s apps, not yours: Zernio documents no bring-your-own OAuth app and no token export. Quotas are shared across Zernio’s customers, every Google Ads account runs on one Zernio developer token, and features depend on Zernio’s own app approvals. Snapchat is unavailable because Snap hasn’t approved Zernio’s app.
Uneven ad editing: After launch, you can edit targeting and creative only on Meta and TikTok. Elsewhere, you delete and recreate the ad. Campaign-level budget and bid-strategy edits are Meta-only.
One rate limit for all your customers: 600 requests per minute applies team-wide, whether you have 3 or 2,000 connected accounts. Scoped keys add no throughput.
Coarse agent scoping: A profile-scoped key isolates one customer, but there’s no per-tool allowlist, so the agent sees the full endpoint surface. You can’t add custom operations in code, and the only raw passthrough is read-only Google Ads queries.
Social-first and cloud-only: CRM support is limited to syncing HubSpot contacts, and you can’t add an API outside Zernio’s roughly 30 platforms. There’s no self-hosted or BYOC option.

5. Unified.to

Unified.to is a real-time, pass-through unified API with 1,790+ integrations across 37 categories, including a Social Media API (20 integrations) and an Advertising API (42 integrations). Every call runs live against the source API, and Unified stores no end-customer data. A hosted MCP server exposes each connection’s unified operations as agent tools.

Best for

Teams that want one normalized schema for ad campaigns and reports across many ad networks, with live reads and no vendor-stored data.

Pros

Campaign management across major ad networks: Meta, Google, LinkedIn, and TikTok Ads support normalized create, update, and delete on campaigns, ad sets, and ads, plus a unified report object.
No data custody: Every request is live and nothing rests on Unified’s side, which simplifies sub-processor reviews. Regions are US, EU, and AU.
Per-connection MCP tool controls: The hosted MCP server can restrict tools, narrow permissions, and hide sensitive fields for each connection.

Cons

Patchy social writes: There is no comments object, so an agent can’t reply to Facebook or Instagram comments through the unified model. Instagram posts are create-only, LinkedIn posts can’t be updated, and TikTok and YouTube are read-only.
You build change detection yourself: No webhooks are listed for Google Ads, LinkedIn Ads, Facebook, Instagram, or Google Business Profile. Meta Ads has polling-based virtual webhooks. To keep agent context fresh, you build the polling, storage, and backfill.
One MCP server per connection: An SMB customer with Meta Ads, a Facebook Page, Google Business Profile, and a CRM means four separate MCP endpoints for one agent. Connection tokens don’t expire, and revoking one means deleting the connection.
No custom logic in code: Beyond the unified models, you get raw fields and a passthrough proxy. There’s no hosted runtime for multi-step operations like a multi-photo post.
Every agent call is billed: Plans start at $750/month for 750,000 API calls, and every MCP tool call and data-carrying webhook delivery counts toward that quota.

Side-by-side comparison

Capability	Nango	Ayrshare	Composio	Zernio	Unified.to
Organic publishing	Yes (Facebook, LinkedIn pre-built; others in code)	Yes (14 networks)	Yes (Facebook, Instagram, LinkedIn, YouTube)	Yes (15+ networks)	Partial (Instagram create-only, no comments)
Ad campaign management	Yes (Meta Ads MCP; Google Ads in code)	No (boost posts only)	Yes (Meta, Google, TikTok Ads)	Partial (8 networks, uneven edits)	Yes (Meta, Google, LinkedIn, TikTok)
Google Business Profile	Partial (auth and proxy; actions in code)	Yes (posts, review replies)	No	Yes (posts, reviews)	Yes (posts, review replies)
Agent tools and MCP	Yes	Yes (33 fixed tools)	Yes	Yes	Yes (one server per connection)
Scoped agent access per customer	Yes (Agent Sessions, tool allowlists)	No (account key)	Yes (session allowlists)	Partial (profile keys, no allowlist)	Partial (one connection per server)
Custom operations in code	Yes (TypeScript functions)	No	Partial (runs in your app)	No	No (passthrough only)
Syncs and webhooks	Yes	Partial (webhooks, no syncs)	No (no social or ads triggers)	Partial (Zernio events)	Partial (polling, Meta Ads only)
CRM and other APIs	Yes (1,000+ APIs)	No	Yes	Partial (HubSpot contacts)	Yes
Pre-approved and own OAuth apps	Yes (both, with token export)	Partial (Ayrshare's apps; own app on X only)	Partial (both, no token export)	Partial (Zernio's apps only)	Partial (own app; shared apps for testing only)
Self-host or BYOC	Yes (Enterprise)	No	Partial (Enterprise)	No	Partial (Enterprise)

How to choose

If you need social, ads, CRM, and other APIs for an agent or product, with full control in code: pick Nango.
If you only publish and engage across many social networks, and Ayrshare’s name on the consent screen is fine: pick Ayrshare.
If you’re building an internal agent that calls ready-made social and ads actions on request: pick Composio.
If you want posting, an inbox, and basic ads from one vendor-managed API: pick Zernio.
If you need normalized ad campaign data across networks and will build change detection yourself: pick Unified.to.

FAQ

What is the best social media API for developers building AI agents?

Nango is the best fit when an AI agent or SaaS product acts across social, ads, and business systems. It combines pre-built Facebook and LinkedIn tools, a Meta Ads MCP connection, scoped Agent Sessions, and custom functions that coding agents build. Ayrshare and Zernio fit products that only publish to social networks, and Composio fits agents that call actions on request without event triggers.

How do I get Meta Ads API access for my customers’ ad accounts?

You need a Meta app with Advanced Access to ads_read or ads_management and a verified business, either your own app or a vendor’s app you rely on. With your own app, customers authorize your product and the access stays with you. Nango’s Meta setup guide walks through registering it.

Is a Facebook connector enough for Meta Ads?

No. Facebook Page publishing uses Page permissions such as pages_manage_posts. Reading insights and managing campaigns use the Marketing API with ads_read and ads_management, which need their own review. With Nango, you connect both through the Facebook and Meta Marketing API integrations.

Does Instagram have an API for posting?

Yes, for professional accounts only. The Instagram API publishes to Business and Creator accounts through a create-container, check-status, publish flow. Meta retired the Basic Display API for personal accounts in December 2024, so customers need to switch a personal account to a professional one first.

Conclusion

Dedicated social APIs are a fast start when posting to many networks is the whole product. Ayrshare covers publishing and engagement, Zernio adds basic ad management, Composio gives agents ready-made actions, and Unified.to normalizes ad campaigns across networks.

Most marketing agents don’t stay there. Customers ask for campaign changes, review replies, and results joined with CRM data. Nango gives you pre-built tools for the first workflow, pre-approved or your own OAuth apps, and coding agents that build the next operation on the same auth, sync, and logging infrastructure.

To try it, follow the Nango quickstart and connect a Facebook Page in a few minutes.

How to expose tools to AI agents without clogging their context

Sapnesh Naik — Thu, 15 Oct 2026 18:52:16 +0000

To give AI agents access to hundreds of tools without filling their context window, expose a small working set and let them discover additional tools on demand. Enforce permissions when tools execute, and keep responses compact: tool definitions and returned data both consume context.

A sales assistant connected to Gmail, Google Calendar, and Salesforce may have hundreds of operations available. Preparing for a meeting needs only a handful. Nango Agent Sessions let developers scope permitted tools, pin frequently used tools, and keep the rest searchable. We tested these exposure patterns with 57 tools and a fixed dataset.

Why do large tool catalogs cause problems?

Tool exposure creates three separate costs:

Definitions: names, descriptions, and argument schemas consume tokens before execution.
Selection: overlapping operations such as search_messages, list_threads, and get_thread require the agent to distinguish similar choices. Mailbox administration adds choices that meeting preparation does not need.
Results: even three tools can fill context if they return 200 full email threads or every field from 50 opportunities.

Anthropic’s advanced tool use article (November 2025) describes five MCP servers exposing 58 tools whose definitions consumed approximately 55,000 tokens. Schema complexity matters as well as tool count.

How much input does discovery with pinned tools save?

Discovery with two pinned tools used 69% fewer input tokens per task than loading all 57 tool definitions upfront in our synthetic test.

We ran six tasks twice per configuration. The tasks used three tools returning fixed fictional meeting, account, and email records; the other 54 tool definitions served as distractors. Discovery exposed two meta tools. The pinned configuration also loaded the meeting and account tools upfront.

Claude Sonnet 4.6, six synthetic tasks run twice per configuration. All used Agent Sessions with client-supplied typed schemas and passed the task checks. Input is summed across model calls, not peak context size.

Tool exposure	Median cumulative input tokens per task	Reduction vs full loading
Baseline: load all 57 definitions	19,394.5	Reference
Discovery only	10,861	44%
Discovery with two pinned tools	6,070.5	69%

Pinning common tools avoided searches for those tools. Discovery alone started with fewer tokens, but the pinned configuration used less input across complete tasks. Measure the whole task when choosing what to pin.

Separate tool permissions from tool visibility

User authorization, session permissions, and tool visibility control different things. Decide what the agent may execute before choosing what the model sees.

Layer	What it controls	Meeting-preparation example
User authorization	Access granted through the connected account and OAuth permissions	Salesforce access under the user's existing rights
Session permissions	Connections and operations the application permits	CRM reads allowed; writes excluded
Tool visibility	Definitions presented to the model	Common tools loaded; others discoverable

With Nango Agent Sessions, your backend selects connections using tags or specific IDs and defines a toolset with allow and deny rules. Nango executes calls using those connections without exposing provider credentials to the model. The agent cannot broaden its own scope. Configure restrictions explicitly: omitting toolset includes every tool on integrations the tenant has a resolved connection for.

The execution layer must enforce permissions on every call, including guessed tool names or instructions found in retrieved content. See how developers secure AI agent access to APIs.

How should you choose which tools an agent sees?

Use task-specific tools for predictable work, select tool groups from application state, and add discovery for capabilities outside the initial selection.

Curate tools around useful tasks

A tool for every API endpoint forces the agent to assemble low-level calls into a workflow. Preparing a briefing might require finding an account, resolving record IDs, fetching opportunities, and filtering activities.

A custom get_account_briefing tool could accept an account identifier and return its owner, open opportunities, and recent activities in one call. Supply identifiers from application state where possible, or provide a lookup that resolves ambiguous names.

Explain what each tool returns, when to use it, and its limitations. Purpose-built tools reduce repeated decisions but require maintenance and may not cover unusual requests. Anthropic’s tool-design guidance describes similar task-oriented designs.

Coding agents such as Claude Code, Cursor, and Codex can use the Nango builder skill to build or customize tools for API integrations. Nango runs those functions using the user’s connected account; see how to build reliable tool calls for AI agents for the broader design pattern.

Select tool groups from the task and application state

Your application can often select tools before calling the model. A “Prepare for meeting” button can expose calendar, email search, and CRM read tools. “Log call notes” can expose CRM write tools if the session permits writes.

Use routing rules for predictable workflows or a classifier for open-ended requests. The tradeoff is omission: if the user adds “also check Acme’s support tickets” and routing selected no ticketing tools, the agent needs a recovery path. Discovery provides one within its permitted scope.

Discover tools on demand and pin frequently used tools

Progressive disclosure loads definitions as the task needs them. The agent searches a catalog of permitted tools, receives matching definitions, and executes a selected tool. Tool discovery searches capabilities: finding an email-search tool returns its definition; executing it returns emails.

Nango Agent Sessions expose two default meta tools:

**nango_tool_search**: searches by a plain-language query and returns best matches with argument schemas. Related leads appear without schemas.
**nango_execute**: runs a selected tool by name using the connection resolved for its integration.

Other permitted tools stay searchable without appearing individually in tools/list. Use pinned_tools to list the small core needed on most requests, avoiding discovery for common operations. Choose the core from observed usage; no fixed number suits every workflow.

Our pinned core contained the meeting and account fixture actions. One recorded Acme briefing used four calls:

Call	Observed result
Pinned meeting action, company Acme	Meeting mtg_acme_001, starting 2026-10-16T14:00:00Z
Pinned account action, company Acme	Owner Mira Stone; opportunity opp_acme_001 in Proposal
nango_tool_search, query "latest customer email note benchmark fixture"	Email-summary fixture action with its input schema
nango_execute, email-summary action with company Acme	Thread thread_acme_001; "Legal review pending"

Search adds a step, and names, descriptions, and ranking settings affect retrieval. Allow query refinement when the expected tool appears only as a related lead. Discovery cannot grant access outside the toolset.

The optional nango_proxy meta tool makes authenticated endpoint requests for connected integrations in the toolset. It bypasses tool-level allow and deny restrictions and is disabled by default. Keep it disabled when those restrictions must constrain the agent.

Check the schema on every exposure path

The pilot revealed a difference between listing and discovery. In the tested dev build, pinned action tools appeared in tools/list with a permissive object schema and no declared properties. Searching for the same fixture action returned its deployed schema, including the required company argument.

In one full-catalog pilot briefing, the model sent {"account":"Acme"} to actions requiring company, and the calls failed. A typed function declaration alone did not establish what the model received.

We excluded the pilot from the comparison and supplied input schemas from management MCP metadata client-side for listed integration tools. The controlled results therefore compare exposure strategies with typed input contracts supplied on both paths. Inspect actual tools/list and search responses in your client, and validate arguments before executing function logic.

Does MCP automatically reduce context usage?

MCP does not guarantee selective loading. Its tools/list interface supports pagination, which divides a tool list across responses. A client can still fetch every page and load every definition. The server or client must control which definitions reach the model.

How can you reduce tool-response size?

Return what the next decision requires, with identifiers that let the agent retrieve more detail. A small catalog can still exhaust context through large results.

Targeted searches: search emails from Acme contacts in the last 30 days instead of listing the inbox.
Field selection: return opportunity name, stage, amount, close date, and owner instead of every field.
Pagination: return the first 10 results and a cursor so the agent can request more.
Retrievable detail: return email excerpts with message IDs for fetching full threads when needed.

Keep source links for verification and IDs for follow-up calls. Make truncation explicit: “10 of 42 opportunities returned” tells the agent whether further retrieval may be necessary.

Nango’s action functions let developers define schemas and choose which provider fields reach the agent. Implement response reduction in function code while preserving a way to retrieve omitted information.

For repeated calls or large intermediate datasets, run loops, filtering, and aggregation in a backend function or code-execution environment. Return relevant records and totals together. Predefined functions suit stable workflows; agent-written code requires a sandbox, resource limits, and monitoring. Retain enough evidence for the model to explain its answer.

Choose the simplest approach that preserves task success

Situation	Approach
Small, predictable workflow	Curated tools exposed directly
Distinct product workflows	Tool groups selected from task and application state
Large, varied tool catalog	On-demand discovery with a small pinned core
Large responses or repetitive processing	Compact outputs and execution outside the conversation

Evaluate completion quality, wrong-tool calls, discovery misses, input tokens, and latency together. Include follow-up requests and less common capabilities, and compare identical tasks before and after changing exposure. Inspect the schemas as well as the number of visible tools.

To implement this with Nango, create an Agent Session with explicit connection and tool permissions. Keep the permitted catalog searchable, pin common tools, and shape outputs around the agent’s next decision.

Related reading:

Best HIPAA-compliant integration platforms for AI agents

Sapnesh Naik — Tue, 13 Oct 2026 18:50:17 +0000

TL;DR

Nango: Best overall for customer-facing healthcare agents connecting SaaS accounts. Combines prebuilt tools, scoped access, and adaptable PHI handling with a Growth/Enterprise BAA path and Enterprise BYOC.
Composio: A managed tool catalog with accessible BAA acceptance on eligible paid plans. Best suited to teams that can meet their PHI retention requirements within its feature-specific controls.
Merge Agent Handler: Managed MCP tools with configurable checks on sensitive data. Suitability depends on contractual coverage and the behavior of request and response rules.
Workato: A fit for centrally governed healthcare workflows exposed to agents. BAA coverage depends on the selected services and the model receiving PHI.
Redox: Best for EHR-first projects where clinical interoperability is the central purchase requirement. Covered exchanges, site permissions, and payload retention shape its fit.

Choosing an integration platform for healthcare AI agents

Healthcare AI agents rely on API integrations to retrieve information and take action across the systems where care is coordinated. The integration platform manages those connections and executes the operations the agent requests. Its access controls and data handling therefore shape which records the agent can reach and where protected health information (PHI) travels.

Choosing a platform means evaluating those controls alongside business associate agreement (BAA) coverage and deployment options. The key questions concern who the agent acts for, what it can retrieve or change, and what persists after execution. Those requirements apply across the full workflow, including data returned to the model.

For example, a scheduling agent may read a referral email, check a calendar, and send a confirmation. Each step needs appropriate account access, while the referral’s clinical details may be unnecessary for the calendar lookup. This makes operation-level permissions and control over returned fields relevant to the platform decision.

This article compares five platforms against those requirements. Nango is our overall recommendation for customer-facing healthcare agents connecting SaaS accounts. We also examine alternatives for centrally governed workflows and EHR connectivity, so teams can match the platform to the systems and data their agents actually use.

What “HIPAA-compliant” means in this comparison

An AI agent integration platform with a BAA can support a healthcare deployment, but the agreement alone does not establish compliance. Building HIPAA-compliant AI agents involves safeguards across the source application, integration service, agent runtime, model provider, storage, logs, and other processors receiving PHI.

A free prototype using synthetic data can demonstrate functionality without establishing eligibility to handle PHI. The appropriate agreements must be in place before the first PHI-bearing workflow, even in a small evaluation for one customer.

SOC 2 reports, encryption, MCP support, and self-hosting can inform this review, but none replaces the applicable HIPAA obligations. HHS does not certify or endorse particular products. Its HIPAA guidance for cloud computing explains the responsibilities of cloud customers and business associates, including appropriate agreements and risk analysis.

The shortlist connects each use case to a procurement starting point. Where public information does not settle service or plan eligibility, the executed contract determines coverage.

Platform	Healthcare agent use case	HIPAA / BAA starting point	Relevant controls
Nango	Best overall for customer-facing SaaS agents	Growth add-on or Enterprise, with BAA	Prebuilt tools, scoped sessions, adaptable outputs, Enterprise BYOC
Composio	Managed tools for healthcare SaaS access	Pro BAA add-on; included on Enterprise	Payload retention across enabled features
Merge Agent Handler	MCP tools with sensitive-data rules	Published Merge BAA; Agent Handler scope depends on contract	Request/response checks and tool logs
Workato	Agent access to healthcare workflows	BAA available; selected-service coverage depends on contract	Read/write permissions and model agreements
Redox	EHR and clinical interoperability	Contracts and BAA covering planned exchanges	Clinical access and payload retention

Verified on October 8, 2026 against public documentation and pricing. Eligibility for PHI use depends on the terms covering the actual deployment.

1. Nango: best overall for healthcare agents across SaaS accounts

Overview

Nango offers 7,000+ prebuilt agent tools across 1,000+ APIs, with managed authentication, tool calls, triggers, syncs, webhooks, and an API proxy. Ready-to-use operations cover tasks such as finding calendar availability, with access scoped to the relevant customer account.

Those operations provide a starting point as the product adds document context or a customer-specific API. Existing tools can be adapted and new ones added as permissions or returned fields change, while retaining the same authentication and execution infrastructure.

Best for

Best overall for teams whose customer-facing healthcare agents need prebuilt SaaS actions, fresh document context, customer-specific PHI handling, and deployment flexibility, subject to the required BAA and configuration.

Pros

BAA availability: Nango’s plans include a BAA through the $450/month Growth add-on or Enterprise. Agreement scope determines which features are covered for PHI use.
Flexible deployment with cloud, self-hosting, and BYOC: Enterprise offers self-hosting and BYOC. Nango operates BYOC infrastructure in the customer’s cloud; self-hosting places operations with the customer. BYOC supports AWS, GCP, and Azure regions beyond Nango’s US cloud. Both options keep the integration runtime and PHI storage in the customer’s infrastructure, with no PHI stored in Nango’s cloud. BYOC sends operational health telemetry to Nango’s monitoring service; self-managed instances send no data back automatically.
Scoped agent access: Agent Sessions limit connections, tools, and access duration. The backend manages scope and client authentication, keeping session tokens outside model input while Nango handles provider credentials.
Adaptable PHI handling: Prebuilt tools can be customized to restrict inputs and returned fields. For example, Nango’s Google Calendar find-free-slots tool could be narrowed to permitted calendars and return availability without event details. Booking can have separate authorization.
Coding-agent support: Claude Code, Cursor, and Codex can adapt integrations using Nango skills and Management MCP. These development tools are separate from runtime Agent Sessions.
Fresh context and visibility: Data Sync uses webhooks and polling to keep context current. Google Drive syncs cover metadata and permissions; content retrieval is separate. Operation logs and OpenTelemetry export support monitoring.
Configurable retention: Nango Cloud defaults to 15-day operation-log retention. For synced records, payloads are pruned after 30 days without a record update, and records are deleted after 60 days without a sync execution. Cloud retention settings are configurable to match the deployment’s requirements. Proxy and function HTTP logs omit request and response bodies; custom logs should exclude PHI. Self-hosted and BYOC deployments keep PHI storage and retention controls in the customer’s infrastructure. See Nango’s security documentation for the default retention behavior.

Cons

Advanced controls require Enterprise: The Growth BAA option excludes audit trails and BYOC. Free self-hosting has fewer features, and self-managed deployments add operational responsibility.

2. Composio: managed healthcare agent tools with accessible BAA acceptance

Overview

Composio combines managed authentication with prebuilt and custom tools through SDK and MCP interfaces for healthcare SaaS workflows.

For PHI-bearing workflows, its pricing introduced August 15, 2026 lists a Pro BAA add-on at $0.0003 per tool call; Enterprise includes it. These terms apply to new accounts; existing customers may have different contractual terms. Execution and other add-ons are charged separately.

Best for

Teams prioritizing managed tool execution and dashboard BAA activation for a defined workflow that fits the available retention controls.

Pros

Dashboard BAA acceptance: Pro and Enterprise Developer customers can accept the BAA through billing settings. Coverage depends on acceptance and the agreement’s service scope.
Payload retention controls: Zero Data Retention (ZDR) suppresses covered tool and proxy payloads while retaining metadata. It is separate from BAA acceptance.

Cons

Limited ZDR coverage: Managed OAuth apps require Enterprise for ZDR coverage. Triggers, sandboxes, files, and tool-search queries have separate retention behavior, so covered calls do not make the entire workflow payload-free.
New projects need activation: On non-Enterprise paid plans, new projects start with ZDR off, even when existing projects have it enabled.
Cloud-first procurement: In a recent prospect evaluation shared with us, Composio’s sales team recommended cloud hosting with a data agreement and discouraged Enterprise self-hosting. Teams requiring customer-cloud deployment should confirm availability and operating responsibilities for their proposed setup.

3. Merge Agent Handler: managed MCP with configurable sensitive-data rules

Overview

For teams prioritizing checks on data passing through MCP tools, Merge Agent Handler provides authentication, execution, and a Security Gateway. This is a separate service from Merge Unified API and its normalized, synced-data model.

That product distinction also matters during procurement. Merge publishes a BAA, while the executed agreement and order form determine coverage for Agent Handler, its enabled capabilities, and the deployment. Public information does not settle plan-specific eligibility.

Best for

Teams whose main requirement is a HIPAA-compliant MCP server for customer-facing agents with centrally configured traffic checks, subject to contractual coverage and verified rule behavior.

Pros

Central data rules: The Security Gateway applies shared data-handling rules across tools, with coverage determined by the configured rules and inspection direction.
Request and response checks: AI guardrails can inspect either or both, with block or log actions. Their effectiveness depends on the configured rules.

Cons

Request rules do not filter results: Standard entity and regex rules inspect arguments. Response inspection relies on separately configured AI guardrails.
Guardrails fail open: Calls proceed when the evaluator errors or is unsure, which conflicts with requirements to block calls when inspection fails.
Sensitive tool logs: Logs can retain arguments and results. Their retention and export are separate from the administrative audit trail.

4. Workato: centralized governance for healthcare agent workflows

Overview

Workato lets an integration team expose workflows as agent tools. The team defines the sequence of operations and the inputs and outputs in recipes, giving agents a way to invoke established processes. For example, an intake agent could call a recipe that checks referral details before passing a request to scheduling.

Using those workflows with PHI requires agreement coverage for the selected automation, MCP, and agent services. Workato documents BAA availability; Agent Studio’s security documentation also calls out model-provider agreements for PHI in model interactions, including skill outputs and knowledge sources.

Best for

Enterprise teams buying HIPAA-compliant workflow automation for agents that execute centrally governed recipes, particularly where Workato already manages the relevant processes.

Pros

Workflows as agent tools: Recipes expose established healthcare processes with controlled inputs and outputs.
Group-level tool permissions: Separate read and write tools let groups retrieve information without receiving tools that modify it.

Cons

Private connectivity is not customer-cloud execution: The on-prem agent connects private systems; it does not establish where workflows execute or data and logs reside. Virtual Private Workato is a separate offering with a fully managed dedicated VPC. Teams whose customer policies require execution and PHI storage inside their own cloud account should confirm whether the proposed deployment meets that requirement.
Customer authorization adds integration work: Centrally administered workflows still need customer-specific connection mapping and patient-level permissions when exposed to customer-facing agents.

Pricing depends on the selected workflow, deployment, agent services, and model usage.

5. Redox: clinical and EHR integrations for healthcare agents

Overview

When the required workflow depends on EHR connectivity, clinical formats and hospital interfaces become central to the purchase. Redox specializes in this healthcare API integration and may be the stronger choice than Nango for that scope.

Establishing that exchange also requires the connection partner’s involvement. Redox’s implementation guidance emphasizes contracts, BAAs, and coordination with the healthcare organization’s technical team before setting a launch date.

Best for

Agents whose central requirement is EHR connectivity and clinical interoperability.

Pros

Clinical specialization: Clinical APIs, healthcare data formats, and hospital interfaces support agents that depend on EHR information.
Site implementation support: Redox’s implementation process addresses coordination with healthcare connection partners for production exchanges.

Cons

Site-dependent capabilities: Available operations depend on region, EHR configuration, API entitlements, and partnerships. Appointment updates do not establish booking access, and sandbox access does not establish production availability.
Service-specific retention: Message payloads have 60-day retention, while Data on Demand data can persist for the contract duration. Backup-deletion terms also affect persistence.
Separate implementation costs: Core starts at $35,000/year. Total pricing includes platform, consumption, and scoped managed services, depending on exchange volume and implementation.
Customer-cloud requirements: Teams whose customer policies require integration execution and PHI storage inside their own cloud account should confirm deployment availability before choosing Redox. This is a customer-specific requirement rather than a universal HIPAA obligation.

Clinical connectivity may cover only part of the product. Calendar, email, or document access can require a complementary platform, making the full set of operations relevant to whether one vendor can support the product.

What determines platform fit for a HIPAA-covered workflow

For HIPAA-compliant automation, platform fit depends on the operations an agent performs and the PHI each step receives, returns, or stores. Using the same workflow across vendors makes differences in coverage and control clearer. For example, a scheduling comparison could cover finding availability and sending a confirmation. Six criteria shape that fit:

BAA availability and scope: Standard or negotiated terms define the covered services, eligible plans, activation requirements, and any usage-based compliance charges. Coverage for the selected agent features determines whether the agreement fits the workflow.
Exact coverage: Support depends on the provider, region, API entitlement, endpoint, read/write behavior, and available prebuilt operation. An OAuth connection or an EHR logo does not prove appointment booking works.
Access boundaries: Customer, account, tool, and session limits constrain what the agent can access. Patient and record permissions remain application responsibilities even when an account connection is valid.
PHI handling: Arguments and results may pass through prompts, caches, sync storage, logs, backups, and support tools. Each introduces its own handling and retention considerations. Keeping credentials out of prompts does not remove PHI from results.
Deployment and operations: Managed cloud and customer-cloud deployments differ in hosting location and operating responsibilities. Support access, monitoring, incident handling, and log exports also affect the deployment. Payload retention and administrative audit retention are separate questions.
Behavior and cost: Data freshness, rate limits, reconnects, duplicate events, failed writes, and safe retries affect workflow reliability. Total cost includes connections, execution, storage, transfer, BAA add-ons, and the required deployment.

Safe retry behavior depends on whether an operation failed or merely returned an uncertain result. For example, a provider may accept a booking before the request times out. Retrying without resolving that outcome can create a duplicate appointment. Reconciliation or provider-supported idempotency can prevent a retry from repeating an already completed write.

A realistic cost comparison uses the same workload across vendors. For instance, a scheduling product may connect clinic accounts, look up appointments, send confirmations, sync referral documents, and export logs. Those operations incur different connection, execution, storage, and transfer costs. BAA add-ons and required regional deployment also affect the total; clinical exchanges and site implementation add separate costs for an EHR-focused deployment.

These criteria address separate requirements. Satisfying a contractual condition does not establish that the technical configuration fits. For example, settling the BAA can still leave read-only access or regional hosting unresolved. Contract terms resolve unpublished eligibility details, while testing establishes how the proposed configuration behaves.

FAQ

Does a BAA make an AI agent HIPAA compliant?

No. A BAA establishes obligations between the parties. The organization must also assess risks and implement the applicable safeguards throughout the agent’s data flow. The HHS Security Rule summary explains these responsibilities.

Can calendar and email integrations involve PHI?

Yes. The relevant question is whether the content identifies a person and reveals information about their healthcare in a HIPAA-covered context. The application storing it does not settle that question. For instance, a calendar entry may combine a patient’s name with the reason for a visit. Ordinary calendar events are not automatically PHI. The HHS definition of protected health information explains the applicable scope.

Is SOC 2 enough for a HIPAA-covered integration?

No. A SOC 2 report can inform vendor due diligence. It does not replace applicable HIPAA obligations, the required BAA, or your assessment of the deployed workflow. A claimed HIPAA-compliant API still depends on its actual configuration and use.

Does HIPAA require US hosting or self-hosting?

Neither is a universal HIPAA requirement. HHS cloud guidance allows overseas processing with the relevant agreements and risk analysis. Customer policies and other applicable requirements can still impose specific regions or deployment models. HIPAA-compliant integrations with BYOC or self-hosting remain subject to agreement coverage and appropriate safeguards; infrastructure control alone does not establish compliance.

Do I need an EHR platform or a general agent connector platform?

The required operations determine the fit. A healthcare product can need HIPAA-compliant calendar and email integrations for AI agents without connecting to an EHR. Calendar, email, and document access across customer accounts favors a general product integration platform. EHR records and hospital interfaces favor clinical interoperability platforms such as Redox. Some products need both.

Can MCP tools send PHI to the model?

Yes. MCP does not inherently filter tool results. Keeping OAuth tokens outside the model protects credentials, while returned content requires its own controls. Output minimization and the model provider’s contractual coverage and data policies remain relevant when tool results contain PHI.

Which Nango offering should I evaluate?

The Growth add-on and Enterprise provide BAA paths. BYOC, self-hosting, and the additional Enterprise controls make Enterprise relevant for deployments requiring those features. Agreement scope determines deployment coverage, and Nango’s Trust Center provides access to supporting security evidence.

Nango’s fit for customer-facing healthcare agents

Nango is our overall recommendation for healthcare products whose agents act across customer-owned SaaS accounts, maintain fresh context, and accommodate customer-specific data rules. Prebuilt tools provide the initial operations, while Agent Sessions constrain access. Customization supports changing requirements, and Enterprise adds deployment options. The Growth or Enterprise BAA determines coverage for the selected deployment.

The alternatives fit specific priorities: Composio for managed tools and dashboard BAA activation, Merge Agent Handler for centrally configured MCP traffic checks, and Workato for governed enterprise workflows. Redox may be stronger when EHR connectivity is the central requirement. For every platform, suitability depends on the agreement, permissions, data handling, and operating responsibilities of the actual deployment.

Best StackOne alternatives in 2026

Sapnesh Naik — Fri, 09 Oct 2026 15:35:00 +0000

Using an AI agent to call a few SaaS APIs is relatively straightforward. It gets harder when integrations must keep customer data in sync, support account-specific fields and mappings, and handle write actions that follow your product’s business rules.

StackOne provides prebuilt actions and an AI Integration Gateway. But its AI Integration Builder is still in early access. If your product needs custom integrations, compare how each platform builds, tests, and runs them.

This guide compares Nango, Merge, Paragon, Pipedream Connect, Composio, and Arcade. We focus on agent tools, data sync, customer-specific requirements, deployment, and pricing.

TL;DR

StackOne combines prebuilt actions, data sync, and agent tooling. Still, another platform may fit better depending on your operational coverage, customization needs, data model, and pricing requirements. Our main picks are:

Nango: Our top pick for customer-facing AI agents and product integrations that need prebuilt tools, persistent syncs, and control over integration behavior as requirements grow.
Merge: Consider it when standard objects in its unified API categories meet your needs. Agent tools and unified data sync are separate products.
Paragon: Consider it when a visual workflow builder is central to your product. Dynamic Field Mapping and private deployment require Enterprise.

Best StackOne alternatives at a glance

Platform	Agent tools	Managed data sync	Custom integration logic	Customer configuration	Deployment
Nango	Prebuilt and custom tools	Incremental syncs on the same runtime	TypeScript functions built with coding agents	Objects, mappings, and filters per connection	Cloud; Enterprise BYOC or self-managed
Merge	Separate Agent Handler product	Unified Common Models	Custom Agent Handler connectors on Enterprise	Advanced fields on higher tiers	Cloud; custom Agent Handler deployments on Enterprise
Paragon	ActionKit	Managed Sync	Visual workflows and TypeScript framework	Dynamic Field Mapping on Enterprise	Cloud; private deployment on Enterprise
Pipedream Connect	Actions and per-user MCP	Build your own pipeline	Custom components and API proxy	Component inputs and per-user accounts	Managed cloud
Composio	Catalog tools and hosted MCP	Build your own pipeline	Custom tools run in your application	User sessions and shared connections	Managed cloud; you host custom logic
Arcade	Hosted and custom MCP tools	Build your own pipeline	MCP framework and custom servers	Per-user authorization and access controls	Cloud; private deployment on Enterprise

Nango combines agent tools and data sync with integration logic your team can change. That matters when a customer asks for a new API operation, a custom field, or a different update rule. A coding agent can implement the change on Nango, and your team can review and deploy it.

What StackOne offers in 2026 and why you should look for an alternative

StackOne originally focused on unified APIs for HRIS, ATS, and LMS platforms. It has since repositioned around AI agents and now describes itself as an “AI Integration Gateway.”

StackOne lists 540+ connectors and 33,000+ actions. Agents can access them through MCP, SDKs, A2A, or HTTP. The platform also offers tool search, access controls, request logs, and prompt-injection scanning.

For product integrations, the important differences are how you customize operations and where you use synced data:

Connector logic uses YAML: StackOne’s AI Integration Builder generates connector definitions for its execution engine. Nango integrations are TypeScript functions that your coding agent can build and extend.
The AI Integration Builder is in early access: Check the feature’s availability and test it against your required operations before depending on it for your roadmap.
Synced records live in StackOne indexes: Data Sync polls provider APIs and stores records in StackOne. Deep Query searches those records. If you need a copy in your application database, evaluate how you will retrieve and maintain it.
Embedded use has its own plans: StackOne’s Gateway plans serve employees’ agents. OEM plans let customers connect accounts through your product. Compare the plan that matches your use case.

Nango is worth evaluating when your product needs custom tools and syncs that feed your own database. The same runtime handles both, and each connection can carry the customer’s field mappings and filters.

The six best StackOne alternatives

Nango is our recommended starting point for agent and product integrations. The other platforms fit requirements such as standard data models, visual workflows, or tool execution without managed sync.

1. Nango

Overview

Nango is an integration platform for AI agents and customer-facing products. It ships 7,000+ prebuilt tools across 1,000+ APIs, with managed auth, tools, triggers, data syncs, webhooks, and an API proxy on one platform. You start with pre-approved OAuth apps and prebuilt functions, then extend them as requirements grow.

Best for

Teams shipping AI agents or SaaS products that need API integrations they can customize as customer requirements change. Nango supports agent tools, persistent syncs, and custom business logic together. Enterprise teams can also run it in their own cloud or infrastructure.

Pros

Start with prebuilt tools: Use the catalog for common operations, then extend it as your product needs more. Nango also offers pre-approved OAuth apps to help you get started.
Coding agents build and extend integrations: With the Nango skill, Claude Code, Cursor, or Codex can customize a prebuilt tool and test it against a real connection. Integrations are TypeScript functions. Your team reviews the logic before deployment.
Agent tools and data sync share one runtime: One connection can power an agent’s write tools and an incremental sync. Syncs resume from checkpoints and notify your backend of changes. Your application can consume those records into its own database.
Configure each customer’s integration: Store objects, field mappings, and filters in the customer’s connection metadata. Functions read that configuration when they run. You can also define your own shared data model across providers.
Give agents limited access: Agent Sessions restrict each session to selected connections and tools. Sessions expire, and provider credentials stay inside Nango.
Debug integrations with your coding agent: The Management MCP server lets agents inspect runs and manage functions. Observability covers function runs and API requests, with OpenTelemetry export.
Choose where integrations run: Use Nango Cloud, BYOC, or a self-managed deployment. BYOC and self-managed deployments require Enterprise. A free self-hosted edition covers auth and proxy use cases.

Motion launched about 189 integrations for its AI employees and workflows. Replit uses Nango syncs across more than 30 connectors to power triggers in its automation product.

For example, a coding agent can extend a NetSuite invoice sync to include each customer’s custom cost-center field. The mapping lives on the customer’s connection, so one deployed sync can support different field mappings.

Cons

You define the shared schema: If you want one data model across providers, your team must choose that model and review its mappings. Coding agents can help implement them.

When to choose Nango over StackOne

Choose Nango when integrations are part of the product you ship to customers. Coding agents can build the operations your product needs. Nango runs the tools and syncs together, with each customer’s credentials and configuration.

For a deeper build guide, see using AI coding agents for building API integrations.

2. Merge

Overview

Merge separates data integrations and agent tools into two products. Unified maps provider data into Common Models across categories such as HRIS, ATS, and CRM. Agent Handler exposes tools to agents and has separate pricing.

Best for

Products whose needs fit Merge’s standard objects and supported categories. Teams that also need agent tools must evaluate Agent Handler separately.

Pros

One schema per category: Standard HRIS, ATS, CRM, and other supported objects follow Merge’s Common Models across providers.
Managed syncs: Merge keeps normalized data synchronized on a schedule.

Cons

Custom fields require higher tiers: Merge’s Unified pricing places custom-field access on Professional and Enterprise. Products that need customer-specific data must budget beyond Launch.
Tools and syncs are separate products: Merge’s managed syncs live in Unified; its prebuilt agent tools live in Agent Handler. Agent Handler Pro starts at $1,000/month, and custom connectors require Enterprise.
Standard models may omit data your product needs: Provider-specific fields and objects may require Field Mappings or other supplemental data features. Your team must handle those differences alongside the Common Models.

StackOne vs Merge

Merge centers data integrations on Common Models. StackOne centers its current offering on an agent gateway. Choose Nango when you want coding agents to build custom tools and syncs around your product’s own schema. See Merge.dev vs Nango.

3. Paragon

Overview

Paragon is an embedded integration platform. Its product suite includes ActionKit for agent actions, Managed Sync for data pipelines, and Workflows for automation. Teams can build workflows visually or with its TypeScript framework.

Best for

B2B SaaS products where a visual workflow builder is central to the integration experience.

Pros

Three products included: Plans include ActionKit, Managed Sync, Workflows, and managed authentication.
Visual workflow builder: Teams can configure workflows through a visual interface.

Cons

Multiple products to integrate: Combining agent actions, syncs, and workflows means working across ActionKit, Managed Sync, and Workflows. Nango tools and syncs use the same function model and runtime.
Dynamic Field Mapping requires Enterprise: Paragon lists Dynamic Field Mapping and private deployment as Enterprise features. Prices require a sales quote.
Your team adopts its workflow model: Paragon supports TypeScript as well as visual workflows. Evaluate whether that workflow model fits the custom operations your product needs.

See Paragon vs Nango for a detailed comparison.

4. Pipedream Connect

Overview

Pipedream Connect gives agents access to users’ connected apps. It provides hosted authentication, prebuilt actions, event triggers, and an API proxy. MCP tools run with each user’s connected accounts.

Important:

Workday acquired Pipedream in February 2026. Pipedream’s public changelog lists October 1, 2025 as its latest entry. Ask about the Connect roadmap if you are evaluating a long-term dependency.

Best for

Agents that mainly need prebuilt actions and event triggers. Products that also need a persistent copy of customer data must build that pipeline separately.

Pros

Large action catalog: Many apps come with ready-made actions and triggers.
Per-user MCP: Each external user gets tools tied to their own connected accounts.

Cons

You build the data sync pipeline: Connect provides actions and triggers. For a current copy of customer records, your team must manage pagination, checkpoints, and deletion handling.
User and compute charges both affect cost: Startup costs $99/month with annual billing or $150/month with monthly billing. It includes 100 external users and 10,000 usage credits. Additional users cost $2 each; usage credits meter compute in 30-second units.

See Pipedream Connect alternatives for more options.

5. Composio

Overview

Composio offers a managed catalog of agent tools. It handles authentication, tool discovery through sessions, and event triggers. Developers connect agents through its SDKs or hosted MCP.

Best for

Internal or personal automation agents that mainly need catalog tools. It can also serve products that handle persistent data sync and custom tool hosting themselves.

Pros

Large prebuilt tool catalog: Agents can call many SaaS tools without defining each one.
Sessions and triggers: Sessions handle tool discovery and auth, and triggers can start an agent on provider events.

Cons

You build the data sync pipeline: Tool calls and triggers do not maintain a persistent copy of customer records. Your team must build and operate that pipeline.
Custom tools run in your application: Composio’s custom tools execute in your process. The API is marked experimental. You host and monitor that custom logic.
Add-ons change the effective rate: Composio pricing meters tool calls and trigger events. Shared connections, proxy execution, and some compliance options add usage charges.
Cloud is the only hosting option: Composio advertises Enterprise self-hosting. Its sales team regularly recommends Cloud hosting with a data agreement instead and discourages Enterprise self-hosting. Composio also does not offer a managed bring-your-own-cloud deployment.

Important:

Composio disclosed a May 2026 security incident involving compromised customer credentials. It reported 5,001 leaked GitHub connections and 5,241 potentially exposed Composio API keys. Its September update describes remediation and independent reviews. Include that update in your security evaluation.

StackOne vs Composio

Both offer prebuilt agent tools. StackOne also provides Data Sync and YAML connector building. Composio leaves persistent sync and custom tool hosting to your application. Nango runs custom tools and syncs together. See our Composio alternatives for more.

6. Arcade

Overview

Arcade is a runtime for agent tools and MCP servers. It handles user authorization and access controls. Teams can use hosted tools, connect remote MCP servers, or build their own with Arcade’s framework.

Best for

Agents that mainly need MCP tools with user authorization and access controls. Teams needing persistent data sync must build it separately.

Pros

User authorization and access controls: Arcade manages authorization and permissions around tool calls.
MCP framework: Teams can build tools and connect existing MCP servers.

Cons

You build the persistent data pipeline: Arcade focuses on tool execution. Your team must build the syncs that keep application records current, including scheduling, checkpoints, and recovery.
Private deployment requires Enterprise: Standard plans run on Arcade Cloud. Enterprise offers private and air-gapped deployment options.

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

FAQs

What is the best StackOne alternative for customer-facing AI agents?

Nango is our top StackOne alternative for customer-facing AI agents that need custom tools and current customer data. Coding agents build and extend integrations. Nango runs agent tools and persistent syncs together, with managed authentication and scoped Agent Sessions.

What is the best StackOne alternative for SaaS product integrations?

Nango is our top choice when a SaaS product needs data sync, write operations, and customer-specific mappings. Your team defines the data model and integration rules. Coding agents implement the functions, and Nango handles authentication and execution.

Which StackOne alternatives support self-hosting?

Nango offers BYOC and self-managed deployments on Enterprise. With BYOC, Nango operates the instance in your cloud account. A free self-hosted edition covers auth and proxy use cases. Arcade, Paragon, and Merge Agent Handler also list private deployment options on Enterprise. Compare the available features in our self-hosting guide.

Can I keep my existing data model and custom fields?

Yes. Nango functions can map provider data into your product’s existing schema. Store each customer’s field mappings and filters on their connection. The sync reads that configuration when it runs.

Can coding agents build custom integrations on Nango?

Yes. Claude Code, Cursor, and Codex can use the Nango skill to build or extend TypeScript integrations. They can test functions against real connections and deploy them after your team’s review. Nango supplies the authentication and runtime for those tools, syncs, and webhook handlers.

Conclusion

Nango is our top StackOne alternative for AI agents and customer-facing product integrations. It combines tools, persistent syncs, and customer-specific logic on one runtime. Coding agents can build new operations as your product’s requirements grow.

Start with prebuilt tools, then use Claude Code, Cursor, or Codex to adapt them. Your team controls the functions and data model. Nango handles authentication and execution on Cloud or an Enterprise deployment in your own infrastructure.

Test your hardest operation before you switch. Check the Nango API catalog for your providers, then follow the quickstart with a free account.

Related reading

Nango vs Rutter: Which is better?

Sapnesh Naik — Wed, 07 Oct 2026 15:30:31 +0000

TL;DR

Nango is the best choice for AI agent and product integrations that combine accounting with broader integrations. Its prebuilt financial actions and syncs provide a starting point that teams can extend with CRM context, documents, and customer-specific behavior on the same platform.
Rutter is the stronger fit for usecases that benefit from normalized data across accounting APIs. Its specialization can save substantial mapping work for bank feeds and standard accounting automation.

Choosing a platform for accounting integrations and more

Accounting and commerce integrations let a SaaS product or AI agent work with data from its customers’ business systems. The integration platform shapes how that data is represented, how updates reach the product, and where custom logic runs.

Nango provides prebuilt actions and syncs that developers can adapt to their own model and run on managed infrastructure. Rutter supplies a shared financial model that reduces mapping work when its resources fit the product. Nango’s approach gives teams more control as requirements expand across business systems.

For example, a revenue operations product may read invoices from QuickBooks or Xero, then connect them to CRM deals and contracts. Adding a customer’s collections rules introduces logic that depends on all three sources. Where that logic runs becomes part of the platform decision.

Nango vs Rutter at a glance

Nango combines prebuilt integrations with control over the data and behavior your product needs. Your team can adapt template outputs, add validation, and run that logic on Nango’s managed infrastructure.

Rutter supplies predefined financial models with extension options, which can reduce mapping work for closely matched workflows. For products with customer-specific rules or plans to add other business systems, Nango provides a broader foundation: the data model and integration functions can evolve together on the same platform.

Buying criterion	Nango	Rutter
Starting point	7000+ prebuilt actions, syncs, and tools across 1,000+ APIs	Normalized financial resources and managed connectors
Data model	Template defaults or a model your team defines	Shared financial models with extension mechanisms
Supported categories	Financial, commerce, accounting, CRM, storage, IM, HRIS, communication, and more	Financial, commerce, and payment workflows
Provider-specific behavior	Native API proxy and custom functions	Custom fields, platform data, and passthrough
Ongoing data	Managed incremental syncs and webhook processing	Configurable initial and incremental syncs
Product agents	Prebuilt/custom tools and scoped Agent Sessions	Publicly described emerging finance MCP layer
Maintenance	Managed auth and execution; team owns custom functions	Managed normalized connectors; team owns application extensions
Pricing basis	Connections, compute, and data transfer	Custom production quote

Nango vs. Rutter: API support

Both platforms support major accounting and commerce APIs. Nango’s advantage is broader coverage across financial tools and the rest of your customers’ software stack, with 1,000+ supported APIs.

Comparison (not exhaustive):

Category	Nango	Rutter
Accounting and ERP	QuickBooks Online, Xero, NetSuite, Sage Intacct, Zoho Books and 50+ Accounting and ERP APIs	QuickBooks Online and Desktop, Xero, NetSuite, Sage Intacct, Zoho Books
Commerce	Shopify, Amazon, WooCommerce, BigCommerce, Square and 60+ e-commerce APIs	Shopify, Amazon, WooCommerce, BigCommerce, Square
Payments and other financial tools	Stripe, PayPal, Chargeable, Adyen, BILL, Brex, Ramp, Mercury, Wise and 40+ payment providers	Stripe, PayPal, Chargebee, Recurly, Plaid, MX, Teller
Beyond finance	Salesforce, HubSpot, Gmail, Slack, Google Drive, Notion, Zendesk, GitHub and more	HR and advertising integrations, including Gusto, Rippling, BambooHR, Google Ads, and Meta Ads

For products that need to combine financial data with CRM records, email, documents, or support workflows, Nango covers those integrations within the same platform.

What each platform provides

Nango: prebuilt integrations for 1,000+ APIs

Nango’s catalog spans 7,000+ tools across 1,000+ APIs, covering authentication, tool calls, triggers, and syncs on managed infrastructure. That infrastructure also runs the team’s extensions, so developers can reuse available integrations, change their behavior, or add native API operations beyond the catalog.

Best for: Customer-facing products and agents that need finance-related integrations alongside CRM, documents, and customer-specific behavior.

Pros:

Prebuilt financial actions and syncs provide a useful starting point.
Teams can change output models, transformations, and tools in integration code.
Custom functions and native API requests use the same managed platform.
Coding-agent Skills help Claude Code, Codex, and Cursor implement, test, and deploy changes.
Enterprise ready deployment options that include Nango cloud, Managed instance in your cloud (BYOC) and self-hosting

Cons:

A shared accounting model and custom business rules still need engineering. Templates and coding agents reduce implementation work; the team defines and tests the semantics.

Rutter: a unified API for financial workflows

Rutter organizes its platform around standardized resources across supported financial and commerce systems. Those resources reduce mapping work when the product’s required fields fit the common accounting API.

Best for: Finance-centric products whose required accounting operations fit Rutter’s normalized resources, or fintechs using its specialized bank-feed workflows.

Pros:

Common financial resources reduce provider-specific schema mapping.
Managed syncs support configurable objects, history, and update frequency.
Custom fields and passthrough provide access beyond the standard fields.

Cons:

CRM and document features may require a separate integration platform.
Product-specific transformations and approval workflows remain application code.
Production cost requires a quote for the required providers and capabilities.

Which gets your first accounting integration working?

Both platforms provide a starting point for reading invoices. The difference is how much of the product’s data model comes with that starting point, and how the team adapts it afterward.

For the revenue operations example, Nango provides these starting components:

QuickBooks: list-invoices, get-invoice, create-invoice, and update-invoice, alongside invoice syncs.
Xero: invoice actions and an invoice sync.

These components supply the provider operations; the product adds its customer matching and presentation rules.

Rutter exposes invoices through normalized financial resources. Fields such as customer_id, amount_due, and currency_code give supported providers a common representation. That saves mapping work when the supplied fields match the product’s requirements.

Nango is well suited for teams that need reusable operations and control over their output. Rutter can shorten the initial mapping when its financial model already fits.

Who owns the data model and the next customer-specific requirement?

A shared model determines what an invoice means inside the product. That includes field names, relationships, and rules for interpreting provider-specific values. Nango lets the team define that model; Rutter supplies a financial model that the application can extend around.

A shared model and additional fields

With Nango, integration functions can return the specific schema your product needs. The team can adapt a template’s output into fields such as outstanding_amount and keep that mapping alongside the integration. This gives the product a consistent interface while preserving control over its accounting semantics.

A simple additional field is possible with either platform. For example, a customer may need a NetSuite collections-hold value. Nango can retrieve and map it in a function. Rutter supports custom-field metadata, source values through expand=platform_data, and custom-field writes for supported entities and providers. Its extension mechanisms may already cover that request.

Custom behavior and native API access

The difference becomes more consequential when the field drives behavior. Suppose the product must return a “needs review” status when the hold conflicts with a CRM deal, then prepare a collections-note update:

A custom Nango function can combine provider data with supplied CRM context, validate the rule, and perform the write after application approval.
With Rutter, this requires workarounds.

Both also provide access beyond standard operations:

Nango’s request proxy authenticates native API requests and manages rate limits, which custom functions can use on the same managed platform.
Rutter offers field-level passthrough for additional request fields and credentials passthrough for direct API calls on listed platforms. But you’ll need to handle provider specific rate-limits yourself.

Provider-specific fields still need validation and error handling.

Testing and maintaining the change

For custom NetSuite integrations, Nango’s advantage is keeping the retrieval, transformation, and reusable action together. Its coding-agent Skills help Claude Code, Cursor, and Codex implement changes from existing templates. The team still tests missing fields, subsidiary relationships, and rejected updates. Those checks establish whether the new behavior matches the customer’s business rule.

How do they keep financial data current?

The model is only useful if it reflects later payments, credits, and corrections. There are three states to consider: the accounting system’s record, the integration’s last completed update, and the copy used by the application. A successful connection alone does not establish that all three agree.

Initial history and ongoing updates

Nango’s managed data syncs support incremental updates and per-customer configuration. Teams can adapt sync functions and combine polling with webhook processing where the provider supports it. That control lets the integration’s fetching and mapping behavior evolve with the product’s freshness requirements.

Corrections and deleted records

Corrections matter after that first load. A missed credit can overstate an invoice balance, while a missed void can leave an invoice in a collections queue. Nango’s Xero invoice sync handles DELETED and VOIDED statuses as record deletions. That behavior is specific to the template. Rutter also documents deletion events, with support varying by provider and object.

Recovering from a failed update

Recovery depends on where processing stopped:

If fetching failed, the integration needs to resume or repeat the affected work.
If the platform received the update but the application failed to apply it, the application needs to reprocess that change without duplicating its effects.

Both implementations need to track completion at that final step.

Nango’s execution logs help trace failures to a connection, function, or request. The team can inspect a transformation and deploy a correction within the same platform. Rutter’s connection and sync events describe the financial sync state, while the team investigates its application-side processing. Nango’s control is especially useful when recovery requires changing custom sync behavior.

What changes when your product adds CRM, documents, or AI agents?

Once invoices are current, the revenue operations product can associate them with deals and contracts. This is where Nango’s broader coverage becomes a practical advantage: the same platform supports connections, background data, and custom actions across those systems.

Connecting invoices to deals and contracts

The application still decides which CRM account corresponds to an accounting customer and which contract belongs to a deal. Nango provides the integration components around those relationships, with prebuilt coverage depending on the required provider and operation. The team can extend missing behavior without introducing another integration platform.

Rutter can remain the financial layer alongside a separate platform for CRM and documents. That can make sense when its financial normalization saves enough work. It also creates another connection lifecycle and another set of failure signals to operate. An investigation may need to follow the invoice through Rutter and the associated deal through the other system.

Giving agents scoped access to the workflow

An agent adds another requirement: controlled access to the assembled context and the actions it can propose. Nango’s MCP and tools expose prebuilt actions and custom functions. Agent Sessions let the backend constrain connections, tools, and session lifetime while keeping provider credentials out of model context.

In this example, the workflow has three stages:

A session reads selected invoices and deal context.
The agent proposes a collections-note update.
The application validates the proposal and obtains approval before invoking the write.

The same custom function can serve both the product’s regular workflow and its agent, so the validation logic does not need a separate implementation for each.

Rutter publicly describes an emerging finance MCP layer for unified read/write access. Its public description, checked October 6, 2026, does not establish the available tools and access controls for this complete scenario. Those details need confirmation for the intended deployment.

For financial AI agent integrations that also need CRM context, documents, and custom actions, Nango is the stronger overall fit. Its documented execution and session model supports that broader workflow on one platform.

When to choose Nango and when Rutter is a better fit

Nango for an expanding product roadmap

Nango is the stronger choice when accounting is the start of a broader product workflow. Three concrete situations make that advantage clear:

A revenue operations product combines QuickBooks or Xero invoices with CRM deals and contracts. Nango supports these API integrations on the same platform.
An enterprise customer needs a NetSuite field, a custom status transformation, and a validated update. Nango keeps that behavior in reusable integration functions alongside native API access.
A product agent needs selected financial records and a narrowly scoped action that also uses business context. Nango combines tools with backend-controlled Agent Sessions.

Rutter for closely matched financial workflows

Rutter is a better fit when financial specialization removes enough work to outweigh the need for broader coverage:

A fintech’s primary requirement is a supported bank-feed workflow, and Rutter covers its required institutions, accounting platforms, and operations.
An accounting automation product needs standard invoice or bill operations across supported systems, and Rutter’s normalized fields closely match its model.
A finance-focused product already operates CRM and document integrations elsewhere, and Rutter’s financial resources save more implementation effort than the additional platform introduces.

For teams evaluating Rutter alternatives because requirements keep expanding, Nango offers the more adaptable foundation. Its advantage grows as the product adds behavior that depends on several business systems.

FAQs

Is Nango only an OAuth tool, or does it provide accounting integrations and syncs?

Nango provides accounting actions and syncs as well as authentication. The QuickBooks and Xero catalogs list specific operations. Authentication support alone does not imply every operation is prebuilt.

Does Nango provide the same normalized accounting schema as Rutter?

No. Nango supplies template defaults and supports a model defined by your team. Rutter supplies normalized financial resources. A unified API for accounting is useful only if its field meanings fit the product.

Which fits a product that needs accounting, CRM, and document integrations?

Nango is the stronger fit for that combined roadmap. Its integration catalog spans the required categories, while the application owns record matching. Rutter can cover finance alongside another platform.

Can Nango and Rutter both support financial AI agents?

Nango has tools and scoped Agent Sessions. Rutter describes an roadmap MCP feature but timelines are not confirmed.

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 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:

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: