Konfiguracja i zabezpieczanie webhooków

Konfiguracja webhooków w PSB: topiki, zabezpieczenie HMAC SHA256 i IP whitelisting.

Webhooki są podstawową metodą otrzymywania powiadomień w czasie rzeczywistym z PSB. Przy każdym istotnym zdarzeniu, otrzymanej fakturze, zmianie statusu, potwierdzeniu dostarczenia, PSB wysyła żądanie HTTP POST do endpointu z danymi zdarzenia.

Jak działają webhooki w PSB?

Rejestruje się webhook ("hook") w PSB z adresem URL i topikiem. PSB wysyła następnie wszystkie zdarzenia danego topiku na podany URL. Każde zdarzenie zawiera odpowiednie dane jako payload JSON.

Tworzenie webhooka

Brak interfejsu użytkownika: obecnie nie ma możliwości konfigurowania hooka przez interfejs użytkownika platformy. Hooki konfiguruje się przez API lub przez wsparcie eConnect. Interfejs samoobsługi dla hooków jest w planie rozwoju (planowany na Q4 2026) i będzie częścią Control (Platform 2.0): użytkownicy będą wtedy mogli sami tworzyć, edytować i usuwać hooki. Do tego czasu nie jest planowany artykuł krok po kroku dotyczący ręcznej konfiguracji hooków przez API.

Rejestracja hooka przez API:

POST /api/v1/hook

Najważniejsze elementy konfiguracji:

PoleOpisurlEndpoint HTTPS, na który PSB wysyła zdarzeniatopicTyp zdarzenia, które ma być nasłuchiwane (np. InvoiceReceived)secretTajny klucz do weryfikacji podpisu HMAC

Uwaga: unikaj szybkiego usuwania i ponownego tworzenia hooków dla tego samego partyId i topiku. Z powodu race conditions w przetwarzaniu zadań może to tymczasowo skutkować brakiem aktywnego hooka, co powoduje niedostarczenie zdarzeń. Po usunięciu hooka poczekaj chwilę przed utworzeniem nowego lub użyj aktualizacji zamiast usunięcia i ponownego utworzenia.

Dodawanie topiku do istniejącego hooka

Chcesz dodać dodatkowy topik (np. InvoiceReceived) do istniejącego hooka? Zaktualizuj istniejącą konfigurację webhooka przez standardowe API /hook, tak aby pożądany topik znajdował się w tablicy topics:

{
  "topics": ["InvoiceReceived"]
}

Zaktualizuj istniejący hook zamiast go usuwać i ponownie tworzyć. Usuwanie i ponowne tworzenie powoduje race condition, w której zdarzenia mogą tymczasowo nie być dostarczane (patrz ostrzeżenie powyżej).

Brak samoobsługi dla klientów nietech nicznych. Dodanie topiku do istniejącego hooka to zadanie techniczne: osoba wykonująca je musi wiedzieć, dokąd powinien trafić webhook (URL endpointu) i rozumieć, czym jest webhook. Klient nietech niczny zazwyczaj nie może zrobić tego samodzielnie. Zaangażuj osoby z wiedzą techniczną (dział IT klienta lub wsparcie eConnect).

Najczęściej używane topiki
TopikKiedyInvoiceReceivedOtrzymano fakturę zakupowąInvoiceSentFaktura sprzedażowa została pomyślnie wysłanaInvoiceSentErrorFaktura sprzedażowa nie mogła zostać dostarczonaInvoiceSentRetryRozpoczęto próbę ponownego wysłaniaInvoiceResponseReceivedOtrzymano Invoice Response (komunikaty statusowe)OrderReceivedOtrzymano zamówienie zakupowe
Zabezpieczanie webhooków za pomocą HMAC

PSB zabezpiecza wszystkie dostarczenia webhooków za pomocą podpisów HMAC SHA256. Przy każdym żądaniu PSB wysyła header:

X-EConnect-Signature: sha256={handtekening}
Implementacja weryfikacji

Aby zweryfikować podpis:

  1. Pobrać surowy payload JSON z żądania.
  2. Obliczyć hash HMAC SHA256 za pomocą tajnego klucza (tego samego, który podano przy tworzeniu hooka).
  3. Porównać obliczony hash z wartością w headerze X-EConnect-Signature.
  4. Jeśli się zgadzają, żądanie jest autentyczne.
Zapobieganie atakom replay

Należy również sprawdzać pole sentOn w payloadzie. Jeśli ten znacznik czasu jest starszy niż 5 minut, żądanie należy odrzucić. Zapobiega to atakom replay, w których przechwycone żądanie jest odtwarzane później.

Dodatkowe opcje zabezpieczeń

Oprócz weryfikacji HMAC, PSB oferuje dodatkowe warstwy bezpieczeństwa:

  • IP whitelisting: ograniczenie przychodzących żądań do IP produkcyjnych PSB (104.40.188.59 i 104.47.148.207)
  • Uwierzytelnianie OAuth dla webhooków: PSB może uwierzytelniać się w endpoincie za pomocą danych OAuth2
  • Mutual SSL: użycie certyfikatów klienta do wzajemnego uwierzytelniania TLS
Kolejność priorytetów

Gdy skonfigurowanych jest wiele hooków, PSB określa, który hook ma być użyty, na podstawie:

  1. Hooki na poziomie PartyId mają pierwszeństwo przed hookami na poziomie environment
  2. Specyficzne topiki mają pierwszeństwo przed wildcardami
  3. Gdy wiele hooków z filtrami odpowiada temu samemu topikowi: wygrywa najdłuższy filtr (liczony w znakach) -- na przykład filtr z dodatkową klauzulą && wygrywa z krótszym filtrem bez tej klauzuli. Zapobiega to podwójnemu dostarczeniu bez konieczności wzajemnego wykluczania się filtrów.
  4. Przy równym priorytecie: hook-id jako kryterium rozstrzygające
Rozwiązywanie problemów

Poniżej przedstawiono typowe problemy z webhookami i sposoby ich rozwiązania.

ObjawPrzyczynaRozwiązanieWebhooki nie docierająEndpoint niedostępny (limit czasu 100 sek.)Wymagane HTTPS + ważny certyfikat SSL; wyłączyć ochronę CSRF na endpoincie webhookWebhook odrzucony jako niezabezpieczonyWalidacja X-EConnect-Signature kończy się niepowodzeniemSprawdzić obliczenie HMAC SHA256: payload × secret → ciąg szesnastkowy z prefiksem sha256=Atak powtarzania zablokowanyPole sentOn starsze niż 5 minutEndpoint przetwarza zbyt wolno lub zegar jest błędnie ustawiony"No such host is known" (błąd DNS)Nazwa hosta endpointu webhook nie jest już rozwiazywalna, np. po zmianie nazwy środowiska ERP lub wygaşnięciu rekordu DNSSprawdzić i przywrócić rekord DNS domeny endpointu; następnie pobrać brakujące zdarzenia przez endpoint batchHookSentError (ostateczny błąd)PSB próbował przez 5 dni bez odpowiedzi 2xxSprawdzić logi endpointu; monitorować topic HookSentError (patrz niżej); pobrać brakujące zdarzenia przez endpoint batchStare faktury dostarczone ponownieAPI nie zwraca 2xx przy pierwszym odbiorzeEndpoint musi zawsze zwracać 2xx, także dla przetwarzania asynchronicznegoZduplikowane przetwarzanie przy ponowieniuBrak kontroli idempotencjiUżyć nagłówka X-EConnect-Delivery (unikalne UUID) do deduplikacji
Monitorowanie i odzyskiwanie po HookSentError

PSB wysyła zdarzenia webhook (np. InvoiceReceived po otrzymaniu e-faktury) do skonfigurowanego endpointu. Jeśli ten endpoint jest niedostępny — z powodu limitu czasu, błędu SSL lub błędu DNS jak No such host is known — PSB ponawia próby z wykładniczym wycofaniem przez 5 dni (limit czasu 100 sek. na próbę). Każda próba generuje zdarzenie HookSentRetry; po 5 dniach bez odpowiedzi 2xx emitowany jest HookSentError jako status końcowy i PSB kończy ponowne próby.

Konsekwencja: otrzymana e-faktura nie zostanie dostarczona do klienta, dopóki endpoint jest niedostępny, bez wiedzy klienta. Zalecane działania:

  • Skonfigurować monitorowanie: subskrybować hook (np. mail-hook) do topicu HookSentError, aby ostateczny błąd dostarczenia był aktywnie sygnalizowany zamiast pozostać niezauważony. Rozważyć również HookSentRetry do wczesnego wykrywania.
  • Naprawić przyczynę główną: w przypadku błędu DNS sprawdzić i przywrócić rekord DNS domeny endpointu; w przypadku limitów czasu sprawić, by endpoint odpowiadał szybciej (2xx w ciągu 100 sek., ciężkie przetwarzanie asynchronicznie).
  • Odzyskać brakujące zdarzenia: zdarzenia, które nie powiodły się podczas awarii, można pobrać przez endpoint batch. Pięciodniowe okno ponowień oznacza, że terminowe usunięcie usterki w tym okresie może jeszcze uzupełnić zaległości przez regularne dostarczanie.
Najlepsze praktyki
  • Zawsze używać HTTPS dla endpointu webhookowego
  • Implementować idempotentne przetwarzanie: PSB może w rzadkich przypadkach dostarczyć zdarzenie więcej niż raz
  • Szybko zwracać kod statusu 2xx: PSB traktuje każdą odpowiedź inną niż 2xx jako błąd i ponowi próbę dostarczenia zdarzenia
  • Logować wszystkie otrzymane zdarzenia do celów debugowania i audytu
  • Używać systemu kolejkowego (queue) po swojej stronie, jeśli przetwarzanie zajmuje czas: najpierw potwierdzić odbiór, potem przetwarzać
Często zadawane pytania
Jak zweryfikować przychodzący webhook za pomocą HMAC SHA256?

Należy wziąć surowe ciało JSON żądania, obliczyć hash HMAC SHA256 przy użyciu sekretu podanego podczas tworzenia hooka i porównać go z wartością w nagłówku X-EConnect-Signature (po prefiksie sha256=). Jeśli wartości się zgadzają, oznacza to, że żądanie pochodzi z PSB i nie zostało zmodyfikowane w trakcie przesyłania.

Dlaczego należy sprawdzać pole sentOn w payloadzie?

Należy sprawdzić, czy sentOn nie jest starszy niż 5 minut. Jeśli znacznik czasu jest zbyt stary, żądanie należy odrzucić. Zapobiega to atakom typu replay, w których wcześniej przechwycone żądanie jest ponownie przesyłane, nawet jeśli podpis jest technicznie poprawny.

Jak uniknąć problemów z idempotentnym przetwarzaniem i ponowieniami?

Należy zaimplementować idempotentne przetwarzanie po swojej stronie, ponieważ PSB może w rzadkich przypadkach dostarczyć zdarzenie więcej niż raz. Ponadto należy szybko zwrócić kod statusu HTTP 2xx: każda inna odpowiedź jest traktowana jako błąd i powoduje ponowienie. W przypadku złożonego przetwarzania warto najpierw potwierdzić odbiór, a następnie przetworzyć dane za pomocą kolejki.


Wolą Państwo pobierać dokumenty hurtowo? Batch hook.

Zobacz endpointy webhooków

Powiązane