Webhook
一种HTTP回调机制，当特定业务事件发生时，系统自动向指定URL发送POST请求，常用于实现系统间的事件驱动集成
核心事实
时间轴 (近 90 天)
微信通知机器人通过Webhook发送JSON Payload实现消息推送，常见于企业微信群机器人或第三方中转服务。
Webhook地址等同于口令，泄露后任何人都能向群聊发送消息，建议存储在环境变量或配置文件中。
在Agent系统中，Webhook让外部世界的变化直接成为Agent的启动信号；cron是基于时间表的定时触发器，适合周期性任务；两者结合可覆盖事件驱动与时间驱动两类自主触发场景。
在 Vercel 无状态函数模型下处理 Webhook 时，事件可能重复投递，处理逻辑需要具备幂等性。
Webhook 自动注册依赖服务商通过 API 提供以编程方式创建、更新和删除 Webhook 订阅的能力。
告警验证动作可以绑定到 webhook 目的地而非全局开关，使得同一 monitor 可以并行配置多个目的地：一个带 Critical Only 过滤的呼叫通道，以及一个接收全量告警的归档通道。
事件驱动架构（如Webhook或消息队列）是唤醒智能体的更优雅方案，但要求智能体平台提供回调接口，而目前多数个人助手并未开放此类能力。
Linear和Jira都提供API与Webhook，允许外部工具读取任务状态、更新工单或嵌入链接。
调度器负责按时间或事件触发Agent运行，如cron定时器、Webhook，使Agent能脱离人工指令在后台周期性执行任务。
对于已有 CI 流水线的团队，API 方式比 Webhook 更适合做安全门禁控制。
还有 40 条时间轴事件
全部知识事实 (20)
事件触发依赖 Webhook 机制——外部应用在事件发生时向 N8N 提供的 URL 发送 HTTP 请求，N8N 收到后即启动对应 Workflow。
75%已验证Webhook本质上是一个HTTP回调，仓库检测到代码推送等事件后向预配置的URL发送POST请求
75%已验证Webhook 是一种反向 API，不是由 n8n 主动请求外部服务，而是对外提供一个专属 URL，任何服务向该地址发起 HTTP 请求时即可触发 n8n 工作流。
70%已验证Webhook 签名验证通常使用 HMAC-SHA256 算法，签名覆盖时间戳与请求体内容，接收方用共享密钥本地重算签名并比对。
65%已验证Webhook必须经过签名验证，否则任何人都可以伪造请求来唤醒智能体，带来安全风险
65%已验证Webhook请求可能因超时、重试或消息队列的至少一次投递（at-least-once delivery）语义而被重复发送
65%已验证在n8n中，工作流（workflow）内放置的每一个功能单元叫做节点（node），通过连接节点让流程运行
65%已验证Webhook触发器适合需要实时响应外部事件的场景，而定时触发节点适合批量处理、定期同步等场景
65%已验证n8n的Webhook触发节点分为测试URL（test）和生产URL（production）两种模式，测试URL路径中带有test字样，主要用于配合Execute Workflow按钮进行开发阶段调试
65%已验证与轮询方式相比，webhook 无需客户端反复查询状态，延迟更低、资源消耗更少
65%已验证n8n支持三类触发器：Webhook触发、轮询触发、定时触发(按Cron表达式执行)
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%待验证积分预检和积分扣除是两个独立的环节，预检在任务提交前拦截积分不足的请求，扣除在Webhook回调时执行
85%待验证在典型的AI SaaS架构中，主流做法是客户端提交任务后立即获得任务ID，后端异步处理，处理完成后通过Webhook回调通知结果
85%