Webhook
一种HTTP回调机制，当特定业务事件发生时，系统自动向指定URL发送POST请求，常用于实现系统间的事件驱动集成
核心事实
时间轴 (近 90 天)
把 Webhook 事件当作日志记录是一种浪费，事件的价值在于触发行动而不是存档。
WorkOS 会在 SAML 证书临近过期时主动推送 webhook 事件。
在 Webhook 处理中，由于网络重试或事件重复投递，同一证书过期事件可能被多次接收。
当平台不可用时，依赖其 API 和 Webhook 的自动化流水线会同步失效，影响范围远超不能访问网页。
OpenMail 支持通过 Webhook 或 WebSocket 将入站邮件推送到开发者代码。
Webhook地址等同于口令，泄露后任何人都能向群聊发送消息，建议存储在环境变量或配置文件中。
微信通知机器人通过Webhook发送JSON Payload实现消息推送，常见于企业微信群机器人或第三方中转服务。
在Agent系统中，Webhook让外部世界的变化直接成为Agent的启动信号；cron是基于时间表的定时触发器，适合周期性任务；两者结合可覆盖事件驱动与时间驱动两类自主触发场景。
Webhook 自动注册依赖服务商通过 API 提供以编程方式创建、更新和删除 Webhook 订阅的能力。
在 Vercel 无状态函数模型下处理 Webhook 时，事件可能重复投递，处理逻辑需要具备幂等性。
还有 40 条时间轴事件
全部知识事实 (20)
事件触发依赖 Webhook 机制——外部应用在事件发生时向 N8N 提供的 URL 发送 HTTP 请求，N8N 收到后即启动对应 Workflow。
75%已验证Webhook本质上是一个HTTP回调，仓库检测到代码推送等事件后向预配置的URL发送POST请求
75%已验证Webhook 是一种反向 API，不是由 n8n 主动请求外部服务，而是对外提供一个专属 URL，任何服务向该地址发起 HTTP 请求时即可触发 n8n 工作流。
70%已验证与轮询相比，Webhook不需要接收方按固定间隔反复查询数据源，因此延迟更低、资源开销更小。
65%已验证Webhook 签名验证通常使用 HMAC-SHA256 算法，签名覆盖时间戳与请求体内容，接收方用共享密钥本地重算签名并比对。
65%已验证Webhook请求可能因超时、重试或消息队列的至少一次投递（at-least-once delivery）语义而被重复发送
65%已验证Webhook必须经过签名验证，否则任何人都可以伪造请求来唤醒智能体，带来安全风险
65%已验证在n8n中，工作流（workflow）内放置的每一个功能单元叫做节点（node），通过连接节点让流程运行
65%已验证n8n的Webhook触发节点分为测试URL（test）和生产URL（production）两种模式，测试URL路径中带有test字样，主要用于配合Execute Workflow按钮进行开发阶段调试
65%已验证Webhook触发器适合需要实时响应外部事件的场景，而定时触发节点适合批量处理、定期同步等场景
65%已验证与轮询方式相比，webhook 无需客户端反复查询状态，延迟更低、资源消耗更少
65%已验证n8n支持三类触发器：Webhook触发、轮询触发、定时触发(按Cron表达式执行)
65%已验证IMAP采用轮询模式，客户端定期主动查询服务器是否有新邮件，而Webhook采用推送模式由服务端主动发送HTTP POST请求
65%已验证Webhook 是一种反向 API 机制，业务系统在状态变更时向预先注册的 URL 发送 HTTP POST 请求，延迟通常在秒级以内
65%已验证Webhook 采用推送模型，当源系统发生事件时主动向目标 URL 发送 HTTP POST 请求，相比轮询（Polling）模式在延迟和资源消耗上有显著优势
65%已验证n8n回传结果时应使用HTTP请求节点而非Respond to Webhook节点
65%已验证如果在Webhook回调阶段才扣除积分，用户积分不足时任务已经完成，AI算力已消耗但积分无法扣除
65%待验证在AI SaaS架构中，n8n工作流通过Webhook与前端通信，而非通过表单触发
90%待验证飞书提供完整的机器人消息推送接口，允许外部系统通过HTTP请求将结构化内容直接发送到指定群组或文档
90%待验证成熟的系统通常采用Webhook加轮询兜底的双重机制来确保任务状态获取的可靠性
85%