落地页上的 Webhook
大多数线索获取技术栈中间都有一笔“过路费”：一个 Zap 或一个场景，唯一的工作就是把线索从页面搬到一个本来可以直接接收它的端点。每条线索都要为这次中转支付任务数或积分，而每多一次中转，线索就多一个可能卡住的地方，买家只能干等。
LanderLab 的 Webhook 集成把它去掉了。每个页面都把线索直接发送到任意 HTTPS 端点：买家的投递 URL、你自己的线索 API、CRM 的端点、追踪工具的回传。请求方法、格式、请求头和具体的请求体都由你决定，对方收到的线索就是它文档里要求的样子。
本站上大多数没有专属集成的工具，背后用的都是它；买家发来一份规范文档时，你该用的也是它。
为什么直接 Webhook 胜过花钱用中间件
一条线索从页面到 Zap 再到买家，要依赖两个系统，还要被其中一个收费。在大流量的 offer 上，自动化套餐随着线索数量水涨船高，可中间并没有发生什么特别的事：Zap 接收一条线索，再把它发到别处。
直接 Webhook 就是同样的发送，只是少了中转。线索在提交时从页面发到端点，全程由你掌控，中间没有任何会暂停、会用完任务数或会改价的东西。需要多个步骤的任务留给中间件；不需要的，交给 Webhook。
按对方要求的格式发送线索
买家和 API 都很挑剔。有的要扁平的表单提交，字段名必须和它的规范完全一致；有的要 JSON，联系人信息嵌套在一个 lead 对象里，追踪信息嵌套在另一个对象里，旁边还要有固定的来源标签和广告系列 ID。Webhook 两种都能做：一种是简单的字段列表，勾选字段并重命名每个键；另一种是你自己编写的 JSON 请求体，可包含嵌套对象、数组和固定值。
请求方法支持 GET、POST 和 PUT，请求体可以是 JSON 或 URL 编码的表单数据，自定义请求头可以携带 API 密钥或令牌，凭据不会出现在 URL 里。
每条线索都带合规和归因字段
LanderLab 会给每条线索加上自己的字段：完整的页面 URL、访客的 IP 和 User Agent、UTC 格式的提交时间，以及展示的 A/B 变体。线索有争议时，买家核查的就是这些字段；你要证明一条线索的来源，靠的也是它们。
添加与 URL 参数同名的隐藏字段，比如 utm_campaign、gclid 或追踪工具的点击 ID，它们就会随线索一起保存、一起发送。买家拿到归因信息，你也可以按被接受的线索来评判每个变体，而不只看原始的表单提交。
用 GET 发送回传和 ping
不是每个目标端都需要请求体。追踪工具的回传、联盟网络的转化 URL 或一个简单的 ping，都是从查询字符串里取数据，GET Webhook 正好就这样发送映射的字段：点击 ID 用追踪工具要求的参数名，旁边是固定的佣金或状态。提交时，转化就会回传到为它付费的那个广告系列。
什么时候改用工作流
Webhook 会发送其页面上的每条线索。如果只有部分线索该发，比如美国的线索给一个买家、其余的给另一个，或者在延时之后再跟进，LanderLab 的工作流（Beta）提供同样的请求，即 HTTP 请求步骤，可以放在筛选、条件判断和多分支步骤后面，运行视图还会显示每条线索的路径和任何失败的步骤。
无论哪种方式，线索也会保存在 LanderLab 的线索标签页中，端点宕机也不会让你丢掉线索；除非开启了“合规线索投递”，它的设计就是不存储线索。
