凭据保存在 OOMOL。你的后端通过 SDK、MCP 或 HTTP 调用允许的接口,只需要使用连接名称和参数。
接入现成集成
接上用户真正会用的应用,把时间留给产品体验,而不是分页、参数、错误处理和权限范围。
GitHub、Gmail、Notion、Slack、Supabase、Airtable 这些账号,不需要你逐个重写授权和调用逻辑。通过 OOMOL 接入后,产品就能使用同一套连接能力。
浏览 AppsOOMOL 将授权、凭据、参数、调用和记录统一管理,让你的产品通过一套连接能力接入应用。
接上用户真正会用的应用,把时间留给产品体验,而不是分页、参数、错误处理和权限范围。
API key、OAuth token 和连接配置保存在 OOMOL 里。你的后端用连接名称和参数发起调用。
TypeScript 后端、MCP 工具和 HTTP 调用都能共用同一批账号连接,不用在每个入口重复授权。
TypeScript SDK、oo CLI、MCP 和 HTTP 都能调用同一批账号连接。调用方式可以按场景选择,授权和凭据不用重复做。
用 OOMOL 托管处理授权、凭据和调用,可以更快上线;需要掌控代码、数据和运维时,可以部署到 Cloudflare 或自行部署 OpenConnector。
这些问题覆盖托管方式、凭据位置、调用入口、权限控制和连接状态。
凭据保存在 OOMOL。你的后端通过 SDK、MCP 或 HTTP 调用允许的接口,只需要使用连接名称和参数。
SDK、oo CLI、MCP、HTTP 和 OpenAPI 都能使用同一批连接。按你的产品场景选择接入方式即可。
可以。同一套连接服务可以通过 oo CLI 或 MCP 提供给 Agent 工作流,也可以通过 SDK 或 HTTP 提供给产品后端。具体访问能力仍取决于账号、授权范围,以及你为每个场景开放的 action。
SDK 应该放在可信后端调用。浏览器页面可以发起面向用户的授权流程,但涉及项目凭据、admin token 或敏感连接标识的执行调用,应放在服务端。
不只 OAuth。只要 provider action 支持对应连接类型,OOMOL 可以使用 OAuth、API key、custom credential 和 no-auth provider。OAuth 流程可以等待用户授权;API key 和 custom credential 连接可以同步返回账号。
可以。把 action 暴露给 Agent 或产品功能前,先确认 provider scope、action schema 和连接标签。自部署时,团队还可以控制部署策略、存储、日志和对外发布的接口。
当团队希望减少 OAuth 应用、凭据存储和服务运维负担时,可以用托管版本。
自部署时,团队需要管理 OAuth 应用、API key、runtime 数据库、encryption key、部署、升级、日志和访问控制。这条路径能让你对代码和数据有更多运维控制权。
Connected account 会返回 active、reauthorization required、error、disconnected 等状态。产品可以在调用 action 前检查账号状态,并在授权过期时引导用户重新连接。
不只这些。页面里的 logo 只是示例,OOMOL 可接入 1000+ 个应用和服务,包括 SaaS、开发工具、协作工具、数据系统和 AI 服务。