nango

只有让学生不把全部时间都用在学习上，而留下许多自由支配的时间，他才能顺利地学习，这是教育过程的逻辑。——苏霍姆林斯基

Nango：用 AI 构建、运行与维护产品集成

项目地址：https://github.com/NangoHQ/nango

对于许多产品团队而言，集成从来不是一句“接一下 API”那么简单。

连接一个外部服务，意味着要面对授权流程、访问令牌、刷新机制、不同供应商的接口风格、请求重试、速率限制、多租户连接管理，以及上线之后持续不断的维护工作。真正让人疲惫的，往往不是发出第一条请求，而是让这条连接在真实业务里稳定地活下去。

Nango 是一个开源的产品集成平台，定位是帮助团队用 AI 构建产品集成。它支持超过一千个 API，并可与任意后端语言、AI 编码工具和代理 SDK 协同工作。

在 Nango 的视角里，集成不应当只是隐藏在业务代码角落中的一段临时逻辑。它可以被写成 TypeScript 函数，可以借助 AI 生成，可以运行在面向生产环境的运行时中，并由平台承担认证、执行、扩缩容与可观测性等工作。

于是，外部 API 不再只是难以驯服的接口集合，而可以成为产品能力的一部分。

集成工作的三块基石

Nango 将集成能力归纳为三个核心原语：认证、代理与函数。

这三部分像一支协作明确的队伍。

认证负责让产品获得进入外部服务的权限。代理负责携带正确的凭据发起请求。函数则负责承载更具体的集成逻辑，让同步、写入、处理与编排拥有可部署的代码形态。

从用户授权到 API 调用，再到持续运行的业务逻辑，Nango 希望让集成的完整链路能够在同一个平台中展开。

Auth：让授权不再成为每次集成的起点

认证是产品集成中最容易被低估、却最难绕开的部分。

OAuth、API Key、令牌刷新、凭据存储、多租户连接管理，每一项都与外部服务的访问能力紧紧相连。Nango 提供面向超过一千个 API 的托管认证能力，支持 OAuth、API Key 与令牌刷新。

它还允许开发者在产品中嵌入白标授权流程，让用户能够在自己的产品界面中完成连接。

nango.openConnectUI({
    onEvent: (event) => {
        /* handle completion */
    }
});

这段代码承担的角色很直接：在前端打开连接界面，并在授权流程完成时处理事件。

对于产品而言，用户连接外部服务不必成为跳出当前体验的一段陌生旅程。认证流程可以被嵌入到产品中，而凭据存储、令牌刷新与连接管理则由 Nango 处理。

当一个用户完成连接后，产品获得的不只是一次授权结果，而是一条可以被后续代理请求和集成函数持续使用的连接。

Proxy：让请求带着正确身份抵达外部 API

完成授权之后，下一步是调用 API。

但真正的 API 请求并不只是拼接路径和发送参数。系统还需要识别目标服务、注入凭据、处理重试、面对速率限制，并将最终响应带回调用方。

Nango 的 Proxy 用于代表用户发起已认证的 API 请求。

import { Nango } from '@nangohq/node';

const nango = new Nango({
    secretKey: '<NANGO-SECRET-KEY>'
});

const response = await nango.get({
    endpoint: '/v3/contacts',
    providerConfigKey: '<INTEGRATION-ID>',
    connectionId: '<CONNECTION-ID>'
});

在这段示例中，开发者创建 Nango 客户端，然后通过集成标识与连接标识发起请求。

请求通过 Nango 的代理层流转。平台会解析服务提供方、注入对应凭据、处理重试与速率限制，并返回响应结果。

这种方式让业务代码不必在每一次请求中重复处理认证细节。调用方更关注自己真正想访问的资源，而平台则承担与连接状态、凭据和请求过程相关的工作。

Functions：把集成逻辑写成可运行的 TypeScript

认证解决“能不能访问”，代理解决“如何安全调用”，而函数则回答“调用之后要完成什么业务动作”。

Nango 支持将集成逻辑写成 TypeScript 函数，并部署到生产运行时中执行。函数运行时内置 API 访问、重试、存储与可观测性能力。

例如，一个函数可以根据输入信息创建 GitHub 问题：

export default async function run(nango: Nango) {
    const { owner, repo, title, body } = nango.input;

    const response = await nango.post({
        endpoint: `/repos/${owner}/${repo}/issues`,
        data: {
            title,
            body
        }
    });

    return response.data;
}

函数从 nango.input 中读取输入数据，然后通过 nango.post 调用外部 API，并返回响应数据。

这种形式让集成逻辑不再只是散落在应用服务中的请求代码，而是可以作为独立函数被编写、审阅、编辑与版本控制。

Nango 还提供 AI builder。开发者可以通过自然语言描述使用场景，由 AI 生成 TypeScript 集成函数。

这里的重点并不是让代码成为不可见的黑箱。Nango 强调生成后的代码仍然可读、可审查、可编辑、可进行版本控制。AI 参与代码生成，而人仍然能够掌握代码本身。

从 AI 工具调用到数据同步

Nango 支持多种常见集成模式。

不同产品需要与外部 API 建立连接的原因并不相同。有的场景需要让 AI 代理执行外部操作，有的场景需要将数据同步到自己的系统，有的场景需要可靠地处理第三方 Webhook，也有的场景希望将差异巨大的接口统一成自己的数据结构。

Nango 所列出的集成方向包括以下几类。

AI 工具调用与 MCP

AI 代理如果需要真正作用于外部世界，就需要能够调用外部 API。

Nango 可以为 AI 代理提供调用外部 API 的能力。对于希望让代理读取、写入或触发外部服务操作的产品来说，集成层成为代理行动能力的一部分。

AI 不再只停留在生成文字或分析内容的阶段，也可以通过已连接的外部 API 参与实际工作流。

数据同步

数据同步可以是单向，也可以是双向。

Nango 支持面向 RAG 流程、索引与触发器的数据同步场景。外部系统中的数据可以参与后续的检索、索引或自动化流程，而同步机制则承担数据持续流动的任务。

Webhook 处理

外部服务通过 Webhook 把事件推送出来时，接收只是开始，可靠处理才是关键。

Nango 支持接收并处理来自外部 API 的 Webhook。对于依赖事件驱动流程的产品而言，Webhook 让外部变化能够进入自己的系统，并触发后续逻辑。

API 统一

不同服务常常拥有不同字段、不同资源模型与不同请求方式。

Nango 支持将 API 规范化为产品自己的通用结构。这样一来，产品可以面向自己的统一模式组织逻辑，而不必让每一个业务模块都直接面对不同供应商之间的差异。

Actions

集成不仅用于读取数据，也可以用于写入数据和执行操作。

Nango 支持代表用户写入数据、执行操作。这让产品能够在授权和连接建立之后，进一步将外部 API 转化为可执行的业务能力。

面向客户的个性化配置

不同客户对集成的需求并不总是一致。

Nango 支持为每位客户定制集成行为。对于需要根据客户需求调整连接、同步或业务逻辑的产品而言，集成不再只能采用完全相同的方式运行。

五分钟内走通一条集成路径

Nango 的快速开始路径围绕三个步骤展开：创建集成、完成授权、访问 API。

第一步是创建一个集成，并在 Integrations 页面完成配置。

第二步是在 Connections 页面创建连接，完成授权流程。之后，可以将授权界面嵌入自己的产品中。

nango.openConnectUI({
    onEvent: (event) => {
        /* handle completion */
    }
});

第三步是获取连接信息，并使用认证后的连接访问 API。

import { Nango } from '@nangohq/node';

const nango = new Nango({
    secretKey: '<NANGO-SECRET-KEY>'
});

const connection = await nango.getConnection(
    '<INTEGRATION-ID>',
    '<CONNECTION-ID>'
);

console.log(connection.credentials);

这段代码通过集成标识与连接标识获取连接信息，并输出连接凭据。

围绕这一条基本路径，开发者可以选择嵌入认证流程、通过代理发起请求，或者构建自己的集成函数。不同的使用方式并非彼此排斥，而是可以根据产品需要组合起来。

AI 生成代码，但控制权仍在开发者手中

Nango 将自己的代码生成方式概括为 AI 生成、人类控制。

开发者可以用自然语言描述集成需求，由 AI builder 生成 TypeScript 函数。但生成代码不会被锁进一个无法查看的黑箱中。代码依然是可读的，可以审阅，可以修改，也可以纳入版本控制。

对于集成工作而言，这一点尤为重要。

外部 API 的调用往往与产品数据、用户权限、业务流程和实际操作紧密相关。即便 AI 能够帮助生成初始逻辑，团队仍然需要查看代码、理解行为、调整细节，并将它纳入正常的软件工程流程。

Nango 提供的方向并不是用 AI 替代对代码的掌控，而是让 AI 帮助更快地形成集成代码，同时保留开发者对实现的可见性与控制权。

面向生产环境的运行基础

集成进入生产环境之后，最重要的问题通常不再是“能不能请求成功”，而是“是否能够稳定运行”。

Nango 表示其运行时提供每租户隔离、弹性扩缩容、自动重试与速率限制处理能力，并处理数十亿次 API 请求。

对于产品集成来说，稳定性往往来自许多细节共同发挥作用：令牌需要被保存和刷新，请求需要面对限流，失败需要得到处理，不同客户之间的连接需要彼此隔离，执行环境需要随工作负载变化而伸缩。

Nango 将认证、执行、扩缩容与可观测性纳入平台职责，让集成代码能够运行在为生产场景准备的基础设施之上。

超过一千个 API 的认证支持

连接外部 API 时，最容易重复出现的工作，往往就是认证。

不同服务有不同的 OAuth 配置、不同的刷新机制、不同的权限范围、不同的凭据格式。即使两个平台都使用 OAuth，具体流程也可能存在大量差异。

Nango 提供超过一千个 API 的认证支持，覆盖 OAuth 流程、令牌刷新、凭据存储与多租户能力。

这使产品团队不必从零开始为每一个外部 API 重复构建认证体系。连接能力可以在更统一的基础上展开，而集成代码则能够更专注于业务逻辑。

兼容现有工作流

Nango 可以通过 CLI 与 API 完整操作，并且兼容任意后端语言或框架。

这意味着，平台不要求产品完全采用某一种服务端技术栈。无论后端使用什么语言或框架，Nango 都可以成为集成能力的一层。

在 AI 编码工具方面，README 列出了 Cursor、Codex 与 Claude Code。在代理 SDK 方面，则列出了 MCP 与 LangChain。

这种兼容性让 Nango 能够进入不同的开发工作流。它既可以服务于传统产品后端，也可以参与由 AI 编码工具和代理 SDK 驱动的新型开发方式。

集成能力不必被锁定在某一种开发模式中，而可以跟随团队现有的工具与架构继续生长。

开源与自托管

Nango 是开源平台。

它既可以运行在 Nango Cloud 上，也可以自托管到自己的基础设施中。README 还提到 Nango 符合 SOC 2 Type II、HIPAA 与 GDPR。

在许可方面，Nango 使用 Elastic License。Cloud 与 Enterprise Self-Hosted 版本会依据计划提供全部功能。

对于希望在云服务与自有基础设施之间保留选择空间的团队而言，开源与自托管让集成平台不必只能以单一形式存在。

让集成从负担变成产品能力

产品集成通常藏在不起眼的地方，却会深刻影响产品可以走多远。

一个授权流程是否顺畅，会影响用户是否愿意连接外部服务。一次 API 调用是否可靠，会影响功能能否稳定交付。数据同步是否持续运行，会影响系统中的信息是否保持可用。Webhook 是否得到可靠处理，会影响外部事件能否进入产品流程。AI 代理是否拥有安全的工具调用能力，会影响它能否真正参与业务动作。

Nango 将这些问题聚焦在认证、代理与函数三个原语中。

认证让连接得以建立，代理让请求带着正确的身份流动，函数让业务逻辑拥有可运行的形态。AI 可以帮助生成代码，而开发者依然可以审阅、编辑与控制它。运行时负责执行、扩缩容、重试与可观测性，产品团队则能够将更多注意力放回真正的产品体验与业务逻辑。

当超过一千个 API 不再是一千种独立挑战，集成便不只是产品研发中的重复劳动。

它也可以成为产品持续延展能力的一部分。