在你的登陸頁上使用 Webhook
大多數名單開發工具組合中間都被抽一筆稅：一個 Zap 或情境，唯一的工作就是把名單從頁面搬到一個原本就能直接接收的端點。每筆名單都要為這一站付出任務或點數，每多一站，就多一個名單可能卡住、讓買家乾等的地方。
LanderLab 的 Webhook 整合把這一站拿掉。每個頁面把名單直接送到任何 HTTPS 端點：買家的 posting URL、你自己的名單 API、CRM 的端點、追蹤工具的 postback。方法、格式、標頭和完整內文都由你決定，對方就能照它文件要求的方式收到名單。
本站上大多數沒有獨立整合項目的工具，背後用的就是這個整合；買家丟給你一份規格表時，該用的也是它。
為什麼直接用 Webhook 勝過花錢買中介軟體
一筆先到頁面、再到 Zap、再到買家的名單，要依賴兩套系統，還被其中一套收費。在高量的優惠上，自動化方案會隨名單數量變大，即使中間什麼有意義的事都沒發生：Zap 收到一筆名單，再把它發到別處。
直接的 Webhook 就是同一個 POST，只是少了中間那一站。名單在送出時從頁面直達端點，由你掌控，中間沒有任何東西會暫停、用光任務額度或調整價格。需要好幾個步驟的工作就留給中介軟體；不需要的，交給 Webhook。
用對方要的格式送出名單
買家和 API 都很挑。有的要扁平的表單 POST，欄位名稱與規格完全一致；有的要 JSON，聯絡資料巢狀在 lead 物件裡，追蹤資料在另一個物件裡，旁邊還要一個固定的來源標籤與廣告活動 ID。Webhook 兩種都做得到：簡單的欄位清單，勾選欄位並重新命名每個鍵；或是你自己寫的 JSON 內文，含巢狀物件、陣列與固定值。
方法支援 GET、POST 與 PUT，內文可以是 JSON 或 URL 編碼的表單資料，自訂標頭可以帶 API 金鑰或權杖，憑證就不會出現在網址裡。
每筆名單都附上合規與歸因欄位
LanderLab 會在每筆名單加上自己的欄位：完整頁面網址、訪客的 IP 與 user agent、UTC 送出時間，以及顯示的 A/B 版本。名單被申訴時，買家檢查的就是這些欄位；你要證明名單來源時，需要的也是它們。
加入與網址參數同名的隱藏欄位，例如 utm_campaign、gclid 或追蹤工具的 click ID，它們就會跟名單一起儲存並送出。買家拿到歸因資料，你也能用被接受的名單、而不是原始表單填寫數來評估每個版本。
用 GET 發送 postback 與 ping
不是每個目的地都要內文。追蹤工具的 postback、聯盟網的轉換網址或簡單的 ping，都是從查詢字串取得資料；GET Webhook 正是這樣送出對應好的欄位：click ID 放在追蹤工具要的參數名稱下，旁邊再加上固定的佣金或狀態。送出時，轉換就回到付錢買這次點擊的廣告活動。
什麼時候該改用工作流程
Webhook 會送出頁面上的每筆名單。當只有部分名單該送出時，例如美國名單給一個買家、其餘給另一個，或在「延時」之後再跟進，LanderLab 的工作流程（Beta 版）也有同樣的請求，就是「HTTP 請求」節點，可以放在「篩選」、「條件判斷」與「多分支」節點後面，還有執行紀錄檢視，顯示每筆名單的路徑與任何失敗的步驟。
不論哪種方式，名單都會存在 LanderLab 的「潛在客戶」分頁，所以端點當機也不會讓你損失名單，除非開啟了「合規潛在客戶投遞」，它的設計本來就是不儲存。
