POST。开发者使用 Webhook 来响应 Alforse 中的变更，而无需轮询 API。
Webhook 的工作方式
- 每个 Webhook 监视一张表和一种或多种触发操作。
- 发生匹配的变更时，Alforse 会将一次投递加入队列并异步发送，通常在片刻之内。
- 每次投递都用属于该 Webhook 的密钥签名，因此您的端点可以证明请求来自 Alforse。
- 请求正文是一条记录已变更的通知。在据此采取行动之前，请使用 API 密钥获取当前记录。
可订阅的表
请以 Webhook 表单中的表下拉列表为准，了解您的部署接受哪些表。触发选项也取决于表，因为一张表只发布部分操作：
receipt 发布插入和删除，employee 只发布更新。
设置 Webhook
前往设置 → Webhooks 创建和管理 Webhook。填写以下字段：
Alforse 拒绝向环回地址、私有网络地址、链路本地地址和云元数据地址投递。这可以防止 Webhook 被用来访问内部系统。
Webhook 列表显示每个 Webhook 的成功次数和错误次数，根据投递尝试统计。
一次投递包含什么
正文
正文是包含四个字段的 JSON：标头
请将事件 ID 用作幂等键。一次变更在其所有重试中保持同一个事件 ID，而每个新的变更都会得到新的事件 ID，包括对您已经收到通知的记录的第二次更新。
投递与重试
投递为至少一次。当您的端点出现以下情况时，Alforse 会将该次尝试视为失败，并以指数退避方式重试，最多 8 次：- 未在 10 秒内返回成功状态，或
- 返回
5xx或429。
- 任何其他
4xx响应都会终止该变更的投递。 3xx响应算作失败，因为 Alforse 不会跟随重定向。请配置最终的 URL。- 向被拒绝的地址投递不会重试。
设计您的端点
- 预期会有重复。 重试可能在您已处理第一次尝试之后到达。请基于
x-omeriva-webhook-event去重，而不是基于type加record.id，因为对同一记录的不同变更共享这些值。 - 中断之后进行对账。 被丢弃的变更不会重放。如果您必须处理每个事件，请在端点停机之后查询 API 来追赶进度。
验证投递
创建 Webhook 的同时会生成一个专属于它的签名密钥，Alforse 对其加密保存。x-omeriva-webhook-signature 中的签名是 `${timestamp}.${body}` 的十六进制 HMAC-SHA256，以该密钥字符串为密钥。timestamp 是 x-omeriva-webhook-timestamp 的值，body 是原始请求正文。
验证投递的步骤：
- 在解析之前捕获原始正文。解析并重新序列化 JSON 会改变字节，使签名失效。
- 计算 HMAC，并使用恒定时间比较，将其与
v1=之后的值比较。 - 拒绝与您的时钟相差超过五分钟的任何时间戳，以防捕获的请求被重放。每次重试都会用新的时间戳重新签名，因此合法的重试仍可通过。