Wyobraź sobie, że czekasz na paczkę. Możesz co pięć minut odświeżać stronę kuriera - albo zostawić numer telefonu i dostać SMS w momencie, gdy paczka wyjedzie do Ciebie.
Pierwsze to odpytywanie. Drugie to webhook.
Poniżej: czym webhook jest naprawdę, czym różni się od API, jak go użyć w Make.com i n8n oraz - najbardziej przydatne - dlaczego czasem nie przychodzi i co wtedy sprawdzić.
Webhook - co to jest
Webhook to automatyczna wiadomość, którą jedna aplikacja wysyła do drugiej w momencie, gdy coś się wydarzy. Nie na żądanie. Sama, z własnej inicjatywy.
Żeby to zadziałało, potrzebne są dwie rzeczy:
Adres, pod który wiadomość ma trafić - zwykły link https://..., który wystawia Twój system albo narzędzie do automatyzacji.
Zdarzenie, które ją wyzwala - ktoś wypełnił formularz, przyszła płatność, pojawiło się zamówienie, zmienił się status zadania.
Podajesz ten adres w ustawieniach aplikacji, a ona od tej pory sama się odzywa, gdy zdarzenie wystąpi. Nazwa jest zresztą dosłowna: to hak (hook) zaczepiony w cudzym systemie, który szarpie za linkę, kiedy coś się dzieje.
Jak działa webhook - krok po kroku
Cały mechanizm ma trzy etapy i dzieje się w ułamku sekundy.
Najważniejszy jest drugi etap i kierunek strzałki. To nie Ty pobierasz dane - to aplikacja Ci je przysyła. Cała reszta z tego wynika.
Webhook a API - czym się różnią
To pytanie pada najczęściej, a odpowiedź jest prostsza, niż się wydaje: webhook to też API, tylko odwrócone.
Przy zwykłym API Ty pytasz: wysyłasz zapytanie i dostajesz odpowiedź. Żeby wiedzieć o nowych rzeczach, musisz pytać regularnie - co minutę, co pięć minut. To się nazywa odpytywanie, po angielsku polling.
Przy webhooku pyta aplikacja - a właściwie nie pyta, tylko mówi. Odzywa się raz, dokładnie wtedy, gdy ma coś do powiedzenia.
Trzy praktyczne konsekwencje:
Webhook jest natychmiastowy. Przy odpytywaniu co pięć minut dane potrafią czekać pięć minut. Webhook przychodzi w sekundę.
Webhook zużywa mniej zasobów. W narzędziach rozliczanych za operacje - jak Make.com - odpytywanie pali limit na pytania, które w 95% przypadków wracają z niczym.
Ale webhook wymaga adresu, który stoi i słucha. I tu jest haczyk: jeśli Twój system akurat nie działa, wiadomość może przepaść. Przy odpytywaniu po prostu zapytasz później.
| Odpytywanie (API) | Webhook | |
|---|---|---|
| Kto inicjuje | Ty | Aplikacja |
| Opóźnienie | do długości interwału | praktycznie zero |
| Zużycie operacji | wysokie, także gdy nic nie ma | jedno na zdarzenie |
| Gdy Twój system nie działa | dopytasz później | wiadomość może przepaść |
| Konfiguracja | klucz API | publiczny adres |
Jak wygląda webhook w praktyce
Kiedy tworzysz webhook w narzędziu do automatyzacji, dostajesz adres mniej więcej taki:
https://hook.eu2.make.com/a1b2c3d4e5f6g7h8i9j0
Ten losowy ciąg na końcu jest jednocześnie adresem i hasłem - kto go zna, ten może wysłać dane do Twojego scenariusza. Wrzucasz go w ustawienia aplikacji źródłowej, w pole zwykle podpisane Webhook URL.
Kiedy zdarzenie wystąpi, pod ten adres przylatuje paczka danych. Najczęściej w formacie JSON i wygląda to mniej więcej tak:
{
"event": "nowe_zamowienie",
"id": 10472,
"klient": "Anna Nowak",
"kwota": 249.00,
"waluta": "PLN"
}
To wszystko. Żadnej magii - po prostu ustrukturyzowany tekst, który Twój scenariusz rozbiera na pola i wykorzystuje dalej.
Webhook w Make.com i n8n
Oba narzędzia obsługują webhooki jako punkt startowy scenariusza - to najczęstszy sposób, w jaki automatyzacja w ogóle się uruchamia.
W Make.com dodajesz moduł webhooka jako pierwszy element scenariusza. Make generuje adres, a potem czeka, aż przyjdzie pierwsza wiadomość - dopiero na jej podstawie rozpoznaje strukturę danych i udostępnia poszczególne pola kolejnym modułom. Dlatego kolejność jest taka: najpierw wyślij testową wiadomość, potem buduj resztę scenariusza. Pokazuję to na żywym przykładzie w tutorialu pierwszej automatyzacji w Make.com.
W n8n dodajesz węzeł webhooka, który daje Ci dwa różne adresy: testowy i produkcyjny. To rozróżnienie jest źródłem połowy problemów początkujących - adres testowy działa tylko wtedy, gdy workflow jest otwarty w edytorze i nasłuchuje. Produkcyjny działa dopiero po zapisaniu i aktywowaniu workflow. Podstawy n8n rozpisałem w tutorialu pierwszego workflow.
Typowe zastosowania, które można zbudować w godzinę: formularz na stronie wysyła zgłoszenie do arkusza i na Slacka, system płatności informuje o zaksięgowaniu wpłaty, sklep przekazuje nowe zamówienie do automatyzacji obsługującej mailem.
Dlaczego webhook nie działa - lista kontrolna
Najbardziej przydatna część i jednocześnie ta, której nie znajdziesz w definicjach. Kiedy wiadomość nie przychodzi, przejdź to po kolei.
Adres musi być dostępny z internetu. Webhook wysyła aplikacja stojąca na cudzym serwerze. Adres w rodzaju localhost albo 192.168.0.10 jest dla niej nieosiągalny. Przy pracy lokalnej potrzebujesz tunelu, który wystawi Twój port na zewnątrz.
Sprawdź, czy używasz właściwego adresu. W n8n testowy kontra produkcyjny. W wielu aplikacjach osobne środowisko testowe i produkcyjne, każde z własną konfiguracją webhooków.
Workflow musi być aktywny. Zapisany to nie to samo co włączony. Scenariusz w Make.com i workflow w n8n mają osobny przełącznik.
Odpowiadaj szybko. Nadawca czeka na potwierdzenie, zwykle kilka sekund. Jeśli Twój scenariusz najpierw mieli dane przez pół minuty, a dopiero potem odpowiada, nadawca uzna to za awarię - i może zacząć wysyłać ponownie. Przy dłuższym przetwarzaniu przyjmij wiadomość od razu, a robotę wykonaj w drugim kroku.
Licz się z duplikatami. Skoro przy braku potwierdzenia nadawcy ponawiają wysyłkę, ta sama wiadomość może przyjść dwa razy. Jeśli scenariusz wystawia fakturę albo wysyła maila, warto sprawdzać identyfikator zdarzenia i pomijać to, co już obsłużyłeś.
Zobacz, co faktycznie przyszło. Oba narzędzia pokazują historię wykonań z podglądem otrzymanych danych. Zanim zaczniesz debugować logikę, sprawdź, czy wiadomość w ogóle dotarła i co w sobie miała - bardzo często pole nazywa się inaczej, niż zakładałeś.
Bezpieczeństwo
Webhook to otwarte drzwi do Twojej automatyzacji. Nie trzeba paranoi, ale trzy rzeczy warto mieć z tyłu głowy.
Adres traktuj jak hasło. Nie wklejaj go do publicznego repozytorium, na forum ani do zgłoszenia do supportu. Kto go ma, ten może uruchomić Twój scenariusz.
Nie ufaj zawartości w ciemno. Do Twojego adresu może wysłać dane ktokolwiek, kto go zna. Jeśli scenariusz robi coś nieodwracalnego - przelew, wysyłkę, usunięcie - sprawdź najpierw, czy dane wyglądają sensownie.
Sprawdź, czy nadawca podpisuje wiadomości. Poważne serwisy dołączają nagłówek z podpisem, którym możesz potwierdzić, że wiadomość faktycznie pochodzi od nich. Jeśli Twój dostawca to oferuje, warto z tego skorzystać - zwłaszcza przy płatnościach.
Podsumowanie
Webhook to wiadomość wysyłana automatycznie w momencie zdarzenia - zamiast dopytywania, czy coś się zmieniło.
Cztery rzeczy warte zapamiętania:
- kierunek jest odwrotny niż przy API - to aplikacja odzywa się do Ciebie, nie Ty do niej
- adres webhooka jest jednocześnie hasłem - kto go zna, ten może wysłać dane
- odpowiadaj szybko i licz się z duplikatami - nadawcy ponawiają wysyłkę, gdy nie dostaną potwierdzenia
- przy problemach najpierw sprawdź historię wykonań - zwykle problemem jest zły adres albo nieaktywny workflow, nie logika
Jeśli budujesz automatyzacje, webhooki są tym, od czego zaczyna się większość z nich - dlatego to pierwszy krok w ścieżkę nauki n8n. Praktyczne przykłady zebrałem w przewodniku po automatyzacji AI.
Najczęstsze pytania o webhooki
Co to jest webhook?
Webhook to automatyczna wiadomość, którą aplikacja wysyła pod wskazany przez Ciebie adres w momencie, gdy zajdzie określone zdarzenie - na przykład ktoś wypełni formularz albo przyjdzie płatność. Nie musisz o nic pytać; aplikacja odzywa się sama.
Czym webhook różni się od API?
Kierunkiem. Przy zwykłym API to Ty wysyłasz zapytanie i czekasz na odpowiedź, więc żeby wiedzieć o nowościach, musisz pytać regularnie. Przy webhooku aplikacja sama wysyła dane w chwili zdarzenia. Technicznie webhook też korzysta z HTTP - to po prostu API działające w drugą stronę.
Czy webhook jest bezpieczny?
Sam mechanizm tak, ale adres webhooka trzeba traktować jak hasło - każdy, kto go zna, może wysłać dane do Twojej automatyzacji. Nie publikuj go, a przy operacjach nieodwracalnych weryfikuj zawartość wiadomości i podpis nadawcy, jeśli dostawca go udostępnia.
Dlaczego webhook nie przychodzi?
Najczęstsze przyczyny to nieaktywny scenariusz lub workflow, użycie adresu testowego zamiast produkcyjnego oraz adres niedostępny z internetu, na przykład localhost. Zacznij od sprawdzenia historii wykonań w narzędziu - zobaczysz, czy wiadomość w ogóle dotarła.
Czy ta sama wiadomość może przyjść dwa razy?
Tak i trzeba to zakładać. Jeśli nadawca nie dostanie szybkiego potwierdzenia, ponowi wysyłkę. Przy scenariuszach, które wystawiają dokumenty albo wysyłają wiadomości, warto zapisywać identyfikator obsłużonego zdarzenia i pomijać powtórki.
Czy webhook działa w Make.com i n8n?
Tak, w obu jest to standardowy sposób uruchamiania automatyzacji. Make.com generuje adres i rozpoznaje strukturę danych po pierwszej otrzymanej wiadomości. n8n daje dwa osobne adresy - testowy, działający tylko przy otwartym edytorze, i produkcyjny, działający po aktywowaniu workflow.