Webhook
一种HTTP回调机制，当特定业务事件发生时，系统自动向指定URL发送POST请求，常用于实现系统间的事件驱动集成
核心事实
时间轴 (近 90 天)
Webhook是WhatsApp触发器的底层机制：用户发送消息时Meta服务器向预先注册的URL发送HTTP POST请求，n8n监听该URL启动工作流
配置Webhook时需填写n8n生成的回调URL并输入自定义验证令牌（Verify Token），Meta通过GET请求握手验证后Webhook才激活
n8n实例必须部署在可被公网访问的服务器上，或借助ngrok等内网穿透工具暴露本地端口，Meta才能成功回调
对于不支持 Webhook 的页面，通常需要用无头浏览器定期抓取页面内容并做差异对比来模拟事件检测
Webhook 是一种事件驱动的 HTTP 回调机制，相较轮询具有实时性更高、服务器资源消耗更低的优势
SendCheck 通过 Webhook 接收 n8n 主流程跑完后发送的最终结果进行校验
SendCheck 的接入成本主要是在流程末尾加一个 Webhook 调用
该语音预约工作流由 Webhook 节点（入口）、日历认证模块、预约记录模块等关键模块串联而成
该演示提供的思路框架为：语音前端 → Webhook 入口 → AI 解析 → 服务认证 → 业务执行 → 结果反馈
Notion的webhook功能目前处于Beta阶段，允许开发者监听数据库的增删改事件
还有 29 条时间轴事件
全部知识事实 (20)
Webhook本质上是一个HTTP回调，仓库检测到代码推送等事件后向预配置的URL发送POST请求
75%已验证与轮询方式相比，webhook 无需客户端反复查询状态，延迟更低、资源消耗更少
65%已验证Webhook 是一种反向 API 机制，业务系统在状态变更时向预先注册的 URL 发送 HTTP POST 请求，延迟通常在秒级以内
65%待验证如果在Webhook回调阶段才扣除积分，用户积分不足时任务已经完成，AI算力已消耗但积分无法扣除
95%待验证在AI SaaS架构中，n8n工作流通过Webhook与前端通信，而非通过表单触发
90%待验证飞书提供完整的机器人消息推送接口，允许外部系统通过HTTP请求将结构化内容直接发送到指定群组或文档
90%待验证成熟的系统通常采用Webhook加轮询兜底的双重机制来确保任务状态获取的可靠性
85%待验证积分预检和积分扣除是两个独立的环节，预检在任务提交前拦截积分不足的请求，扣除在Webhook回调时执行
85%待验证在典型的AI SaaS架构中，主流做法是客户端提交任务后立即获得任务ID，后端异步处理，处理完成后通过Webhook回调通知结果
85%待验证Webhook服务商通常在首次回调超时或收到非2xx响应时自动重试，常见策略是指数退避重试3-5次
75%待验证大多数服务商对Webhook回调有超时限制，通常为5-30秒
70%待验证Replicate、Stability AI等主流AI平台广泛采用Webhook回调的异步通信模式
60%待验证Webhook是WhatsApp触发器的底层机制：用户发送消息时Meta服务器向预先注册的URL发送HTTP POST请求，n8n监听该URL启动工作流
50%待验证n8n实例必须部署在可被公网访问的服务器上，或借助ngrok等内网穿透工具暴露本地端口，Meta才能成功回调
50%待验证配置Webhook时需填写n8n生成的回调URL并输入自定义验证令牌（Verify Token），Meta通过GET请求握手验证后Webhook才激活
50%待验证Webhook 是一种事件驱动的 HTTP 回调机制，相较轮询具有实时性更高、服务器资源消耗更低的优势
50%待验证对于不支持 Webhook 的页面，通常需要用无头浏览器定期抓取页面内容并做差异对比来模拟事件检测
50%待验证SendCheck 通过 Webhook 接收 n8n 主流程跑完后发送的最终结果进行校验
50%待验证SendCheck 的接入成本主要是在流程末尾加一个 Webhook 调用
50%待验证该语音预约工作流由 Webhook 节点（入口）、日历认证模块、预约记录模块等关键模块串联而成
50%