Webhook on your landing pages
Most lead gen stacks have a tax in the middle: a Zap or a scenario whose only job is to move a lead from the page to an endpoint that would have taken it directly. Every lead pays for that hop in tasks or credits, and every hop is one more place a lead can stall while a buyer waits.
LanderLab's Webhook integration removes it. Each page sends its leads straight to any HTTPS endpoint: a buyer's posting URL, your own lead API, a CRM's endpoint, a tracker's postback. You decide the method, the format, the headers and the exact body, so the other side gets the lead the way its docs ask for it.
It's the integration behind most of the tools on this site that don't have their own entry, and it's the one to reach for when a buyer sends you a spec sheet.
Why a direct webhook beats paying for middleware
A lead that goes page, then Zap, then buyer depends on two systems and gets billed by one of them. On a high-volume offer, the automation plan grows with your lead count even though nothing interesting happens in the middle: the Zap receives a lead and posts it somewhere else.
A direct webhook is the same post without the hop. The lead goes from the page to the endpoint on submit, under your control, with nothing in between to pause, run out of tasks or change its pricing. Keep middleware for the jobs that need several steps; let the webhook carry the ones that don't.
Send leads in the format the other side expects
Buyers and APIs are particular. One wants a flat form post with fields named exactly as in its spec; another wants JSON with the contact nested inside a lead object, the tracking inside another, and a fixed source tag and campaign ID next to them. The webhook does both: a simple field list where you tick fields and rename each key, or a JSON body you write yourself with nested objects, arrays and static values.
Methods cover GET, POST and PUT, bodies go as JSON or URL-encoded form data, and custom headers carry an API key or a token, so credentials never sit in the URL.
Compliance and attribution fields on every lead
LanderLab adds its own fields to every lead: the full page URL, the visitor's IP and user agent, the submission time in UTC and the A/B variant shown. Those are the fields a buyer checks when a lead is disputed, and the ones you need to prove where a lead came from.
Add hidden fields named like your URL parameters, such as utm_campaign, gclid or a tracker's click ID, and they're saved with the lead and sent with it too. The buyer gets the attribution, and you can judge each variant on accepted leads rather than raw form fills.
Postbacks and pings with GET
Not every destination wants a body. A tracker postback, an affiliate network's conversion URL or a simple ping takes its data in the query string, and a GET webhook sends the mapped fields exactly that way: the click ID under the parameter name the tracker expects, a static payout or status beside it. The conversion goes back to the campaign that paid for it on submit.
When to use a workflow instead
A webhook sends every lead from its page. When only some leads should go, such as US leads to one buyer, the rest to another, or a follow-up after a Delay, LanderLab's Workflows (beta) has the same kind of request as an HTTP Request node, behind Filter, If and Switch nodes, with a Runs view that shows each lead's path and any failed step.
Either way, the lead is also stored in LanderLab's Leads tab, so an endpoint that was down doesn't cost you the lead, unless Lead Compliance Delivery is on, which skips storage by design.
