☰

企业官网建设流程全解析

首页 / 建站日记 / 企业官网建设流程全解析
自带 OAuth 应用时如何注册 Composio ingress URL 让实时触发器收到事件
2026/9/12 15:35:52 网站建设 项目流程

自带 OAuth 应用时如何注册 Composio ingress URL 让实时触发器收到事件

【免费下载链接】composioComposio powers 1000+ toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composio

如果你用的是 Composio 托管的 OAuth，可以直接跳过这篇——ingress 已经配好，创建触发器后事件就会流动。本文针对另一种情况：你自带（BYO）自己的 OAuth 应用，且目标触发器类型是实时（realtime）触发器。有些 provider 只把事件推送到你在 OAuth 应用上注册过的 URL，所以要把 Composio 的 ingress URL 注册到该 OAuth 应用里一次，事件才能进入 Composio。判断标准是触发器类型的requires_webhook_endpoint_setup标志为true，只有这种触发器需要做这一步。

每个你自带的 OAuth 应用在一个项目内拥有自己的 ingress URL：

https://backend.composio.dev/api/v3.1/webhook_ingress/{toolkit_slug}/{we_xxx}/trigger_event

其中{toolkit_slug}是工具包标识，{we_xxx}是 webhook endpoint 的 ID。注意一条硬性约束：一个 OAuth 应用最多服务一个 Composio 项目——provider 只接受每个 OAuth 应用一个 callback URL，每个 ingress URL 也只路由到单个项目。如果同一个 OAuth 应用被多个项目共用，先合并到单个项目，或按项目分别注册 OAuth 应用再继续。

每个项目因此成为独立的 webhook 租户，拥有自己的 ingress 速率限制与背压预算、项目范围内的凭据（签名密钥和 app-level token 只存储在该项目）、事件只扇出到该项目触发器实例的干净投递路径，以及按项目计量的能力。所有入站事件在触发任何触发器之前都会在 ingress 做签名校验：Slack 使用 HMAC-SHA256，其他 provider 使用 Ed25519 或共享 token 匹配；provider 对请求时间戳签名时，超出允许偏移窗口的请求会被拒绝；未签名或被篡改的请求在 ingress 以400拒绝。

准备条件

  • 一个 Composio API key，用于请求头x-api-key；
  • 你在 provider 侧自建 OAuth 应用的client_id；
  • 该 OAuth 应用只绑定一个 Composio 项目；
  • 用户在 Composio 中有该 toolkit 的 connected account（创建触发器时需要，见 Authentication）；
  • 各 provider 应用后台的凭据（如 Slack 的 Signing Secret），具体要哪些以 Step 1 返回的setup_fields为准。

下文以 Slack 为例，完整参考 Webhook Endpoints API；各 toolkit 特有的设置说明见其 FAQ 部分，例如 Slack。

Step 1: 查询 endpoint 需要哪些凭据

对目标 toolkit 调用 schema 端点。响应里的setup_fields精确告诉你需要从 provider 应用后台收集哪些字段：

curl "https://backend.composio.dev/api/v3.1/webhook_endpoints/schema?toolkit_slug=slack" \ -H "x-api-key: <YOUR_COMPOSIO_API_KEY>"

文档示例的响应：

{ "toolkit_slug": "slack", "setup_fields": { "webhook_signing_secret": { "display_name": "Signing Secret", "description": "Webhook request signing secret from your Slack app dashboard", "is_required": true, "is_secret": true }, "app_token": { "display_name": "App-Level Token", "description": "Slack xapp- token with authorizations:read scope for event authorization", "is_required": true, "is_secret": true } } }

以 Slack 为例，这两个凭据的来源是：Signing secret 在 Slack app → Basic Information → App Credentials → Signing Secret；App-level token 在 Slack app → Basic Information → App-Level Tokens，需要authorizations:readscope，直接消息、私有频道和 reaction 事件需要它，只处理公开频道事件时省略。

Step 2: 创建 endpoint，拿到 ingress URL

用toolkit_slug和 OAuth 应用的client_id创建 endpoint（<YOUR_OAUTH_CLIENT_ID>换成你 OAuth 应用的 client ID）：

curl -X POST "https://backend.composio.dev/api/v3.1/webhook_endpoints" \ -H "x-api-key: <YOUR_COMPOSIO_API_KEY>" \ -H "Content-Type: application/json" \ -d '{ "toolkit_slug": "slack", "client_id": "<YOUR_OAUTH_CLIENT_ID>" }'

文档示例的响应：

{ "id": "we_abc123", "toolkit_slug": "slack", "client_id": "<YOUR_OAUTH_CLIENT_ID>", "webhook_url": "https://backend.composio.dev/api/v3.1/webhook_ingress/slack/we_abc123/trigger_event", "data": null, "created_at": "2026-04-24T10:00:00.000Z" }

保留响应中的两个值：id（下文记为<ENDPOINT_ID>，如示例中的we_abc123）和webhook_url（Step 4 要粘贴进 provider 应用后台）。这个调用在同一项目内对(toolkit_slug, client_id)组合是幂等的：用同一对参数再次调用会返回已存在的 endpoint，不会轮换 URL 也不会清掉已存的 secret。

Step 3: 存好 schema 要求的凭据

把 Step 1 schema 返回的所有字段放在一个PATCH请求里提交。对 Slack 就是 signing secret 和（需要时）app-level token 一起提交（<SIGNING_SECRET>换成 provider 后台的签名密钥，xapp-...换成你的 app-level token）：

curl -X PATCH "https://backend.composio.dev/api/v3.1/webhook_endpoints/<ENDPOINT_ID>" \ -H "x-api-key: <YOUR_COMPOSIO_API_KEY>" \ -H "Content-Type: application/json" \ -d '{ "data": { "webhook_signing_secret": "<SIGNING_SECRET>", "app_token": "xapp-..." } }'

**必须在 Step 4 切换 provider 的 callback URL 之前完成这一步。**如果 provider 向 URL 发请求而 endpoint 上还没有 secret，每个请求都会以400失败，并且 provider 可能在连续失败一段时间窗口后自动禁用该 endpoint（Slack 约为 36 小时）。

Step 4: 在 provider 应用后台注册 ingress URL

把 Step 2 响应里的webhook_url粘贴到 provider 的应用后台：

  • Slack→ Event Subscriptions → Request URL
  • Notion→ Webhook Endpoints（在集成设置中）

对于保存时会发起验证 challenge 的 provider（Slack 的url_verification、Notion 的 verification token 等），Composio 会自动应答，你这边不需要写任何握手代码。provider 接受该 URL 后，就可以去 创建触发器。

验证注册是否生效

文档给出的确认与失败信号如下：

  • provider 侧保存 URL 时的验证 challenge 被自动应答、provider 接受 URL，说明 ingress 侧就绪；
  • 用GET查看单个 endpoint，确认其状态与已存凭据：
curl "https://backend.composio.dev/api/v3.1/webhook_endpoints/<ENDPOINT_ID>" \ -H "x-api-key: <YOUR_COMPOSIO_API_KEY>"
  • 列出当前项目全部 endpoint：
curl "https://backend.composio.dev/api/v3.1/webhook_endpoints" \ -H "x-api-key: <YOUR_COMPOSIO_API_KEY>"
  • 反向信号：如果 provider 开始向 URL 发事件而 endpoint 尚未存 secret，请求会全部以400失败——这正是 Step 3 要先于 Step 4 的原因。

URL 被接受后，事件链路是：provider → ingress URL → 触发器 → 你的订阅或 webhook URL。触发器创建要求用户已有该 toolkit 的 connected account，只需传user_id，Composio 自动解析连接。例如用 SDK 创建：

from composio import Composio composio = Composio() user_id = "user-id-123435" # 用户必须先有该 toolkit 的 connected account，先完成认证。 trigger = composio.triggers.create( slug="GITHUB_COMMIT_EVENT", user_id=user_id, trigger_config={"owner": "your-repo-owner", "repo": "your-repo-name"}, ) print(f"Trigger created: {trigger.trigger_id}")

触发器激活后事件开始流动；本地开发可以用subscribe()快速看事件，或推荐用 CLIcomposio dev triggers listen --forward "http://localhost:8000/webhooks/composio"把事件签名后转发到你的本地 handler；生产环境用composio.triggers.set_webhook_subscription(webhook_url=...)注册项目级 webhook URL，handler 里用parse()验签并解析。细节见 Receiving events 和 Triggers。

更新与维护 endpoint

  • 轮换 signing secret 或改单个字段：PATCH该字段，其他字段保留：
curl -X PATCH "https://backend.composio.dev/api/v3.1/webhook_endpoints/<ENDPOINT_ID>" \ -H "x-api-key: <YOUR_COMPOSIO_API_KEY>" \ -H "Content-Type: application/json" \ -d '{ "data": { "webhook_signing_secret": "<NEW_SECRET>" } }'
  • 整体替换data（没包含的字段会被清空）：对同一 URL 发POST：
curl -X POST "https://backend.composio.dev/api/v3.1/webhook_endpoints/<ENDPOINT_ID>" \ -H "x-api-key: <YOUR_COMPOSIO_API_KEY>" \ -H "Content-Type: application/json" \ -d '{ "data": { "webhook_signing_secret": "<NEW_SECRET>", "app_token": "<NEW_APP_TOKEN>" } }'
  • webhook_url在 endpoint 生命周期内不可变；provider 侧轮换 signing secret 是对现有 endpoint 的PATCH，不要创建新 endpoint。

相关文档：Custom OAuth webhooks、Webhook Endpoints API、Creating triggers、Receiving events。

【免费下载链接】composioComposio powers 1000+ toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composio

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

标签： 网站建设 企业官网 项目流程 UI设计 前端开发

热门文章

文章分类

标签云

网站建设 响应式设计 用户体验 SEO优化 前端开发 小程序 电商平台 性能优化

相关文章

您可能感兴趣的其他内容

出海游戏AI买量策略与专属语言引擎实战
2026/9/12 15:35:02 网站建设

出海游戏AI买量策略与专属语言引擎实战

买量成本一路走高&#xff0c;本地化版本又跟不上发行节奏&#xff0c;这两件事几乎是做出海游戏的人都绕不开的坎。过去两年我带着项目组同时推进AI买量策略和自建语言引擎&#xff0c;踩了不少坑&#xff0c;也跑出了一些可复用的打法。这篇文章把我实际落地的经验整理出来&a…...

阅读更多 →
Roo Code 2.2 版本深度解析：MCP 自定义工具、API 配置 Profile 与 Diff 编辑实战指南
2026/9/12 15:35:00 网站建设

Roo Code 2.2 版本深度解析：MCP 自定义工具、API 配置 Profile 与 Diff 编辑实战指南

Roo Code 2.2 版本深度解析&#xff1a;MCP 自定义工具、API 配置 Profile 与 Diff 编辑实战指南 【免费下载链接】Roo-Code Roo Code gives you a whole dev team of AI agents in your code editor. 项目地址: https://gitcode.com/GitHub_Trending/ro/Roo-Code Roo C…...

阅读更多 →
内容没流量？真正原因是缺乏个人品牌：从0到1打造稳定账号
2026/9/12 15:34:25 网站建设

内容没流量？真正原因是缺乏个人品牌：从0到1打造稳定账号

做内容好几年&#xff0c;最怕听到的一句话就是&#xff1a;你这内容挺好&#xff0c;怎么就是没流量。我早期也有过这种状态&#xff1a;很认真写一篇干货&#xff0c;发出去两小时&#xff0c;阅读量还是两位数&#xff0c;而同行随手拍的一个日常&#xff0c;却冲上了热门。…...

阅读更多 →

需要专业的网站建设服务？

联系我们获取免费的网站建设咨询和方案报价，让我们帮助您实现业务目标

立即咨询