用途：接收 Exa Monitor 事件，通过已验证签名、防重放、去重和快速确认来处理 Webhook 投递，适用于运营或审查该 Exa 集成。
主要能力：Monitors 按计划执行重复搜索、对先前结果去重，并投递到 HTTPS 公共 Webhook。创建 Monitor 时仅返回一次 webhookSecret。Exa-Signature 携带 timestamp 与 v1 值，用于对签名载荷做 HMAC-SHA256 校验；不跟随重定向。
使用方式：常规 REST 调用从服务端密钥管理器注入 EXA_API_KEY，仅以 Authorization: Bearer 发往配置的第一方 Exa API 主机。创建或轮换 Monitor 需经批准的查询、计划、目标与预算；立即将一次性 webhook 密钥存入接收方密钥库；解析前用常量时间比较校验原始请求体的时间戳与 HMAC；拒绝过期、畸形、未签名、被重定向或无法识别的投递；按稳定的事件与运行标识去重，快速确认并入队处理；与 Monitor run API 对账并保留不含内容的证据。
限制与边界：团队管理服务密钥、托管 MCP OAuth 或企业托管授权、支付协议调用属于不同信任模型。切勿打印、提交、放入 URL 或向不可信客户端暴露凭据。涉及敏感意图的实时查询、生产凭据、花费或速率限制变更、强制实时抓取、生成摘要、外部投递、部署、成员或密钥变更、计划创建或破坏性取消/停止/删除/撤销，均需有责任负责人批准。仅只读仓库检查与合成离线验证不授权实时供应商操作。
失败模式：不得从重新序列化的 JSON 重建签名；若创建时未存储密钥则之后无法获取；仅收到 Webhook 不能证明下游处理或 Monitor 运行已完成。输出应包含操作范围、环境、团队与产品面、授权类别、契约与策略决策、确定性验证结果、无内容标识符、状态与成本计数、风险、清理或回滚状态及简明通过/失败回执，排除凭据、原始查询、提示、预签名 URL、检索内容、生成输出与客户衍生数据（除非另行批准）。