Gödi Sittes / 2026. október 8.
Facebook-leadből CRM-ügyfél: egy nap Meta-debugolás, jogosultsági zsákutcák és sikeres backfill
Élesre vittük a Facebook Lead Ads → Gödi Sittes CRM folyamatot: aláírt webhook, Graph API-s adatlekérés, idempotens PostgreSQL-import és PWA push-értesítés. A nap végére négy korábbi valódi érdeklődőt is behoztunk, miközben a tesztadatokat eltakarítottuk.
A helyzet
A Gödi Sittes CRM már képes volt Facebook leadgen webhookot fogadni, de ettől még nem jelent meg ügyfél az alkalmazásban. A Meta tesztfelülete felváltva hiányzó engedélyeket és nem telepített alkalmazást jelzett, a tesztesemény hosszú ideig Pending állapotban maradt. A szerveroldali HMAC-aláírásellenőrzés és a HTTP 200 csak az esemény fogadását igazolta, nem azt, hogy a Graph API valóban visszaadja az érdeklődő adatait. Eközben az éles rendszer üzemeltetési biztonságát is szem előtt kellett tartani.
A megoldási út
Először szétválasztottuk a webhook, a token, az űrlap és a háttérfeldolgozó hibalehetőségeit. A debug_token lekérdezés feltárta, hogy a rendszerfelhasználói token jogosultságai önmagukban nem elegendők: a konkrét Facebook-oldal saját Page Access Tokenjével már HTTP 200 mellett láthatóvá vált mindkét űrlap. A token biztonságos cseréje után a webhook a leadgen azonosítóját elmentette a meta_lead_events sorba, de az első tesztlead egyedi Graph-lekérése HTTP 400 / code 100 / subcode 33 hibába futott. A célzott API-vizsgálat megmutatta, hogy a már nem elérhető tesztlead és az érvényes oldaljogosultság külön kérdés. Új tesztleadet hoztunk létre közvetlenül a Meta test_leads API-ján, ellenőriztük a mezőit, majd az esemény egyetlen próbálkozással imported státuszba került; a CRM ügyfélkártyája és a mobil PWA push is megjelent. A nap egyik üzemeltetési zsákutcájában egy fejlesztői make down az adatbázis-konténert is leállította; a production Compose-konfigurációval és a meglévő perzisztens kötettel állítottuk helyre, majd health checkkel igazoltuk a működést. Végül mentés után egy lapozó, dry-run előnézettel indított backfill-szkriptet használtunk: a két űrlapból négy valódi, egyedi régi érdeklődőt állítottunk sorba, a két ismert teszteseményt és az egy teszt-CRM-kártyát célzottan eltávolítottuk.
Mi lett belőle
A négy korábbi, API-n elérhető valódi Facebook-lead feldolgozása imported státuszban zárult; a tesztrekordok takarítása után a Meta-sorban négy sikeres import és nulla fennmaradó sikertelen esemény szerepelt. Az új leadek útvonala — Facebook űrlap → hitelesített webhook → PostgreSQL-sor → Graph API → CRM ügyfél és visszahívási feladat → PWA push — tesztleadekkel végig igazoltan működik. A duplikációvédelem az eredeti Meta leadazonosítóra épül, az éles adatbázisról az egyszeri visszamenőleges import előtt mentés készült. Valódi fizetett hirdetésből érkező következő érdeklődőt még üzemi megfigyeléssel érdemes ellenőrizni.