osFoundry / Platform
出站 webhook
将平台事件扇出到您自己的端点。自动重试、签名校验。
简介
出站 Webhook 让 osFoundry 把事件主动推送到你所控制的端点。你无需反复轮询来发现变化，只要注册一个 URL，每当工作区中发生相关事件，osFoundry 就会向该 URL 发起一次 HTTP 请求。这样一来，聊天、智能体、应用、代码、知识与数据各个界面上的动态，就变成了你自己的系统可以据以行动的信号，而不必为每一种情况各自搭建定制集成。
在 osFoundry 中，Webhook 位于「设置与安全」之下，因为它跨越了一道信任边界：它把工作区事件送到你所拥有的接收方那里。每一次投递都带有签名，因此你的端点可以校验请求确实来自 osFoundry，且在传输途中未被篡改。在信任消息体之前，请用你的共享密钥核对签名。因端点宕机、响应缓慢或返回错误而失败的投递会自动重试，而不会被丢弃，这样你这一侧的短暂故障就不会悄无声息地丢失事件。由于 osFoundry 采用本地优先（local-first）与自带密钥（BYOK），Webhook 是把数据向外发送的一种有意为之、需主动开启的方式：由你决定哪些端点接收事件，载荷只会流向你所指定的地方。
它真正的价值在于解耦。你的通知服务、工单系统、数据仓库或某个内部自动化流程，既不必运行在 osFoundry 之内，也无需持有 osFoundry 的凭据，只需对外暴露一个 HTTPS 端点，能够校验签名并返回成功状态即可。正是签名校验加上自动重试，才让这个端点值得信任、可以依赖，而这也正是一个能承载工作流的 Webhook 与一个需要你时时照看的 Webhook 之间的区别。
主要功能
- 注册你自己的 HTTPS 端点，在事件发生的当下即时接收平台事件，无需维护轮询循环
- 每个载荷都带有签名，接收方在处理之前即可校验请求确实源自 osFoundry
- 投递失败会自动重试，下游的一次故障不会悄无声息地丢弃事件
- 在「设置与安全」之下管理，是按端点、需主动开启、由你完全掌控的出站通道
- 契合本地优先与 BYOK 模型：数据只会流向你明确指定的端点
使用场景
- 平台工程师：把工作区事件转发到内部自动化服务，既不必向其提供 osFoundry 凭据，也无需将其嵌入应用之内
- 运维/值班：将事件接入现有的告警或通知系统，让相关人员实时获知动态
- 数据团队：把事件流式传输到数据仓库或 ETL 端点，让外部记录与工作区中发生的一切保持同步
常见问题
我该如何校验一个 Webhook 请求确实来自 osFoundry？
每次投递都带有签名。你的端点用共享密钥对请求体重新计算签名，再与 osFoundry 发来的签名比对。若两者不一致，就拒绝该请求。正是这一步阻止了第三方向你的端点伪造事件。
如果事件触发时我的端点正好宕机，会发生什么？
osFoundry 会自动重试该投递，而不会将其丢弃，因此你这一侧的短暂故障或一次部署不会让你丢失事件。端点在接收完载荷后，应返回一个成功状态。
使用 Webhook 会把我的数据发送到某个由 osFoundry 控制的地方吗？
不会。osFoundry 采用本地优先与 BYOK，Webhook 是向你所注册端点的出站发送。事件只会流向你所配置的 URL，而哪些端点存在也由你掌控。这是一种需主动开启的方式，用于把特定事件送往你本就拥有的系统。