Słowniczek

Webhook

Webhook to mechanizm komunikacji między systemami, w którym system zewnętrzny automatycznie wysyła powiadomienie HTTP do Twojej aplikacji, gdy nastąpi określone zdarzenie. W odróżnieniu od tradycyjnego API, gdzie Twoja aplikacja musi aktywnie pytać „czy jest coś nowego?” (polling), webhook działa odwrotnie — to serwis sam mówi Ci „właśnie coś się wydarzyło!”.

Analogia, która tłumaczy to najlepiej: API to dzwonienie do restauracji co 5 minut i pytanie „czy moje zamówienie jest gotowe?”. Webhook to restauracja, która sama dzwoni do Ciebie, gdy jedzenie jest na stole. Mniej obciążenia, szybsza reakcja, zero zmarnowanych zapytań.

Jak działa webhook technicznie?

Proces w czterech krokach:

  1. Rejestracja — podajesz systemowi zewnętrznemu URL (endpoint), na który ma wysyłać powiadomienia. Np. mówisz Stripe'owi: „gdy klient zapłaci, wyślij POST na https://mojafirma.pl/webhook/platnosc”.
  2. Zdarzenie — klient płaci za zamówienie w Twoim sklepie.
  3. Powiadomienie — Stripe natychmiast wysyła żądanie HTTP POST na Twój endpoint z danymi o płatności (kwota, klient, status) w formacie JSON.
  4. Przetworzenie — Twoja aplikacja odbiera powiadomienie i wykonuje akcję: oznacza zamówienie jako opłacone, wysyła potwierdzenie klientowi, aktualizuje magazyn.

Cały proces trwa sekundy, nie minuty. To fundamentalna różnica wobec pollingu, który sprawdza źródło co 1-15 minut.

Webhook vs API — kiedy co stosować?

  • Webhook (push) — system zewnętrzny sam powiadamia Cię o zdarzeniu. Idealne gdy: chcesz reagować natychmiast (płatności, wiadomości, zamówienia), nie wiesz kiedy zdarzenie nastąpi, chcesz zminimalizować obciążenie (zero zbędnych zapytań).
  • API polling (pull) — Twój system regularnie odpytuje źródło. Idealne gdy: system zewnętrzny nie wspiera webhooków, potrzebujesz danych na żądanie (nie w reakcji na zdarzenie), chcesz pełną kontrolę nad częstotliwością.

Reguła: webhook gdy możesz, polling gdy musisz. Webhook jest szybszy, efektywniejszy i nie obciąża API niepotrzebnymi zapytaniami. Ale nie wszystkie systemy go wspierają.

Webhooks w narzędziach no-code

W narzędziach automatyzacji (Make.com, Zapier, n8n) webhook jest jednym z typów wyzwalacza:

  • Make.com — moduł „Custom Webhook” tworzy unikalny URL. Podajesz go systemowi zewnętrznemu. Gdy webhook przychodzi — scenariusz się uruchamia natychmiast.
  • Zapier — „Webhooks by Zapier” trigger. Catch Hook tworzy URL, na który wysyłasz dane z dowolnego systemu.
  • n8n — Webhook Node. Self-hosted, więc Twoje dane nie przechodzą przez serwery trzecich firm.

Webhooks w no-code to potężne narzędzie, bo pozwalają zintegrować dowolny system z Twoim workflow — nawet jeśli nie ma natywnej integracji. Wystarczy, że system potrafi wysłać HTTP POST.

Bezpieczeństwo webhooków

Webhook to otwarty endpoint — każdy, kto zna URL, może wysłać na niego dane. Dlatego bezpieczeństwo jest kluczowe:

  • Weryfikacja podpisu — system wysyłający dołącza kryptograficzny podpis (np. HMAC-SHA256). Twoja aplikacja weryfikuje podpis przed przetworzeniem. Zapobiega fałszywym webhookom.
  • HTTPS — webhook MUSI być na HTTPS, nigdy na HTTP. Dane są szyfrowane w transmisji.
  • Secret token — dodaj sekretny token do URL lub nagłówka. Odrzucaj żądania bez tokena.
  • Idempotentność — webhook może zostać wysłany dwukrotnie (retry). Twoja aplikacja musi obsłużyć duplikaty bez podwójnego przetworzenia.

Typowe zastosowania webhooków w biznesie

  • Płatności — Stripe/PayU powiadamia o udanej płatności → oznacz zamówienie, wyślij potwierdzenie.
  • E-commerce — nowe zamówienie w sklepie → aktualizuj magazyn, powiadom logistykę.
  • CRM — nowy lead w formularzu → dodaj do HubSpot, powiadom handlowca na Slacku.
  • Git — nowy commit/push → uruchom testy, zbuduj, zadeploy (CI/CD, patrz: Deployment).
  • Monitoring — serwer down → powiadom zespół SMS-em natychmiast.

Webhook to mechanizm, w którym system zewnętrzny sam powiadamia Twoją aplikację o zdarzeniu, wysyłając żądanie HTTP na dedykowany URL. API wymaga, żebyś sam pytał co jakiś czas „czy jest coś nowego?” (polling). Analogia: API to dzwonienie do restauracji co 5 minut pytając czy zamówienie gotowe. Webhook to restauracja dzwoniąca do Ciebie gdy jedzenie jest na stole. Webhook jest szybszy (reakcja w sekundach vs minuty pollingu), efektywniejszy (zero zbędnych zapytań) i lżejszy dla infrastruktury. Reguła: webhook gdy możesz, polling gdy musisz — bo nie wszystkie systemy wspierają webhooks.

Cztery warstwy bezpieczeństwa: (1) Weryfikacja podpisu HMAC — system wysyłający dołącza kryptograficzny podpis, Twoja aplikacja weryfikuje go przed przetworzeniem, co zapobiega fałszywym webhookom. (2) HTTPS — webhook musi być na HTTPS, nigdy HTTP, dane szyfrowane w transmisji. (3) Secret token — dodaj tajny token do URL lub nagłówka, odrzucaj żądania bez tokena. (4) Idempotentność — webhook może przyjść dwukrotnie (retry po timeoucie), Twoja aplikacja musi obsłużyć duplikaty bez podwójnego przetworzenia (np. podwójnego pobrania płatności). Każda z tych warstw jest ważna — brak jednej to potencjalna luka.

W każdym narzędziu webhook to typ wyzwalacza. Make.com: moduł Custom Webhook generuje unikalny URL, podajesz go systemowi zewnętrznemu, scenariusz uruchamia się natychmiast gdy webhook przychodzi. Zapier: trigger Webhooks by Zapier, Catch Hook tworzy URL do odbioru danych. n8n: Webhook Node, self-hosted więc dane nie przechodzą przez serwery trzecich firm. Kluczowa zaleta: webhooks w no-code pozwalają zintegrować dowolny system z workflow, nawet bez natywnej integracji — wystarczy że system potrafi wysłać HTTP POST. To łączy świat, który normalnie nie rozmawia ze sobą.

Pięć głównych: (1) Płatności — Stripe/PayU powiadamia o udanej płatności, oznacz zamówienie, wyślij potwierdzenie. (2) E-commerce — nowe zamówienie uruchamia aktualizację magazynu i powiadomienie logistyki. (3) CRM — nowy lead z formularza trafia do HubSpot i powiadomienie na Slacku do handlowca. (4) CI/CD — push do Git uruchamia testy, build i deploy automatycznie. (5) Monitoring — serwer down = SMS do zespołu w sekundy. Wspólny mianownik: chcesz reagować natychmiast na zdarzenie w systemie zewnętrznym, bez manualnego sprawdzania czy coś się zmieniło.

Idempotentność oznacza, że ponowne wykonanie tej samej operacji daje ten sam wynik — bez efektów ubocznych. Przy webhookach jest kluczowa, bo webhook może zostać wysłany dwukrotnie: system wysyłający nie dostał potwierdzenia odbioru (timeout, błąd sieci) i wysyła retry. Jeśli Twoja aplikacja nie jest idempotentna, przetworzy płatność dwukrotnie, wyśle dwa maile potwierdzające, doda dwa rekordy do CRM. Rozwiązanie: zapisuj ID każdego przetworzonego webhooka i sprawdzaj czy już go nie obsłużyłeś przed przetworzeniem. Proste zabezpieczenie, które zapobiega kosztownym duplikatom.