Webhook på dina landningssidor
De flesta leadgen-stackar har en skatt i mitten: en Zap eller ett scenario vars enda jobb är att flytta ett lead från sidan till en endpoint som hade tagit emot det direkt. Varje lead betalar för det steget i uppgifter eller krediter, och varje steg är ytterligare ett ställe där ett lead kan fastna medan en köpare väntar.
LanderLabs Webhook-integration tar bort den. Varje sida skickar sina leads direkt till valfri HTTPS-endpoint: en köpares posting-URL, ditt eget lead-API, ett CRM:s endpoint, en trackers postback. Du bestämmer metod, format, headers och exakt body, så att mottagaren får leadet så som dess dokumentation kräver.
Det är integrationen bakom de flesta verktyg på den här webbplatsen som inte har en egen integration, och det är den du tar till när en köpare skickar en specifikation.
Därför slår en direkt webhook att betala för en mellanhand
Ett lead som går sida, sedan Zap, sedan köpare är beroende av två system och faktureras av ett av dem. På ett erbjudande med hög volym växer automationsabonnemanget med antalet leads, trots att inget intressant händer i mitten: Zapen tar emot ett lead och postar det någon annanstans.
En direkt webhook är samma post utan mellansteget. Leadet går från sidan till endpointen vid inskick, under din kontroll, utan något emellan som kan pausa, få slut på uppgifter eller ändra sina priser. Behåll mellanhanden för jobb som kräver flera steg; låt webhooken sköta dem som inte gör det.
Skicka leads i det format som mottagaren förväntar sig
Köpare och API:er är noga. En vill ha en platt formulärpost med fält som heter exakt som i specifikationen; en annan vill ha JSON med kontakten nästlad i ett lead-objekt, spårningen i ett annat och en fast källtagg och ett kampanj-ID bredvid. Webhooken klarar båda: en enkel fältlista där du bockar i fält och döper om varje nyckel, eller en JSON-body du skriver själv med nästlade objekt, arrayer och statiska värden.
Metoderna omfattar GET, POST och PUT, body skickas som JSON eller URL-kodad formulärdata, och egna headers bär en API-nyckel eller en token, så att inloggningsuppgifter aldrig ligger i URL:en.
Fält för compliance och attribuering på varje lead
LanderLab lägger till egna fält på varje lead: sidans fullständiga URL, besökarens IP-adress och user agent, tidpunkten för inskicket i UTC och den A/B-variant som visades. Det är de fälten en köpare kontrollerar när ett lead ifrågasätts, och de du behöver för att bevisa var ett lead kom ifrån.
Lägg till dolda fält som heter som dina URL-parametrar, till exempel utm_campaign, gclid eller en trackers klick-ID, så sparas de med leadet och skickas med det också. Köparen får attribueringen, och du kan bedöma varje variant på accepterade leads i stället för råa formulärinskick.
Postbacks och pingar med GET
Alla mottagare vill inte ha en body. En postback till en tracker, ett affiliatenätverks konverterings-URL eller en enkel ping tar emot sin data i query-strängen, och en GET-webhook skickar de mappade fälten precis så: klick-ID:t under det parameternamn som trackern förväntar sig, en statisk utbetalning eller status bredvid. Konverteringen går tillbaka till kampanjen som betalade för den i samma stund som formuläret skickas.
När du ska använda ett arbetsflöde i stället
En webhook skickar varje lead från sin sida. När bara vissa leads ska iväg, som leads från USA till en köpare och resten till en annan, eller en uppföljning efter en Fördröjning, har LanderLabs Arbetsflöden (beta) samma sorts förfrågan som noden HTTP-anrop, bakom noderna Filter, Om och Switch, med vyn Körningar som visar varje leads väg och eventuella misslyckade steg.
Hur som helst sparas leadet också i LanderLabs flik Leads, så en endpoint som låg nere kostar dig inte leadet, om inte ”Regelefterlevnad vid leadleverans” är påslaget, som med avsikt hoppar över lagringen.
