什么是API Gateway
这个 API Gateway 是 Maton 提供的一层直通代理，核心作用不是重新封装各家接口，而是让开发者通过托管好的连接方式，直接调用第三方服务原生 API。它面向的对象很明确：当团队已经熟悉 Slack、Google Workspace、Microsoft 365、GitHub、Notion、HubSpot、Airtable、Salesforce、Stripe 等平台各自的接口形态，却不想再分别处理 OAuth 授权、令牌注入和连接切换时，可以把这一层通道作为统一入口来用。
它的访问方式也比较直接，请求统一走固定网关地址，路径前缀先写应用名，再接目标服务原本的 API 路径。例如访问 Gmail 时，路径必须以对应连接的 app 名开头，而不是只照搬原生接口地址。调用时只需要在请求头里放 Maton API key，网关会自动为目标服务注入相应的 OAuth token；除 Host 和 Authorization 之外，请求头、查询参数以及常见 HTTP 方法都可以透传到目标 API。
从证据包看，这个工具并不试图替代各平台官方文档，也不把第三方接口抽象成统一数据模型。它更像是一个“认证与路由层”：一边通过单独的控制端点管理连接，支持创建、查询、列出和删除连接；另一边保留原生接口调用方式，减少开发者在多系统集成中的重复接线工作。对于需要同时接入多个 SaaS 的应用来说，这种设计的价值在于上手门槛低，迁移成本也相对可控。
核心功能特点
- 通过单一网关地址直连第三方原生 API，不必改写成平台自定义协议
- 使用 Maton API key 统一鉴权，目标服务所需 OAuth token 由网关自动注入
- 内置连接管理能力，可创建、查询、筛选和删除连接，并查看连接状态
- 同一应用存在多个连接时，可用 Maton-Connection 请求头明确指定要使用的连接
- 支持大量主流服务，覆盖 Google、Microsoft、Slack、GitHub、Notion、HubSpot、Salesforce、Stripe、Airtable 等百余种 API
- 保留原生请求习惯，查询参数、自定义请求头及 GET、POST、PUT、PATCH、DELETE 等方法都可透传
适用场景
最适合它的场景，是要把多个现成 SaaS 能力拼接到同一产品里的团队。比如内部运营系统既要发 Slack 消息、读写 Google Sheets、同步 HubSpot 联系人，又要查询 Salesforce 或 Stripe 数据，如果分别处理每家的 OAuth 流程、访问入口和连接维护，工程上会很碎。API Gateway 把这部分共性工作收拢到统一入口，开发侧仍可按各家原生端点继续调用，比较适合已有接口经验、但想减少接入杂务的后端或平台团队。
它也适合做自动化和集成型应用。证据包里的示例已经覆盖 Slack 发消息、HubSpot 新建联系人、Google Sheets 读取表格、Notion 查询数据库、Airtable 列表读取、Salesforce 执行 SOQL、Stripe 查询客户等典型动作。对于需要快速把 CRM、协作、表格、邮件、支付、项目管理等系统串联起来的服务，这种“保留原生 API、统一认证入口”的方式，通常比重新学习一套中间层 DSL 更省时间。
如果一个服务下会有多个授权对象，这个网关也有实际意义。它允许同一 app 维护多条连接，并通过请求头显式选择具体连接；若不指定，则默认使用该应用最早的活跃连接。这对于多客户、多工作区、多组织并行接入的系统尤其重要。再加上连接状态可按 app 和状态筛选，团队能更清楚地知道某个集成是否已完成授权、是否需要替换失效连接。
不过它更偏向“集成通道”而不是“高级编排平台”。当团队希望继续依赖官方 API 文档、保持与原生端点一致的调用习惯，同时把认证和连接管理外包出去，它会很合适；如果需求是统一数据语义、跨平台做深度抽象，证据包里并没有显示它提供这类能力。换句话说，它最适合放在多 SaaS 接入链路的中间层，帮助开发者把精力放在业务逻辑上，而不是反复处理授权细节。