Nango: Deploying AI-Generated Integration Functions to Production

Nango is an open-source integration platform that deploys AI-generated TypeScript functions to a production runtime with managed auth, retries, and multi-tenant connection state. It supports 800+ APIs and is used by Replit, Ramp, and Mercor. The interesting part is not that AI writes code. The interesting part is the plumbing that turns a prompt into a versioned, authenticated, rate-limited function running at scale.

The Three Primitives

Nango gives you three building blocks:

Auth: Managed OAuth, API keys, and token refresh for 800+ APIs. You embed a white-label auth flow in your frontend. Nango handles credential storage, token rotation, and multi-tenant connection management. Each connection is scoped to a user and a provider.

Proxy: Make authenticated API requests on behalf of users. You send requests through Nango’s proxy. It resolves the provider, injects credentials, handles retries and rate limits, and returns the response. You do not manage tokens or retry logic.

Functions: Write integration logic as TypeScript functions and deploy to Nango. Functions execute on a production runtime with built-in API access, retries, storage, and observability. You can write them by hand or use the AI builder to generate them from a description.

How AI-Generated Functions Deploy

The AI builder takes a natural language description of your use case and generates a TypeScript function. Here is what happens next:

Code generation: The AI writes a function that uses Nango’s SDK to call the target API. It includes auth handling, pagination, and error handling.
Versioning: The function is stored with a version identifier. You can deploy multiple versions and roll back if needed.
Deployment: The function is pushed to Nango’s runtime. The runtime is a managed execution environment that runs your code in isolation.
Execution: When you trigger the function, the runtime loads the correct version, injects the connection credentials, and executes the code. It handles retries, rate limits, and logging.

The runtime is not serverless in the AWS Lambda sense. It is a persistent execution environment that keeps connection state warm and reuses authenticated sessions. This reduces latency and avoids repeated OAuth handshakes.

Architecture: From Prompt to Execution

Here is the flow when an AI agent generates and deploys an integration function:

┌─────────────┐
│ AI Builder  │ (natural language → TypeScript)
└──────┬──────┘
       │
       v
┌─────────────┐
│  Function   │ (versioned TypeScript code)
│  Registry   │
└──────┬──────┘
       │
       v
┌─────────────┐
│  Runtime    │ (isolated execution, connection injection)
│  Deployment │
└──────┬──────┘
       │
       v
┌─────────────┐
│  API Proxy  │ (auth, retries, rate limits)
└──────┬──────┘
       │
       v
┌─────────────┐
│ External    │ (Salesforce, HubSpot, etc.)
│ API         │
└─────────────┘

The runtime injects three things into every function:

Connection credentials: OAuth tokens, API keys, or session cookies for the target API.
Storage: A key-value store scoped to the connection. You can persist state between function runs.
Observability: Logs, traces, and error reporting. You do not instrument this yourself.

Multi-Tenancy and Namespace Isolation

Nango handles multi-tenancy by scoping connections to a connectionId and a providerConfigKey. The connectionId is your user identifier. The providerConfigKey is the integration identifier (e.g., salesforce-crm).

When you deploy a function, you specify which provider it targets. The runtime enforces this boundary. A function for Salesforce cannot access HubSpot credentials, even if both connections exist for the same user.

Namespace collisions are avoided by versioning. Each function has a unique identifier and version number. You can deploy multiple versions of the same function and route traffic based on feature flags or user segments.

Code Example: AI-Generated Function

Here is what an AI-generated function looks like after deployment:

export default async function fetchContacts(nango: NangoSync) {
  const endpoint = '/v3/contacts';
  let hasMore = true;
  let offset = 0;

  while (hasMore) {
    const response = await nango.get({
      endpoint: `${endpoint}?offset=${offset}&limit=100`,
    });

    const contacts = response.data.results;
    await nango.batchSave(contacts, 'Contact');

    hasMore = response.data.has_more;
    offset += 100;
  }
}

The nango object is injected by the runtime. It provides:

get, post, put, delete: Authenticated HTTP methods with automatic retry and rate limiting.
batchSave: Persist data to Nango’s storage. You can query it later or sync it to your database.
log: Structured logging that appears in the Nango dashboard.

The function does not handle auth, token refresh, or retry logic. The runtime does that.

Deployment Shape and Failure Modes

Nango’s runtime is a managed service. You do not provision servers or configure autoscaling. You deploy functions via the CLI or API, and Nango handles execution.

Deployment pipeline:

Write or generate the function.
Test it locally with the Nango CLI.
Deploy it to the Nango cloud or self-hosted instance.
Trigger it via API, webhook, or schedule.

Failure modes:

Failure Type	Handling
API rate limit	Automatic exponential backoff, respects `Retry-After` headers
Token expiration	Automatic token refresh before request, fallback to re-auth flow
Network timeout	Configurable retry with jitter, logs failure after max attempts
Function crash	Runtime captures stack trace, logs error, marks execution as failed
Storage write failure	Transactional save, rollback on error, retries with idempotency key

The runtime does not retry indefinitely. After a configurable number of attempts, it marks the execution as failed and surfaces the error in the dashboard. You can configure alerting to notify your team.

Observability and State Management

Every function execution is logged. You get:

Execution time: How long the function ran.
API calls: Which endpoints were hit, with request and response payloads.
Errors: Stack traces, HTTP status codes, and error messages.
Storage writes: What data was saved and when.

State management is handled by Nango’s key-value store. You can persist data between function runs. This is useful for incremental syncs, where you only fetch new records since the last run.

const lastSyncTime = await nango.getMetadata('lastSyncTime');
const response = await nango.get({
  endpoint: `/contacts?updated_since=${lastSyncTime}`,
});
await nango.setMetadata('lastSyncTime', new Date().toISOString());

The store is scoped to the connection. One user’s data does not leak into another’s.

Security Boundaries

Nango enforces several security boundaries:

Credential isolation: Functions cannot access credentials for other connections or providers.
Code isolation: Functions run in isolated environments. One function cannot read another’s memory or storage.
Rate limiting: The runtime enforces per-connection rate limits to prevent abuse.
Audit logs: Every API call, storage write, and function execution is logged.

If you self-host Nango, you control the encryption keys for stored credentials. In the cloud version, Nango encrypts credentials at rest and in transit.

MCP Support for Agent Integration

Nango supports the Model Context Protocol (MCP), which lets AI agents discover and call integration functions. An agent can query Nango for available functions, read their schemas, and invoke them with parameters.

This is useful when you want an agent to orchestrate multi-step workflows across APIs. For example, an agent could:

Fetch contacts from HubSpot.
Enrich them with data from Clearbit.
Create tasks in Asana for follow-up.

Each step is a Nango function. The agent calls them in sequence, passing data between steps. Nango handles auth, retries, and state persistence.

Trade-Offs and Constraints

Aspect	Nango Approach	Trade-Off
Code ownership	You write or generate TypeScript	Locked into TypeScript, cannot use Python or Go
Runtime control	Managed execution environment	Less control over infrastructure, cold start latency
Auth complexity	Nango handles OAuth, token refresh	Vendor lock-in for auth flows, harder to customize
Observability	Built-in logs and traces	Less flexibility than custom instrumentation
Multi-tenancy	Connection-scoped isolation	Requires Nango’s connection model, not just API keys

The biggest constraint is the TypeScript requirement. If your team writes Python or Go, you need to either adopt TypeScript for integrations or use Nango’s API to trigger functions from your existing codebase.

When to Use Nango

Use Nango when:

You need to integrate with dozens or hundreds of APIs and do not want to manage OAuth flows for each one.
You want AI to generate integration code but need production-grade execution with retries, rate limiting, and observability.
You are building an AI agent that needs to call external APIs on behalf of users.
You want to avoid writing boilerplate for token refresh, pagination, and error handling.

Avoid Nango when:

You only integrate with one or two APIs and can manage auth yourself.
You need sub-millisecond latency and cannot tolerate the overhead of a proxy layer.
You require full control over the execution environment and cannot use a managed runtime.
Your integrations are written in a language other than TypeScript and you cannot adopt it.

Technical Verdict

Nango solves the plumbing gap between “AI writes code” and “code runs reliably at scale.” It gives you a runtime that handles auth, retries, multi-tenancy, and observability so you do not have to. The AI builder is a nice shortcut, but the real value is the infrastructure underneath.

If you are building a product that integrates with many APIs, or an AI agent that needs to call external services, Nango is worth evaluating. The TypeScript constraint is real, but the trade-off is less boilerplate and faster time to production.

The self-hosted option gives you control over credentials and infrastructure. The cloud version is faster to start but introduces vendor dependency. Choose based on your security and compliance requirements.