客户在表单里按下提交按钮之后，数据不会自己走进自动化流程。它要经过一段看不见的路程，才变成收件箱里的确认邮件和任务清单里的待办。Webhook 是这段路程最常见的入口，常被误解成某个产品的功能，本质上更接近一种约定。

没有 Webhook 时，流程靠轮询运转：自动化工具每隔一段时间去问表单后台有没有新记录。两次询问之间数据是静止的，问得越勤消耗越大，延迟却始终存在。Webhook 把方向反过来——表单工具在提交发生的那一刻，主动向预先登记好的地址发起一次 HTTP POST 请求，把提交内容放进请求体送过去。这个地址由自动化工具生成，n8n 里叫 Webhook 节点，Make 里叫 Custom Webhook；Typeform、Tally、金数据这类支持 Webhook 的表单服务，都能把提交结果推到这里。它的本质是事件通知与数据承载的合并：触发时机由发送方决定，不由你决定；你要准备的只是一个能被找到的地址，和一套能接住数据的处理逻辑。

接住请求之后，先看清数据结构

请求体不是一份稳定的合同。字段名、嵌套层级、时间格式里有没有时区偏移、多选字段是数组还是逗号分隔字符串，都由发送方决定，很多“流程搭好却不生效”的问题根因就在这里。所以第一步不是连线，而是触发一次真实提交，把原始结构看清楚。

看清之后建议先统一一层命名，把表单字段映射成自己的变量：姓名、邮箱、需求类型、预算区间、描述、提交时间。三个细节值得固定下来——邮箱统一转小写并作为去重键；时间统一到同一时区，否则会出现今天提交、显示昨天的错位；长文本先截断，原文另存，别让任务标题变成一整段话。

实时触发的代价

推送模型把一部分可靠性责任转移给了接收方。发送方超时或异常时可能重试，同一次提交就会在流程里出现多次，去重因此不是可选项。失败也不会像轮询那样等到下一轮自动重来，需要被显式记录：发生时间、触发来源、原始数据、失败节点、错误信息、是否已处理。工具自带的执行列表属于工具视角的日志，能说明哪一次执行失败，却回答不了“上周到底漏了几个客户”。

对方不提供 Webhook 时，定时轮询是唯一的兜底手段，只是要接受延迟和重复读取。无论哪种接法，接口变更、发件额度、字段调整带来的维护成本都不会消失。把流程控制在十步以内、分支不超过三条，是让它在半年后仍然可维护的现实做法。