Webhooki w e-commerce - do czego służą i jak je bezpiecznie wdrożyć

Klient płaci za zamówienie, a ERP dowiaduje się o tym dopiero po kwadransie. Bramka płatności potwierdza wpłatę, ale status w sklepie zmienia się z opóźnieniem. Magazyn wysyła paczkę, a klient nie dostaje numeru przesyłki, bo integracja sprawdza zmiany raz na godzinę. Większość takich problemów ma wspólną przyczynę: systemy pytają się nawzajem o zmiany, zamiast dostawać o nich informację w chwili, gdy zachodzą.

Webhooki rozwiązują ten problem. W tym wpisie wyjaśniamy, czym są webhooki w e-commerce, czym różnią się od odpytywania API, jakie zdarzenia warto obsługiwać w sklepie i jak wdrożyć je tak, żeby nie stały się furtką dla atakującego ani źródłem zdublowanych zamówień. Wpis jest napisany dla właściciela sklepu i osoby, która koordynuje pracę programisty.

[#wazne] W skrócie: webhook to automatyczne powiadomienie, które jeden system wysyła do drugiego, gdy coś się wydarzy - np. „nowe zamówienie” albo „płatność potwierdzona”. Zastępuje ciągłe odpytywanie API, więc dane płyną szybciej, a integracja zużywa mniej zapytań. Bezpieczne wdrożenie wymaga trzech rzeczy: weryfikacji podpisu nadawcy, odporności na powtórzone i spóźnione powiadomienia oraz mechanizmu, który wyłapie zdarzenia, które nie dotarły.

Czym są webhooki w e-commerce i jak działają

Webhook to wywołanie HTTP (zwykle typu POST), które system źródłowy wysyła pod adres URL wskazany przez Ciebie, gdy zajdzie określone zdarzenie. W treści takiego wywołania jest informacja, co się stało, i najczęściej dane obiektu, którego zdarzenie dotyczy - np. zamówienia, produktu albo płatności. Twój serwer, nazywany odbiorcą lub endpointem webhooka, przyjmuje te dane i uruchamia dalszą logikę.

[#chart:wpr2a]

Najprościej porównać to do różnicy między sprawdzaniem skrzynki pocztowej co godzinę a dzwonkiem do drzwi. Odpytywanie (polling) to schodzenie do skrzynki: często niepotrzebne, bo nic nie przyszło, a gdy coś przyjdzie, i tak dowiadujesz się z opóźnieniem. Webhook to dzwonek - reagujesz wtedy, kiedy faktycznie ktoś przyszedł.

Webhook a odpytywanie API - porównanie

Cecha	Odpytywanie API (polling)	Webhook
Kto inicjuje komunikację	Twoja integracja, cyklicznie	System źródłowy, przy zdarzeniu
Opóźnienie danych	Zależy od interwału odpytywania	Zwykle sekundy od zdarzenia
Zużycie limitów API	Wysokie, także gdy nic się nie zmieniło	Niskie, ruch tylko przy zmianach
Wymagania techniczne	Skrypt uruchamiany cyklicznie	Publicznie dostępny endpoint HTTPS
Ryzyko utraty danych	Niskie, kolejne zapytanie wyłapie zmiany	Istnieje, gdy endpoint nie odpowiada - potrzebne ponowienia i uzgadnianie
Dostępność	Każde API z odczytem danych	Tylko systemy, które wspierają webhooki

Nie każda platforma wysyła webhooki. WooCommerce, Shopify, Shoper czy bramki płatności, takie jak Stripe, oferują je dla wybranych zdarzeń. Z kolei w Allegro REST API zmiany w zamówieniach pobiera się przez dziennik zdarzeń, który integracja odpytuje cyklicznie - więcej o możliwościach tego API piszemy we wpisie Allegro REST API - co można zautomatyzować w sprzedaży. W praktyce integracja sklepu często łączy oba modele: webhooki tam, gdzie są dostępne, odpytywanie tam, gdzie ich nie ma.

Jakie zdarzenia webhook warto obsługiwać w sklepie

Lista dostępnych zdarzeń różni się między platformami, ale w e-commerce powtarza się kilka grup. Nie trzeba subskrybować wszystkiego - lepiej zacząć od zdarzeń, które dziś powodują ręczną pracę albo opóźnienia odczuwalne dla klienta.

Webhook zamówienie utworzone - przekazanie zamówienia do ERP, WMS lub operatora fulfillmentu, utworzenie przesyłki, rezerwacja stanu.
Zmiana statusu zamówienia - anulacja, wstrzymanie, zmiana adresu. Pozwala zatrzymać wysyłkę, zanim paczka opuści magazyn.
Płatność potwierdzona lub zwrócona - zmiana statusu zamówienia, wystawienie faktury, rozpoczęcie kompletacji. Przy bramkach płatności to często podstawowy mechanizm potwierdzenia transakcji.
Zmiana produktu lub stanu - aktualizacja feedów reklamowych, marketplace'ów i wyszukiwarki w sklepie.
Nowy klient lub zgoda marketingowa - zapis do narzędzia mailingowego lub CRM.
Zwrot lub reklamacja - powiadomienie magazynu, przygotowanie korekty.

Klient płaci za zamówienie, a ERP dowiaduje się o tym dopiero po kwadransie. Bramka płatności potwierdza wpłatę, ale status w sklepie zmienia się z opóźnieniem. Magazyn wysyła paczkę, a klient nie dostaje numeru przesyłki, bo integracja sprawdza zmiany raz na godzinę. Większość takich problemów ma wspólną przyczynę: systemy pytają się nawzajem o zmiany, zamiast dostawać o nich informację w chwili, gdy zachodzą.

Webhooki rozwiązują ten problem. W tym wpisie wyjaśniamy, czym są webhooki w e-commerce, czym różnią się od odpytywania API, jakie zdarzenia warto obsługiwać w sklepie i jak wdrożyć je tak, żeby nie stały się furtką dla atakującego ani źródłem zdublowanych zamówień. Wpis jest napisany dla właściciela sklepu i osoby, która koordynuje pracę programisty.

[#wazne] W skrócie: webhook to automatyczne powiadomienie, które jeden system wysyła do drugiego, gdy coś się wydarzy - np. „nowe zamówienie” albo „płatność potwierdzona”. Zastępuje ciągłe odpytywanie API, więc dane płyną szybciej, a integracja zużywa mniej zapytań. Bezpieczne wdrożenie wymaga trzech rzeczy: weryfikacji podpisu nadawcy, odporności na powtórzone i spóźnione powiadomienia oraz mechanizmu, który wyłapie zdarzenia, które nie dotarły.

Czym są webhooki w e-commerce i jak działają

Webhook to wywołanie HTTP (zwykle typu POST), które system źródłowy wysyła pod adres URL wskazany przez Ciebie, gdy zajdzie określone zdarzenie. W treści takiego wywołania jest informacja, co się stało, i najczęściej dane obiektu, którego zdarzenie dotyczy - np. zamówienia, produktu albo płatności. Twój serwer, nazywany odbiorcą lub endpointem webhooka, przyjmuje te dane i uruchamia dalszą logikę.

[#chart:wpr2a]

Najprościej porównać to do różnicy między sprawdzaniem skrzynki pocztowej co godzinę a dzwonkiem do drzwi. Odpytywanie (polling) to schodzenie do skrzynki: często niepotrzebne, bo nic nie przyszło, a gdy coś przyjdzie, i tak dowiadujesz się z opóźnieniem. Webhook to dzwonek - reagujesz wtedy, kiedy faktycznie ktoś przyszedł.

Webhook a odpytywanie API - porównanie

Cecha	Odpytywanie API (polling)	Webhook
Kto inicjuje komunikację	Twoja integracja, cyklicznie	System źródłowy, przy zdarzeniu
Opóźnienie danych	Zależy od interwału odpytywania	Zwykle sekundy od zdarzenia
Zużycie limitów API	Wysokie, także gdy nic się nie zmieniło	Niskie, ruch tylko przy zmianach
Wymagania techniczne	Skrypt uruchamiany cyklicznie	Publicznie dostępny endpoint HTTPS
Ryzyko utraty danych	Niskie, kolejne zapytanie wyłapie zmiany	Istnieje, gdy endpoint nie odpowiada - potrzebne ponowienia i uzgadnianie
Dostępność	Każde API z odczytem danych	Tylko systemy, które wspierają webhooki

Nie każda platforma wysyła webhooki. WooCommerce, Shopify, Shoper czy bramki płatności, takie jak Stripe, oferują je dla wybranych zdarzeń. Z kolei w Allegro REST API zmiany w zamówieniach pobiera się przez dziennik zdarzeń, który integracja odpytuje cyklicznie - więcej o możliwościach tego API piszemy we wpisie Allegro REST API - co można zautomatyzować w sprzedaży. W praktyce integracja sklepu często łączy oba modele: webhooki tam, gdzie są dostępne, odpytywanie tam, gdzie ich nie ma.

Jakie zdarzenia webhook warto obsługiwać w sklepie

Lista dostępnych zdarzeń różni się między platformami, ale w e-commerce powtarza się kilka grup. Nie trzeba subskrybować wszystkiego - lepiej zacząć od zdarzeń, które dziś powodują ręczną pracę albo opóźnienia odczuwalne dla klienta.

Webhook zamówienie utworzone - przekazanie zamówienia do ERP, WMS lub operatora fulfillmentu, utworzenie przesyłki, rezerwacja stanu.
Zmiana statusu zamówienia - anulacja, wstrzymanie, zmiana adresu. Pozwala zatrzymać wysyłkę, zanim paczka opuści magazyn.
Płatność potwierdzona lub zwrócona - zmiana statusu zamówienia, wystawienie faktury, rozpoczęcie kompletacji. Przy bramkach płatności to często podstawowy mechanizm potwierdzenia transakcji.
Zmiana produktu lub stanu - aktualizacja feedów reklamowych, marketplace'ów i wyszukiwarki w sklepie.
Nowy klient lub zgoda marketingowa - zapis do narzędzia mailingowego lub CRM.
Zwrot lub reklamacja - powiadomienie magazynu, przygotowanie korekty.

Jak bezpiecznie wdrożyć webhooki w e-commerce - zasady techniczne

Endpoint webhooka to publiczny adres w internecie, który przyjmuje dane i uruchamia akcje w Twoich systemach. Jeśli każdy może wysłać tam dowolne dane, ktoś może np. oznaczyć zamówienie jako opłacone. Dlatego bezpieczeństwo jest tu warunkiem, a nie dodatkiem.

[#chart:wpr2b]

1. Weryfikacja nadawcy - podpis HMAC

Większość platform podpisuje wysyłane webhooki. Nadawca oblicza skrót treści wiadomości z użyciem tajnego klucza znanego tylko Tobie i jemu (najczęściej HMAC-SHA256), a wynik umieszcza w nagłówku HTTP. Shopify przesyła go w nagłówku X-Shopify-Hmac-Sha256, WooCommerce w X-WC-Webhook-Signature, a Stripe w nagłówku Stripe-Signature. Twój endpoint liczy ten sam skrót po swojej stronie i odrzuca wiadomość, jeśli wyniki się nie zgadzają. Bez tej weryfikacji nie przetwarzaj żadnych danych.

[#uwaga] Podpis liczy się z surowej treści żądania, dokładnie w takiej postaci, w jakiej przyszła. Częsty błąd to weryfikacja po wcześniejszym sparsowaniu i ponownym zapisaniu JSON-a - wtedy podpis nigdy się nie zgadza, a programista pod presją czasu… wyłącza weryfikację. Tego nie wolno robić.

2. Szybka odpowiedź i przetwarzanie w tle

Nadawca czeka na odpowiedź tylko przez ograniczony czas. Jeśli endpoint w tym czasie łączy się z ERP, generuje fakturę i etykietę, łatwo przekroczyć limit - nadawca uzna wtedy, że dostarczenie się nie udało, i ponowi próbę. Dobra praktyka: endpoint weryfikuje podpis, zapisuje zdarzenie w kolejce lub bazie, od razu odpowiada kodem 2xx, a właściwa praca dzieje się w osobnym procesie.

3. Idempotencja - odporność na powtórzenia

Webhooki są zwykle dostarczane w modelu „co najmniej raz”. To znaczy, że to samo zdarzenie może przyjść dwa albo trzy razy, np. po problemie z siecią. Jeśli integracja za każdym razem utworzy zamówienie w ERP, będziesz mieć duplikaty. Rozwiązaniem jest zapisywanie identyfikatora zdarzenia (lub pary: identyfikator obiektu i rodzaj zmiany) i pomijanie zdarzeń, które już zostały przetworzone.

4. Kolejność i aktualność danych

Platformy zazwyczaj nie gwarantują, że zdarzenia dotrą w kolejności, w jakiej zaszły. Aktualizacja statusu może przyjść przed informacją o utworzeniu zamówienia. Bezpieczne podejście to traktowanie webhooka jako sygnału „coś się zmieniło” i pobranie aktualnego stanu obiektu przez API przed zapisaniem go w innym systemie. Alternatywnie można porównywać znacznik czasu ostatniej modyfikacji i ignorować starsze dane.

5. Ponowienia i uzgadnianie

Gdy Twój serwer nie odpowiada, nadawca zwykle ponawia próbę kilka razy, ale po pewnym czasie rezygnuje, a niektóre platformy wyłączają webhook po serii nieudanych dostarczeń. Dlatego obok webhooków warto uruchomić okresowe uzgadnianie: np. raz na godzinę integracja pobiera przez API zamówienia z ostatnich godzin i sprawdza, czy wszystkie zostały przetworzone. To siatka bezpieczeństwa, która wyłapuje zgubione zdarzenia.

[#checklista] Lista kontrolna wdrożenia webhooków: endpoint wyłącznie po HTTPS - weryfikacja podpisu na surowej treści żądania - sekret przechowywany poza kodem źródłowym - odpowiedź 2xx zaraz po zapisaniu zdarzenia - przetwarzanie w kolejce - zapis identyfikatorów zdarzeń i pomijanie duplikatów - pobieranie aktualnego stanu obiektu przez API - logi z czasem przyjęcia i wynikiem przetwarzania - alert przy serii błędów - okresowe uzgadnianie z API - test, co się dzieje, gdy endpoint jest niedostępny przez godzinę.

6. Testy przed uruchomieniem

Webhooki testuje się inaczej niż zwykłe zapytania do API, bo to platforma decyduje, kiedy wyśle powiadomienie. Wiele platform pozwala wysłać zdarzenie testowe z panelu, a niektóre mają narzędzia do ponownego wysłania wybranego zdarzenia. Na etapie wdrożenia warto przejść kilka scenariuszy na środowisku testowym lub sklepie w trybie testowym:

złożenie zamówienia i sprawdzenie, czy trafiło do docelowego systemu dokładnie raz,
ręczne ponowienie tego samego zdarzenia i sprawdzenie, czy nie powstał duplikat,
wysłanie żądania z błędnym podpisem i sprawdzenie, czy zostało odrzucone,
wyłączenie odbiorcy na kilkanaście minut i sprawdzenie, czy po włączeniu zaległe zdarzenia zostały przetworzone lub wyłapane przez uzgadnianie,
zmiana statusu zamówienia kilka razy w krótkim czasie i sprawdzenie, czy w docelowym systemie jest ostatni status.

Typowe błędy przy wdrażaniu webhooków w sklepie internetowym

Brak weryfikacji podpisu - endpoint przyjmuje wszystko, co do niego przyjdzie.
Ciężka logika w endpoincie - przekroczenie czasu odpowiedzi, ponowienia i duplikaty.
Brak obsługi duplikatów - podwójne dokumenty w ERP, podwójne etykiety, dwa maile do klienta.
Zaufanie do kolejności - starszy status nadpisuje nowszy.
Brak monitoringu - webhook został wyłączony przez platformę po serii błędów, a nikt tego nie zauważył.
Endpoint na adresie testowym - po migracji serwera lub zmianie domeny nikt nie zaktualizował adresu w panelu platformy.

[#chart:wpr2c]

Webhooki są szczególnie przydatne w logistyce. Statusy przesyłek, informacja o nadaniu czy doręczeniu mogą od razu trafiać do sklepu i do klienta. Jak połączyć wysyłki InPost z własnym systemem, opisujemy we wpisie ShipX API InPost - jak zintegrować wysyłki z własnym systemem.

Webhooki w e-commerce bez programisty - Make, n8n i integratory

Nie zawsze trzeba pisać własny endpoint. Narzędzia do automatyzacji, takie jak Make, n8n czy Zapier, udostępniają moduły, które generują adres URL do odbioru webhooków i pozwalają zbudować dalszy scenariusz bez kodu. To dobre rozwiązanie na proste przepływy: powiadomienie na komunikatorze o dużym zamówieniu, zapis klienta do listy mailingowej, wpis w arkuszu.

Przy procesach krytycznych - zamówienia do ERP, płatności, stany magazynowe - sprawdź, czy wybrane narzędzie pozwala zweryfikować podpis, obsłużyć duplikaty i zapisać zdarzenia, które się nie powiodły. Jeśli nie, lepiej postawić prosty dedykowany odbiornik, który weryfikuje i kolejkuje zdarzenia, a dopiero potem przekazuje je dalej.

Jak Vinson pomaga przy wdrażaniu webhooków w e-commerce

Projektujemy i wdrażamy integracje oparte na webhookach dla sklepów, bramek płatności, kurierów i systemów magazynowych. Zaczynamy od listy zdarzeń, które realnie zmieniają Twój proces, a potem budujemy odbiorniki z weryfikacją podpisu, kolejką, obsługą duplikatów, logami i uzgadnianiem z API. Przejmujemy też utrzymanie istniejących integracji, które działają niestabilnie. Wycena jest indywidualna, rozliczana godzinowo lub za projekt. Więcej na stronie Wsparcie programistyczne dla e-commerce.

Najczęściej zadawane pytania

Czym jest webhook w sklepie internetowym?

To automatyczne powiadomienie wysyłane przez sklep lub inną platformę pod wskazany adres URL, gdy zajdzie określone zdarzenie, np. złożenie zamówienia lub potwierdzenie płatności. Odbiorca może od razu zareagować, zamiast cyklicznie sprawdzać zmiany przez API.

Czy webhooki mogą całkowicie zastąpić odpytywanie API?

W procesach krytycznych nie warto na tym polegać. Webhooki mogą nie dotrzeć, gdy serwer odbiorcy jest niedostępny. Najbezpieczniej połączyć je z okresowym uzgadnianiem przez API, które wyłapie pominięte zdarzenia.

Dlaczego dostaję ten sam webhook kilka razy?

Platformy ponawiają wysyłkę, gdy nie dostaną szybkiej odpowiedzi z kodem 2xx, a niektóre gwarantują tylko dostarczenie „co najmniej raz”. Endpoint powinien szybko odpowiadać i rozpoznawać zdarzenia, które już przetworzył.

Jak sprawdzić, czy webhook pochodzi z właściwego źródła?

Przez weryfikację podpisu przesyłanego w nagłówku. Endpoint liczy skrót treści z użyciem wspólnego sekretu i porównuje go z podpisem nadawcy. Dodatkowo ruch powinien odbywać się wyłącznie przez HTTPS.

Czy Allegro wysyła webhooki o zamówieniach?

Zmiany w zamówieniach z Allegro pobiera się przez dziennik zdarzeń w REST API, który integracja odpytuje cyklicznie. Integratory, takie jak Base, robią to za Ciebie i mogą dalej przekazywać zamówienia do sklepu lub ERP.

Webhooki przyspieszają przepływ danych w sklepie, ale tylko wtedy, gdy są wdrożone z weryfikacją podpisu, obsługą duplikatów i siatką bezpieczeństwa. Jeśli chcesz uporządkować integracje w swoim sklepie, zajrzyj na stronę Wsparcie programistyczne dla e-commerce. Szerszy kontekst wyboru rozwiązania znajdziesz w artykule integracja sklepu z Allegro - na jakie rozwiązanie postawić.

Jak bezpiecznie wdrożyć webhooki w e-commerce - zasady techniczne

Endpoint webhooka to publiczny adres w internecie, który przyjmuje dane i uruchamia akcje w Twoich systemach. Jeśli każdy może wysłać tam dowolne dane, ktoś może np. oznaczyć zamówienie jako opłacone. Dlatego bezpieczeństwo jest tu warunkiem, a nie dodatkiem.

[#chart:wpr2b]

1. Weryfikacja nadawcy - podpis HMAC

Większość platform podpisuje wysyłane webhooki. Nadawca oblicza skrót treści wiadomości z użyciem tajnego klucza znanego tylko Tobie i jemu (najczęściej HMAC-SHA256), a wynik umieszcza w nagłówku HTTP. Shopify przesyła go w nagłówku X-Shopify-Hmac-Sha256, WooCommerce w X-WC-Webhook-Signature, a Stripe w nagłówku Stripe-Signature. Twój endpoint liczy ten sam skrót po swojej stronie i odrzuca wiadomość, jeśli wyniki się nie zgadzają. Bez tej weryfikacji nie przetwarzaj żadnych danych.

[#uwaga] Podpis liczy się z surowej treści żądania, dokładnie w takiej postaci, w jakiej przyszła. Częsty błąd to weryfikacja po wcześniejszym sparsowaniu i ponownym zapisaniu JSON-a - wtedy podpis nigdy się nie zgadza, a programista pod presją czasu… wyłącza weryfikację. Tego nie wolno robić.

2. Szybka odpowiedź i przetwarzanie w tle

Nadawca czeka na odpowiedź tylko przez ograniczony czas. Jeśli endpoint w tym czasie łączy się z ERP, generuje fakturę i etykietę, łatwo przekroczyć limit - nadawca uzna wtedy, że dostarczenie się nie udało, i ponowi próbę. Dobra praktyka: endpoint weryfikuje podpis, zapisuje zdarzenie w kolejce lub bazie, od razu odpowiada kodem 2xx, a właściwa praca dzieje się w osobnym procesie.

3. Idempotencja - odporność na powtórzenia

Webhooki są zwykle dostarczane w modelu „co najmniej raz”. To znaczy, że to samo zdarzenie może przyjść dwa albo trzy razy, np. po problemie z siecią. Jeśli integracja za każdym razem utworzy zamówienie w ERP, będziesz mieć duplikaty. Rozwiązaniem jest zapisywanie identyfikatora zdarzenia (lub pary: identyfikator obiektu i rodzaj zmiany) i pomijanie zdarzeń, które już zostały przetworzone.

4. Kolejność i aktualność danych

Platformy zazwyczaj nie gwarantują, że zdarzenia dotrą w kolejności, w jakiej zaszły. Aktualizacja statusu może przyjść przed informacją o utworzeniu zamówienia. Bezpieczne podejście to traktowanie webhooka jako sygnału „coś się zmieniło” i pobranie aktualnego stanu obiektu przez API przed zapisaniem go w innym systemie. Alternatywnie można porównywać znacznik czasu ostatniej modyfikacji i ignorować starsze dane.

5. Ponowienia i uzgadnianie

Gdy Twój serwer nie odpowiada, nadawca zwykle ponawia próbę kilka razy, ale po pewnym czasie rezygnuje, a niektóre platformy wyłączają webhook po serii nieudanych dostarczeń. Dlatego obok webhooków warto uruchomić okresowe uzgadnianie: np. raz na godzinę integracja pobiera przez API zamówienia z ostatnich godzin i sprawdza, czy wszystkie zostały przetworzone. To siatka bezpieczeństwa, która wyłapuje zgubione zdarzenia.

[#checklista] Lista kontrolna wdrożenia webhooków: endpoint wyłącznie po HTTPS - weryfikacja podpisu na surowej treści żądania - sekret przechowywany poza kodem źródłowym - odpowiedź 2xx zaraz po zapisaniu zdarzenia - przetwarzanie w kolejce - zapis identyfikatorów zdarzeń i pomijanie duplikatów - pobieranie aktualnego stanu obiektu przez API - logi z czasem przyjęcia i wynikiem przetwarzania - alert przy serii błędów - okresowe uzgadnianie z API - test, co się dzieje, gdy endpoint jest niedostępny przez godzinę.

6. Testy przed uruchomieniem

Webhooki testuje się inaczej niż zwykłe zapytania do API, bo to platforma decyduje, kiedy wyśle powiadomienie. Wiele platform pozwala wysłać zdarzenie testowe z panelu, a niektóre mają narzędzia do ponownego wysłania wybranego zdarzenia. Na etapie wdrożenia warto przejść kilka scenariuszy na środowisku testowym lub sklepie w trybie testowym:

złożenie zamówienia i sprawdzenie, czy trafiło do docelowego systemu dokładnie raz,
ręczne ponowienie tego samego zdarzenia i sprawdzenie, czy nie powstał duplikat,
wysłanie żądania z błędnym podpisem i sprawdzenie, czy zostało odrzucone,
wyłączenie odbiorcy na kilkanaście minut i sprawdzenie, czy po włączeniu zaległe zdarzenia zostały przetworzone lub wyłapane przez uzgadnianie,
zmiana statusu zamówienia kilka razy w krótkim czasie i sprawdzenie, czy w docelowym systemie jest ostatni status.

Typowe błędy przy wdrażaniu webhooków w sklepie internetowym

Brak weryfikacji podpisu - endpoint przyjmuje wszystko, co do niego przyjdzie.
Ciężka logika w endpoincie - przekroczenie czasu odpowiedzi, ponowienia i duplikaty.
Brak obsługi duplikatów - podwójne dokumenty w ERP, podwójne etykiety, dwa maile do klienta.
Zaufanie do kolejności - starszy status nadpisuje nowszy.
Brak monitoringu - webhook został wyłączony przez platformę po serii błędów, a nikt tego nie zauważył.
Endpoint na adresie testowym - po migracji serwera lub zmianie domeny nikt nie zaktualizował adresu w panelu platformy.

[#chart:wpr2c]

Webhooki są szczególnie przydatne w logistyce. Statusy przesyłek, informacja o nadaniu czy doręczeniu mogą od razu trafiać do sklepu i do klienta. Jak połączyć wysyłki InPost z własnym systemem, opisujemy we wpisie ShipX API InPost - jak zintegrować wysyłki z własnym systemem.

Webhooki w e-commerce bez programisty - Make, n8n i integratory

Nie zawsze trzeba pisać własny endpoint. Narzędzia do automatyzacji, takie jak Make, n8n czy Zapier, udostępniają moduły, które generują adres URL do odbioru webhooków i pozwalają zbudować dalszy scenariusz bez kodu. To dobre rozwiązanie na proste przepływy: powiadomienie na komunikatorze o dużym zamówieniu, zapis klienta do listy mailingowej, wpis w arkuszu.

Przy procesach krytycznych - zamówienia do ERP, płatności, stany magazynowe - sprawdź, czy wybrane narzędzie pozwala zweryfikować podpis, obsłużyć duplikaty i zapisać zdarzenia, które się nie powiodły. Jeśli nie, lepiej postawić prosty dedykowany odbiornik, który weryfikuje i kolejkuje zdarzenia, a dopiero potem przekazuje je dalej.

Jak Vinson pomaga przy wdrażaniu webhooków w e-commerce

Projektujemy i wdrażamy integracje oparte na webhookach dla sklepów, bramek płatności, kurierów i systemów magazynowych. Zaczynamy od listy zdarzeń, które realnie zmieniają Twój proces, a potem budujemy odbiorniki z weryfikacją podpisu, kolejką, obsługą duplikatów, logami i uzgadnianiem z API. Przejmujemy też utrzymanie istniejących integracji, które działają niestabilnie. Wycena jest indywidualna, rozliczana godzinowo lub za projekt. Więcej na stronie Wsparcie programistyczne dla e-commerce.

Najczęściej zadawane pytania

Czym jest webhook w sklepie internetowym?

To automatyczne powiadomienie wysyłane przez sklep lub inną platformę pod wskazany adres URL, gdy zajdzie określone zdarzenie, np. złożenie zamówienia lub potwierdzenie płatności. Odbiorca może od razu zareagować, zamiast cyklicznie sprawdzać zmiany przez API.

Czy webhooki mogą całkowicie zastąpić odpytywanie API?

W procesach krytycznych nie warto na tym polegać. Webhooki mogą nie dotrzeć, gdy serwer odbiorcy jest niedostępny. Najbezpieczniej połączyć je z okresowym uzgadnianiem przez API, które wyłapie pominięte zdarzenia.

Dlaczego dostaję ten sam webhook kilka razy?

Platformy ponawiają wysyłkę, gdy nie dostaną szybkiej odpowiedzi z kodem 2xx, a niektóre gwarantują tylko dostarczenie „co najmniej raz”. Endpoint powinien szybko odpowiadać i rozpoznawać zdarzenia, które już przetworzył.

Jak sprawdzić, czy webhook pochodzi z właściwego źródła?

Przez weryfikację podpisu przesyłanego w nagłówku. Endpoint liczy skrót treści z użyciem wspólnego sekretu i porównuje go z podpisem nadawcy. Dodatkowo ruch powinien odbywać się wyłącznie przez HTTPS.

Czy Allegro wysyła webhooki o zamówieniach?

Zmiany w zamówieniach z Allegro pobiera się przez dziennik zdarzeń w REST API, który integracja odpytuje cyklicznie. Integratory, takie jak Base, robią to za Ciebie i mogą dalej przekazywać zamówienia do sklepu lub ERP.

Webhooki przyspieszają przepływ danych w sklepie, ale tylko wtedy, gdy są wdrożone z weryfikacją podpisu, obsługą duplikatów i siatką bezpieczeństwa. Jeśli chcesz uporządkować integracje w swoim sklepie, zajrzyj na stronę Wsparcie programistyczne dla e-commerce. Szerszy kontekst wyboru rozwiązania znajdziesz w artykule integracja sklepu z Allegro - na jakie rozwiązanie postawić.

Webhooki w e-commerce - do czego służą i jak je bezpiecznie wdrożyć