Fabriq Developer vs Nango: What You Own and What You Call

Overview

We've argued the governance side of this market twice, in 10 Best AI Agent Integration Platforms and Composio alternatives. Both rank on agent identity, per-user authority and audit, because that's what a security review asks. This page doesn't. A two-person team at pre-seed has no security review. It has a Friday afternoon, a demo on Tuesday, and a worry about whether today's choice survives six months.

For that reader the decisive facts are narrow and boring. What the free tier actually covers. How many providers are reachable, and reachable how. How long until a tool call returns real data. Whether you have to register an OAuth app with Google before anything works. And who ends up holding your user's access token.

Nango and Agentic Fabriq both answer those questions, and they are not the same kind of product. Nango is an integration platform: unified auth, a proxy, functions you deploy, syncs that replicate provider data into a records cache, and webhooks. Its repository describes it as a way to "connect your agents & product to 1,000 APIs", and agent sessions expose your deployed functions to a model over MCP. Fabriq Developer is narrower. It's a hosted gateway that holds your users' credentials, attaches them server-side at call time, and serves tools to an agent over one MCP endpoint.

One of those you run. The other you call. That's the axis this page is about.

The Free Tiers Are Not Comparable

Start here. It's where the two diverge hardest and where most comparison pages wave a hand.

Nango's free plan is $0 a month with three limits: 10 connections, 10 hours of compute, 10GB of transfer. The first one decides everything, and Nango's pricing FAQ is direct about what it counts: "1 Connection = 1 API key or access token of the external API. For example: 3 users connect their Gmail = 3 connections." If your product asks for Gmail and Slack, every user costs two of your ten. Five users and you're done. Free-tier requests are also rate limited to 200 a minute, against 1,000 on the paid plan.

Past that, Pay-as-you-go is $50 a month base including $50 of monthly credits, then $0.29 per connection, $0.72 per hour of function compute and $0.50 per gigabyte of transfer, with connections prorated by how long they sit in your account. A thousand users with two tools each is 2,000 connections, or $580 a month before any compute.

Fabriq Developer's free plan is priced on a different unit. It's free forever with 20,000 API calls a month, unlimited agents, per-agent tool permissions, request logs, live sessions, and the Python SDK, the afctl CLI and the MCP endpoint. A call is any request your agent makes through Fabriq, which includes authenticating and retrieving credentials, not just the tool call itself. That unit is coarser than a tool call, and we'd rather say so than let you find out from an invoice. The paid steps are $50 a month for 200,000 calls and $300 a month for 2,000,000.

The practical difference: connecting users isn't a billing event on Fabriq, and making calls isn't one on Nango's free tier. Onboard forty design partners who each connect one tool and Nango's free plan runs out while Fabriq's doesn't. Run a batch job that hits one connected account a hundred thousand times and the reverse is true.

Whose OAuth App You Register

This is the biggest single difference in time to first tool call, and it rarely makes it into a comparison table.

Nango's auth guide is explicit: "OAuth APIs require an OAuth developer app registered with the provider." You create the app on the provider's portal, paste in the callback URL Nango's integration settings show you, then paste the client ID, secret and scopes back into Nango. For testing there's a shortcut, flagged honestly: "For popular APIs, Nango ships a built-in shared developer app so you can test connections with zero setup. We strongly recommend registering your own OAuth app before going live." For production Nango also recommends an endpoint on your own domain that 308-redirects to https://api.nango.dev/oauth/callback, so the callback domain your users see belongs to you.

If you've ever shipped a Google integration you know what that path costs. A Cloud project, a consent screen, scope justifications, and for sensitive scopes a verification queue measured in weeks. Nango doesn't make that worse. It just can't make it go away, because the OAuth client is yours.

Fabriq's catalogue lists three connection methods per provider: "Agentic Fabriq's OAuth app", "Your own OAuth app", "Pasted credential". The first is the default on the /developers path, so your first call doesn't wait on a Cloud project. The flip side is real: the consent screen your user sees is ours. If your pitch depends on your own brand appearing at the moment of consent, Nango's custom callback URL plus your own client is the better arrangement, and we'd point you there rather than pretend otherwise.

Figure 1 — The step that dominates time to first call is provider paperwork, and only one of these two paths requires it before you start.

On the Fabriq side the code is short enough to quote. You install agentic-fabriq-sdk for Python or @agenticfabriq/sdk for TypeScript, put AF_APP_ID and AF_APP_SECRET in the environment, and call two methods:

from af_sdk import AgenticFabriq

af = AgenticFabriq()                     # reads AF_APP_ID / AF_APP_SECRET

url = await af.initiate_connection(request, provider="gmail")   # send the user here

async with await af.for_user(request) as session:
    tools = await session.get_tools()    # only what this user granted
    result = await session.call_tool("google_gmail_list_messages", {"max_results": 5})

Note what isn't in that snippet: a user id. Both calls take your framework's request object and read identity from the session your own auth already established, because a user id as a parameter is a value your code, or a model inside it, can get wrong or invent. The escape hatch for background jobs is spelled dangerously_use_raw_user_id, which is hard to type by accident and easy to grep for.

Nango's equivalent is a connect session created from your backend, returning a connect_link valid for 30 minutes, then an agent session whose tenant you express with connection tag selectors. Those have to resolve to exactly one connection per integration or creation fails with ambiguous_connections. Good design, and one more concept to learn on a Friday.

Catalogue Size, Stated Plainly

Both vendors publish a headline number, and both numbers mean less than they look like.

Nango's repository and docs say 1,000+ APIs, with new ones "added on demand within days, by request or self-contributed", and its pricing page advertises "7k pre-built tools, triggers & syncs" on every plan. The contribution path is real and is part of why that number keeps moving.

Fabriq's catalogue currently holds 509 providers. Of those, 123 have a live OAuth redirect, 12 have OAuth in progress, and 374 have no OAuth flow at all and are connected once in the console by pasting a credential. Those are counts out of the generated catalogue file in our own codebase, not marketing, and we'd rather you read them here than discover them halfway through an integration.

There's a tighter number that matters more here. The end-user connect flow, the one where your customer clicks a link and authorizes, drives thirteen providers end to end today: Gmail, Google Drive, Docs, Sheets, Slides, Calendar, Meet, Forms, Contacts and Chat, plus Slack, GitHub and Notion. Anything else returns a 400 from the initiate endpoint. The hosted credential-entry page, where a user pastes their own API key instead of running OAuth, supports Notion only. Every other key-based connector is connected by you in the console, not by your user in a browser.

Self-Hosting, With the Asterisk

Nango being open source is the reason a lot of developers shortlist it, so it's worth being precise about what that gets you in October 2026.

The repository's LICENSE file is the Elastic License 2.0, which is source-available rather than OSI open source. Its central limitation reads: "You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software." For almost every product team that's irrelevant, since you're embedding integrations in your own app rather than reselling Nango. Anyone planning to offer an integration layer to their own customers as a service should read it twice.

The self-hosting docs list three paths: BYOC, where "Nango deploys and operates your instance inside your own AWS account, GCP project or Azure subscription"; Self-Managed, where "you deploy and operate Nango yourself, on your own infrastructure, using our Helm chart"; and Free Self-Hosted, "a limited free self-hosting option is available for hobby projects". Read the feature table before you plan around it. Free Self-Hosted covers API Auth, the Proxy, and observability limited to "Auth + proxy only". Syncs, tool calls, webhooks, triggers, the MCP server, RBAC, MFA, SAML SSO and the audit trail all need Enterprise self-hosting or Nango Cloud.

Read that against what you probably wanted it for. If you came to Nango because you want an agent tool layer running inside your own VPC for free, the free build has no MCP server and no tool calls. That's in the docs rather than hidden in a changelog, but it isn't what "open source and self-hostable" suggests to a developer skimming a README.

Fabriq's position here is worse on paper and we'll say it flatly. There is no public source to read and no free self-host. Installing into your own Kubernetes cluster on AWS or GCP via our Helm chart is available on a custom plan, which means talking to us. If self-hosting is a hard requirement at seed stage, Nango wins this section outright.

The Shape of a Tool

Here the two architectures stop resembling each other, and it's where we'd spend the most evaluation time.

In Nango, a tool is an action function. The docs are unambiguous: "Only action functions can be tools." You enable a template function on an integration or write and deploy your own, and it runs provider-specific code with the connected account's credentials. Agent sessions expose a chosen subset of those functions over an MCP server at a per-session mcp_url, authenticated with a session_token. Sessions are immutable, can't be extended, default to 15 days, and die on a DELETE, after which that MCP server answers 401.

The context handling there is genuinely good. By default nothing in the toolset is listed; tools/list returns Nango's meta tools plus whatever you explicitly pinned, paginated 50 at a time, and the agent finds the rest with a nango_tool_search meta tool. That keeps a large toolset out of a context window it would otherwise fill with definitions the model never calls. One documented sharp edge: Nango warns that with the nango_proxy meta tool enabled, "the agent can call any endpoint of a connected integration in the toolset, including ones your deny list was meant to keep out." Leave it off unless you need it.

The trade is that the tool surface is code you own, so it's also code you maintain. Nango gives you real tooling for that: dry runs, mocks, snapshot tests, a CI/CD path, plus syncs with a records cache, checkpoints and deletion detection if what you need is replicated provider data rather than live calls. Fabriq has nothing comparable to syncs. If your roadmap says "RAG over the customer's Drive, refreshed hourly", that's a Nango job.

Fabriq's tool surface is served from the gateway instead. One schema per tool, one MCP endpoint, and the effective tool list for a call is the intersection of what the user granted and what the agent is scoped to. The agent holds a short-lived session token, 900 seconds by default with a one-hour ceiling, re-minted 60 seconds before expiry, so calling for_user per request is the intended pattern rather than waste. The TypeScript SDK stops short of wrapping an MCP client: it hands you token and mcpUrl and expects you to bring your own. Some will read that as unfinished. We think it's right for a layer that shouldn't own your agent loop, and it's still one fewer convenience than Nango's Node SDK.

Who Holds the Token

Credential model is one of the nine dimensions in the agent access control taxonomy, and it's where these two products' defaults point in opposite directions.

Nango encrypts credentials with AES-256-GCM under an envelope scheme whose data key is wrapped by AWS KMS, which is a solid build, and it's SOC 2 Type II certified with a HIPAA BAA on an add-on. It also hands them back. The auth guide's second code sample is nango.getConnection(integrationId, connectionId), described as how you "fetch credentials whenever you need them". Functions and the proxy let you avoid that, and agent sessions state plainly that "the agent never sees raw credentials, and cannot change the scope of its own session". But pulling the live access token into your own backend is a first-class documented path, which puts your logs, your error reporting and your incident response in scope for it.

Fabriq's default runs the other way. In proxy mode the credential stays in the vault and is attached server-side at the moment of the call, so the agent gets a session and never the secret. Every token also records an auth_level for how the user was proven: app_asserted means we took your app's word for it, app_signed means your backend signed a 60-second single-use assertion with a private key we never hold, and user_present exists only for a moment after a human finished a connection and can't be renewed. You can require signed assertions and refuse unsigned token requests outright. One thing we don't do: disconnecting clears the grant held in our own vault and nothing more. If you need Google to forget, ask Google.

Figure 2 — Both platforms can do both shapes. The difference is which one the documentation puts first, and defaults decide what most teams ship.

Neither default is wrong. If you're writing integration code yourself you need the token, and Nango handing it over is the feature. With an LLM in the loop we'd keep the secret out of any process the model can influence, which is why proxy mode is our default rather than our option.

Which to Pick

No single winner here.

Pick Nango if you want integration code you own and can read, if your users must see your brand on the consent screen, if you need provider data replicated into your own store with change detection, if your provider list runs into the long tail of B2B SaaS, or if self-hosting is a hard requirement.

Pick Fabriq Developer if you want a tool call working before you've registered anything with a provider, if your free-tier ceiling should be calls rather than connected users, if the providers you need are in the Google, Slack, GitHub and Notion cluster, or if you want the credential to stay out of the agent's process by default rather than by discipline.

Pick both is not a cop-out: Nango for syncs and owned integration code, Fabriq for the agent-facing tool surface. They don't fight. Think hard before running two credential stores, though. That's two breach surfaces.

Frequently Asked Questions

Is Nango open source? The repository is public and its LICENSE file is the Elastic License 2.0, which is source-available rather than OSI open source. You can read, modify and run it, but not offer it to third parties as a hosted service providing "any substantial set of the features or functionality of the software".

Can I self-host Nango for free? Yes, with a limited feature set. The docs describe the free option as being "for hobby projects", covering API Auth and the Proxy. Syncs, tool calls, webhooks, triggers and the MCP server require Enterprise self-hosting or Nango Cloud.

Can I self-host Agentic Fabriq? Only on a custom plan, via a Helm chart into your own Kubernetes cluster on AWS or GCP. No free self-hosted build, no public source. Nango is ahead here.

Do I have to register my own OAuth app? With Nango, yes for production: it ships a shared developer app for popular APIs for testing and recommends registering your own before going live. With Fabriq, no. Our provider app is the default, and bringing your own is a supported alternative on much of the catalogue.

How many integrations does each have? Nango advertises 1,000+ APIs and 7k pre-built tools, triggers and syncs. Fabriq's catalogue holds 509 providers: 123 with a live OAuth redirect, 374 connected by pasting a credential in the console. The end-user connect flow drives thirteen of them end to end.

Which free tier goes further? It depends on the axis. Nango gives you 10 connections, 10 compute hours and 10GB a month. Fabriq gives you 20,000 calls a month and unlimited agents, with no per-user charge. Forty design partners fit on one and not the other.

Does either stop an agent calling a tool it shouldn't? Both narrow the surface. Nango's sessions take an allow and deny toolset and the agent can't change its own scope. Fabriq's effective tool list is the intersection of the user's scopes and the agent's, computed when the list is built and again at call time. Neither replaces not granting write access you don't need.

Conclusion

These two look similar in a feature grid and feel nothing alike in practice, because they sit on opposite sides of one decision. Nango hands you the materials: your OAuth app, your function code, your records cache, optionally your own infrastructure. Fabriq hands you an endpoint and keeps the materials.

At pre-seed the cost of the first option is almost never the subscription. It's the week in Google's verification queue and the afternoon learning a function runtime, both spent before you know whether anyone wants the feature. The second option bills you later, as a ceiling you hit when the provider you need isn't in the thirteen, or when a customer asks to see their own name on the consent screen.

Sources

• Nango pricing — Free at 10 connections / 10 compute hours / 10GB, Pay-as-you-go at $50 base with $0.29 per connection, $0.72 per compute hour, $0.50 per GB; "7k pre-built tools, triggers & syncs"; the FAQ definition "1 Connection = 1 API key or access token" (checked October 2026)
• Nango self-hosting — BYOC, Self-Managed and Free Self-Hosted, with the feature table showing syncs, tool calls, webhooks, triggers and the MCP server excluded from the free build (checked October 2026)
• Nango auth guide — "OAuth APIs require an OAuth developer app registered with the provider", the shared developer app caveat, the 308-redirect custom callback URL, the 30-minute connect link, and getConnection returning credentials (checked October 2026)
• Nango agent sessions — tenant/toolset/discovery, mcp_url plus session_token, pinned versus searchable tools, "Only action functions can be tools", and the nango_proxy deny-list warning (checked October 2026)
• Nango limits — 200 requests per minute on free and 1,000 on Pay-as-you-go, 15-minute action function ceiling, 15-day log retention, 30-second minimum sync frequency (checked October 2026)
• Nango security — SOC 2 Type II, AES-256-GCM with envelope encryption under AWS KMS, 1-year audit trail, 30/60-day record retention (checked October 2026)
• Nango repository and its LICENSE — "Connect your agents & product to 1,000 APIs", Elastic License 2.0 and its hosted-service limitation (checked October 2026)
• Nango tool calling for AI agents — action functions as the tool surface, and the pointer to syncs for RAG-style replication (checked October 2026)
• Elastic License 2.0 — the licence text Nango ships under
• Agentic Fabriq pricing — Free forever at 20,000 calls a month with unlimited agents, Launch at $50 for 200,000, Growth at $300 for 2,000,000, Helm self-install on a custom plan, and what counts as a call
• Fabriq Developer and the Developer Quickstart — AF_APP_ID / AF_APP_SECRET, initiate_connection, for_user, 900-second tokens, the auth_level ladder, the thirteen end-user OAuth providers and the Notion-only credential page
• Agent access control taxonomy — the credential, delegation and identity model dimensions used above