Webhook op je landingspagina's
De meeste leadgenstacks hebben een tolpoortje in het midden: een Zap of een scenario dat alleen een lead van de pagina verplaatst naar een endpoint dat hem ook rechtstreeks had aangenomen. Elke lead betaalt voor die tussenstap in taken of credits, en elke tussenstap is een plek meer waar een lead kan blijven hangen terwijl een afnemer wacht.
De Webhook-integratie van LanderLab haalt die weg. Elke pagina stuurt zijn leads rechtstreeks naar elk HTTPS-endpoint: de posting-URL van een afnemer, je eigen lead-API, het endpoint van een CRM, de postback van een tracker. Jij bepaalt de methode, het formaat, de headers en de exacte body, zodat de andere kant de lead krijgt zoals zijn documentatie erom vraagt.
Het is de integratie achter de meeste tools op deze site die geen eigen pagina hebben, en de integratie die je pakt als een afnemer je zijn specs stuurt.
Waarom een directe webhook beter is dan betalen voor middleware
Een lead die van de pagina naar een Zap en dan naar de afnemer gaat, hangt af van twee systemen en wordt door een van beide gefactureerd. Op een offer met veel volume groeit het automatiseringsabonnement mee met je aantal leads, terwijl er in het midden niets interessants gebeurt: de Zap ontvangt een lead en post hem ergens anders heen.
Een directe webhook is dezelfde post zonder tussenstap. De lead gaat bij het verzenden van de pagina naar het endpoint, onder jouw controle, zonder iets ertussen dat kan pauzeren, door zijn taken heen kan raken of zijn prijzen kan veranderen. Houd middleware voor de taken die meerdere stappen nodig hebben; laat de webhook de rest dragen.
Stuur leads in het formaat dat de andere kant verwacht
Afnemers en API's zijn kieskeurig. De ene wil een platte formulierpost met velden die exact zo heten als in zijn specificatie; de andere wil JSON met het contact genest in een lead-object, de tracking in een ander object, en een vaste brontag en campagne-ID ernaast. De webhook doet het allebei: een eenvoudige veldenlijst waarin je velden aanvinkt en elke key hernoemt, of een JSON-body die je zelf schrijft met geneste objecten, arrays en vaste waarden.
Als methode heb je GET, POST en PUT, bodies gaan als JSON of URL-encoded formulierdata, en eigen headers dragen een API-sleutel of token, zodat inloggegevens nooit in de URL staan.
Compliance- en attributievelden bij elke lead
LanderLab voegt zijn eigen velden toe aan elke lead: de volledige pagina-URL, het IP-adres en de user agent van de bezoeker, het tijdstip van inzending in UTC en de getoonde A/B-variant. Dat zijn de velden die een afnemer controleert als een lead wordt betwist, en de velden die je nodig hebt om te bewijzen waar een lead vandaan kwam.
Voeg verborgen velden toe met dezelfde naam als je URL-parameters, zoals utm_campaign, gclid of de click ID van een tracker, en ze worden bij de lead opgeslagen en ook met hem meegestuurd. De afnemer krijgt de attributie, en jij kunt elke variant beoordelen op geaccepteerde leads in plaats van op ruwe formulierinzendingen.
Postbacks en pings met GET
Niet elke bestemming wil een body. Een trackerpostback, de conversie-URL van een affiliatenetwerk of een simpele ping krijgt zijn data via de querystring, en een GET-webhook stuurt de gemapte velden precies zo: de click ID onder de parameternaam die de tracker verwacht, met een vaste uitbetaling of status ernaast. Bij het verzenden gaat de conversie terug naar de campagne die ervoor betaalde.
Wanneer je beter een workflow gebruikt
Een webhook stuurt elke lead van zijn pagina. Moeten alleen sommige leads gaan, zoals leads uit de VS naar de ene afnemer en de rest naar een andere, of een opvolging na een Wachttijd, dan hebben de Workflows (bèta) van LanderLab hetzelfde soort verzoek als HTTP-verzoeknode, achter Filter-, Als- en Switch-nodes, met een Runs-weergave die het pad van elke lead en elke mislukte stap laat zien.
Hoe dan ook wordt de lead ook opgeslagen op het tabblad Leads van LanderLab, dus een endpoint dat plat lag, kost je de lead niet, tenzij “Compliant leadlevering” aanstaat, dat opslag bewust overslaat.
