A webhook egy automatikus HTTP POST kérés, amit egy szolgáltatás küld a te szerveredre, amikor valami történik nála — pl. fizetés sikerre fut, új lead érkezik, vagy egy GitHub-repón push történt. Lényegében ez a polling fordítottja: nem te kérdezed folyamatosan, hogy „történt-e valami?”, hanem a másik fél szól, amikor van mit közölni. Ezért hívják néha „reverse API”-nak vagy „push-alapú integrációnak”. A modern SaaS-világ alapköve — Stripe, Zapier, n8n, Make, Slack, Discord, Shopify mind webhook-okkal kommunikál.
Így is ismerheted
Magyar fordítás gyakorlatban nincs — szinte kizárólag a webhook angol szót használjuk. Néha web hook (külön írva) vagy HTTP callback, callback URL formában találkozhatsz vele. A „reverse API” és „push notification” rokon fogalmak, de nem teljesen ugyanazok — a webhook konkrétan szerver-szerver közötti HTTP POST. Régi szakirodalom „callback url”-ként hivatkozik rá, ami ugyanaz: az a végpont, amit a szolgáltatás meghív, amikor van eseménye.
Hogyan működik egy webhook?
A flow három szereplővel zajlik: az esemény forrása (pl. Stripe), a fogadó szerver (a te oldalad), és maga az esemény (pl. egy sikeres fizetés). A folyamat egyszerű: regisztrálsz a forrásnál egy URL-t (a te webhook-fogadó endpoint-od, pl. https://eclick.hu/webhook/stripe), és megadod, milyen eseményekre szeretnél értesülni. Amikor az esemény bekövetkezik, a forrás egy HTTP POST kérést küld erre az URL-re, JSON body-val, ami leírja mi történt.
A te szervered fogadja a POST-ot, validálja (lentebb erre kitérünk), és reagál — pl. frissíti a megrendelés-státuszt az adatbázisban, e-mailt küld a vásárlónak, vagy átdob egy lead-et a CRM-be. Visszaadsz egy 200 OK választ, ezzel a forrásnak jelzed: „megkaptam, feldolgoztam”. Ha nem érkezik 200 vagy timeout-ol a hívás, a legtöbb szolgáltató újra próbál (exponenciális backoff-fal) — Stripe például 3 napon át tüzel exponenciálisan növekvő szünetekkel.
Mire használjuk a gyakorlatban?
A webhook a SaaS-integráció svájcibicskája. Ha valaha kapcsoltál össze két szolgáltatást (pl. Stripe-ot WordPress-szel, Mailchimp-et HubSpot-tal, vagy n8n-nel automatizáltál bármit), az 90%-ban webhook-on át történt. Tipikus felhasználási esetek:
- Fizetés-értesítés — Stripe, PayPal, Barion „payment.success” eseménye → automatikus számla, e-mail, hozzáférés-aktiválás.
- Lead-átadás — Form-kitöltés → CRM-be (HubSpot, Pipedrive, ClickUp) Zapier vagy n8n-en át.
- Discord/Slack értesítés — bármilyen esemény (új rendelés, kritikus hiba, support-üzenet) push-olva a csapat-csatornába.
- Git-deploy — GitHub push event → CI/CD trigger → automatikus build és deploy.
- Chatbot lead-flow — Typebot end-of-conversation → eClick-bot-brain REST endpoint → Discord ping + email + ClickUp task.
A mi OAuth-hoz hasonló integrációs gerinc — csak míg az OAuth a hozzáférést kezeli, a webhook az eseményeket szállítja. A kettőt sokszor együtt használjuk.
Webhook biztonság — mire figyelj?
Mivel a webhook egy nyitott HTTP endpoint, bárki, aki ismeri az URL-t, küldhet rá kérést. Ezért minden komoly szolgáltató valamilyen aláírást ad a kéréshez, hogy meg tudd győződni: tényleg ők küldték, és nem volt manipulálva a body. Stripe-nál ez a Stripe-Signature header, GitHub-nál X-Hub-Signature-256, Shopify-nál X-Shopify-Hmac-SHA256.
Egy tipikus baki, amit többször láttunk: a fejlesztő implementálja a webhook-fogadót, de elfelejti validálni a signature-t — és teszteléskor jól működik, mert Stripe-ról jön. Aztán valaki rájön az URL-re, és kamu POST-tal aktivál előfizetéseket. A validáció minden webhook-receiver első lépése: HMAC SHA-256 a body + a secret key alapján, egyezik-e a header értékkel.
A másik gyakori hiba: a webhook szinkron feldolgozása lassú műveletekkel (e-mail küldés, kép-feltöltés). Ha a feldolgozás 30 másodpercnél tovább tart, a forrás retry-olja, és duplikált eseményt kapsz. Megoldás: a webhook-handler csak elfogadja a kérést (200 OK), és egy queue-ba (Redis, RabbitMQ, vagy WP cron) teszi az aktuális feldolgozást.
Webhook vs polling — mikor melyiket?
Ha a forrás-szolgáltató ad webhook-ot, és te tudsz egy publikus HTTP endpoint-ot futtatni, akkor webhook a nyerő — kevesebb terhelés, gyorsabb reakció, lényegében ingyenes. Polling akkor jön szóba, ha:
- A forrás nem ad webhook-ot (csak REST endpoint-ot).
- A te szervered nem érhető el publikusan (pl. lokál fejlesztőkörnyezet — ott ngrok tunnel-lel hidalod át).
- Tűzfal mögött ülsz, és a tűzfal nem enged be HTTP-t.
Polling-nál te kérdezed le periodikusan a forrást (pl. minden 5 percben), és nézed, történt-e új esemény. Egyszerűbb a beállítása, de drágább erőforrás-szinten és lassabb az reakció. Tipikus kompromisszum: 5 perces polling + saját retry-logic.
Tooling — webhook-okat hogyan tesztelj és fogadj?
Helyi fejlesztéshez használj egy tunneling-eszközt: az ngrok az iparági standard, ingyenes csomaggal. Egyetlen ngrok http 3000 parancs egy publikus URL-t ad a lokál szerveredre, amit a Stripe webhook-konfigjában megadhatsz. A Stripe CLI-ben van saját stripe listen --forward-to localhost:3000/webhook parancs, ami helyettesíti az ngrok-ot Stripe-specifikus tesztelésre.
Produkcióban a webhook-receiver lehet sima WordPress REST endpoint (lásd a mi eclick-bot-brain plugin /wp-json/eclick-bot/v1/lead endpoint-ját), Laravel route, Express handler, vagy serverless function (AWS Lambda, Cloudflare Worker, Vercel API route). A választás projekt-függő — kis volumen (napi <100 esemény) bármelyik elég, nagy volumen esetén dedikált queue (RabbitMQ, AWS SQS) kell mögé.
Ha webhook-integrációkat, automatizációt vagy egyedi backend-et építenénk neked (Stripe, GitHub, CRM-bekötés), nézd meg az AI automatizáció és az egyedi weboldal-fejlesztés szolgáltatásunkat. Kapcsolódó cikkek: OAuth, GraphQL, DNS.
