Question 1

Webhook 处理程序要调用大模型，发送方等到超时了，怎么办？

Accepted Answer

先应答发送方，再调用模型。Slack 等你的 2xx 只等 3 秒，Shopify 等 5 秒，GitHub 等 10 秒；一次大模型调用通常比这更久，于是发送方重试，处理程序执行两次，最后 Slack 或 Shopify 会把这个 Webhook 关掉。放在 AnyHook 后面，发送方约 1 秒就能收到 200，你的处理程序有 Free 60 秒、Pro 120 秒、Scale 5 分钟来完成调用，失败会重试，也不用自己搭队列。指南：https://anyhook.net/zh-cn/blog/llm-webhook-handler-timeouts

Question 2

为什么不用 SQS + Lambda + DynamoDB 自己搭一套？

Accepted Answer

可以，但你要承担幂等状态机、每个平台各自的签名验证器、密钥轮换、可搜索的事件日志，还有值班。基础设施每月 $50–$200；真正的成本是每月 $3,000–$5,000 的工程师时间。AnyHook Pro 套餐 $20/月，零维护。

Question 3

价格表里的“投递超时”指的是什么？

Accepted Answer

这是两个不同的计时。Stripe 的计时针对的是到你的公网 URL 的连接；指向 AnyHook 后，Stripe 约 1 秒就能从我们的边缘节点收到 2xx。“投递超时”这一行是我们的投递计时，也就是我们等待你的端点的时长（Free 60 秒、Pro 120 秒、Scale 5 分钟）。更耗时的任务，返回 202 Accepted，然后异步处理。

Question 4

它和 Zapier、Make 有什么区别？

Accepted Answer

Zapier/Make 是带可视化编辑器的低代码自动化平台。AnyHook 是面向开发者的转发服务：你的 Webhook、你的端点、你的代码。写代码处理 Webhook？用 AnyHook。在 n8n、Make 或 Zapier 里搭流程？把 AnyHook 放在工作流的 Webhook 触发器前面，工作流宕机期间到达的事件会等你重放，而不是凭空消失。

Question 5

如果 AnyHook 自己宕机了怎么办？

Accepted Answer

我们先把事件写入持久化队列，再向发送方返回 200。如果我们的转发器宕机，事件会在队列里等待，恢复后再发出。如果边缘节点完全无法保存一个事件，它会改为返回 503，由发送方自己的重试兜底：AnyHook 从不为没有保存下来的事件返回 200。可用性数据见 status.anyhook.net。

Question 6

我的 AI 智能体要 5–10 分钟才能响应，这样行吗？

Accepted Answer

行，这正是 AnyHook 的用途。不管你的智能体要多久，我们都会约 1 秒应答 Stripe。你的端点应该立即返回 202 Accepted，然后异步处理。AnyHook 的投递超时只作用于最初那一次 HTTP 往返。

Question 7

要等业务逻辑跑完，再给 Stripe 返回 200 吗？

Accepted Answer

不要。Webhook 一通过验证就返回 200，然后异步执行业务逻辑。这是 Stripe 推荐的做法。重试和重放由 AnyHook 在你这一侧处理，而不是逼 Stripe 重发。

Question 8

AnyHook 不适合哪些场景？

Accepted Answer

AnyHook 处理的是异步事件 Webhook，约定是快速返回 2xx。它不适合需要特定响应体的同步控制类 Webhook，例如 Twilio Voice（TwiML）、Discord Interactions（JSON UI）、Shopify Carrier Shipping（实时运费）。这些平台的标准事件 Webhook 依然可用。

Question 9

异步智能体端点该怎么正确接入 AnyHook？

Accepted Answer

你的端点立即返回 202 Accepted，然后异步处理任务。AnyHook 收到 202 就把投递标记为成功。如果你等智能体完成后才返回 200，长任务就会触发重试；解决办法是 202 + 异步。

Question 10

宕机之后能重放事件吗？

Accepted Answer

能，有三种方式：在控制台里对任意事件点击 Replay；用 POST /api/v1/events/{id}/replay 重放单个事件；或用 POST /api/v1/apps/{slug}/replay-failed 批量重放某个 App 的失败事件，每次调用最多 100 个。重放会带上 is_replay:true 标记，不计入配额；只有超出配额后被暂存的事件例外，它在重放时计一次。

Question 11

接入 AnyHook 之前就失败的 Webhook，它能找回来吗？

Accepted Answer

不能。AnyHook 只保存到达它的事件，从你把平台指向你的 AnyHook URL 那一刻开始。在那之前失败的事件，只存在于平台那边。以 Stripe 为例，它会对失败的 live 模式事件持续重试最多三天，你也可以在它的控制台里手动重发 15 天内的事件。

Question 12

如果我的端点返回 400 或 422，AnyHook 还会重试吗？

Accepted Answer

不会，这是有意为之。可重试：5xx、408、429 和网络错误。不可重试：3xx（不跟随重定向）和除 408/429 以外的所有 4xx。400 或 422 说明请求体或鉴权有问题；重试不会改变结果，只会拖慢修复。问题修好之后，失败的事件可以在套餐的重放窗口内重放。

Question 13

如果一分钟内来了 10,000 个 Webhook，AnyHook 会把我的服务器冲垮吗？

Accepted Answer

默认情况下，事件到得多快，AnyHook 就转发得多快。在 Pro 和 Scale 套餐上，你可以为每个转发目标设置投递限流（每秒投递数上限）；超出的事件在队列里等待，按顺序发出，不会丢弃任何事件。你的服务器也可以返回 429 并带上 Retry-After，AnyHook 会退避。

Question 14

我的服务器宕机了会怎样？

Accepted Answer

到达 AnyHook 的事件都不会丢失。AnyHook 按自己的计划重试（5 分钟 → 30 分钟 → 3 小时 → 18 小时，之后每天一次），直到用完你的套餐的尝试次数（Free 3 次，Pro 5 次，Scale 10 次）。某个转发目标出现第 1 次和第 5 次连续失败时，你会收到邮件；连续失败 20 次后，熔断器会暂停该转发目标，同时新事件照常保存。服务器恢复后，App 页面上的失败事件横幅或 POST replay-failed（每次最多 100 个）会按从旧到新的顺序发出失败的事件，用量计入你的套餐的每日重放上限。

Question 15

我的 Webhook 请求体数据安全吗？

Accepted Answer

数据经过传输加密（TLS）和静态加密。在你的套餐的重放窗口内可以重放（3 / 30 / 90 天），之后 Free 套餐的事件会被永久删除，付费套餐的事件则转入只读的加密归档，保存到套餐的保留期结束（Pro 1 年，Scale 7 年）。请求体数据从不用于训练模型。密钥加密存储，从不出现在日志里。

Question 16

超出每月事件上限会怎样？

Accepted Answer

Pro 套餐：每 1,000 个事件 $0.15。Scale 套餐：每 1,000 个事件 $0.17。在 Settings 中设置每月支出上限（$5–$50），达到上限后，后续事件会被暂存（已保存、不投递），直到你提高上限或到了下个月重新计算，最多再暂存配额的 20%；超过之后，边缘节点会返回 429 拒收。超额计费可以按 App 开关。Free 套餐：10,000/月，1,000/天，没有超额计费。超过每日上限的事件会被拒收；超出月度配额的事件会被暂存（最多再暂存配额的 20%），升级后即可重放。

Question 17

AnyHook 能用于本地开发吗？

Accepted Answer

能。把转发目标指向内网穿透地址（ngrok、cloudflared、localhost.run）。更好的做法是让 AnyHook 捕获真实的生产环境事件，再重放到你的 localhost：在每日重放上限内用真实数据测试，也不用手动触发事件。

Question 18

我的 Webhook 来源不在支持列表里，还能用吗？

Accepted Answer

能，AnyHook 支持任何 HTTP POST Webhook，不只是那 22 个可自动识别的平台。创建 App 时选择“Generic”。AnyHook 会接收每一个发来的 POST，逐字节转发原始请求头和请求体，并附加 AnyHook-Signature 请求头，让你的端点可以验证这次转发。Generic 类型的 App 不验证收到的请求的签名，所以要保留你自己对发送方原始请求头的验证；使用 Standard Webhooks 的发送方（OpenAI、Replicate）可以改选这个来源，在边缘节点完成验证。配置时的验证握手，比如 Meta 的 GET hub.challenge 校验，会自动应答。

Question 19

请求体大小有上限吗？

Accepted Answer

有，按事件计：Free 512 KB，Pro 2 MB，Scale 4 MB，Enterprise 定制。超出上限的请求会在边缘节点收到 413 Payload Too Large：不会被悄悄丢弃，不入队，也不计费。Stripe 事件通常是 2–8 KB；这些上限覆盖了 99% 以上的 Webhook 请求体。

Question 20

我的端点怎么验证转发过来的请求是合法的？

Accepted Answer

三层验证：（1）平台的原始请求头（Stripe-Signature 等）原样转发，首次投递时你现有的 SDK 验证可以直接通过；（2）按转发目标附加自定义请求头（Authorization、x-api-key），密钥经过静态加密；（3）每个请求都带 AnyHook-Signature 请求头，用每个转发目标各自的密钥生成带时间戳的 HMAC-SHA256 签名，生产环境推荐使用。

Question 21

为什么不直接在我的服务器上验证 Stripe/GitHub 的原始签名？

Accepted Answer

对 GitHub、Shopify 和 LINE 来说可以：它们只对请求体签名，所以原始签名每次重试都能通过。对 Stripe、Slack 等连同时间戳一起签名的发送方，重试会失败：这些平台会拒绝超过约 5 分钟的签名，而 AnyHook 的重试发生得更晚。AnyHook 在边缘节点验证一次平台签名，然后用新的 AnyHook-Signature 和当前时间戳为每次投递重新签名，你的服务器只需验证一个永不过期的请求头。

Stripe 发出了。你错过了。它还在这里。

发送方会放弃。你的处理程序会执行两次。

只改一个 URL。

看清每个事件。

面向 AI 智能体的 API。

流量看得清，也完全由你控制。

去掉各家 SDK。只验证一个请求头。

你的服务器宕机了。
什么都不会丢。

为开发者而做。

发送方会重试。你的智能体会运行两次。

简单的定价。

常见问题，一一解答。

你的服务器不再响应时，每个发送方会怎么做。

只改一个 URL。之后的每个 Webhook，都保存下来。