Zapier 路由 Webhook 网关

要解决什么问题

Webhooks by Zapier 的 catch 端点（形如 hooks.zapier.com/hooks/catch/<hook-id>）一旦开始接收第三方 SaaS 的回调，问题就会集中冒出来：各家 SaaS 的 payload 结构并不统一，同一个 Zap 里相邻两步对字段命名的预期也经常对不上；你以为会收到一个 JSON 对象，实际拿到的是一段 text/plain 原始字符串。Zapier 界面里的运行记录只能告诉你「哪一步挂了」，很难把原始请求完整拎出来对照。

它如何工作

路由：把发往 catch 端点的入站流量按目标 Zap 分流，避免多个端点共用同一套处理逻辑时互相干扰。

校验：检查请求的方法、路径与 payload 是否符合该触发器的契约，把明显的畸形请求挡在链路之外。

标准化：把异构的请求体收敛成统一形状，让后续步骤按固定字段读取，而不必为每一个上游 SaaS 单独写一遍适配。

调试：串起跨多个 Zap 的调用链，定位到底是哪一段的入参或出参不符合预期。

大致流程：接收入站请求 → 解析并校验触发契约 → 按路由分发 → 输出标准化 payload 给下游步骤。

适用边界与注意点

• 只覆盖 Webhooks by Zapier 这一类触发器，不涉及 Zapier 原生触发器或定时轮询。
• 上游仓库没有给出可用的安装与使用说明，实际行为需要你自己审阅源码后再确认，不要直接放进敏感流程。
• 它解决的是「看清流量长什么样」，不会替你改写上游 SaaS 的发送格式。