Webhook to mechanizm powiadamiania między systemami, w którym system źródłowy sam wywołuje zarejestrowany adres URL odbiorcy w momencie wystąpienia zdarzenia. To odwrotność klasycznego odpytywania (polling): zamiast pytać co minutę „czy coś się zmieniło?", odbiorca czeka, aż nadawca da znać.
Analityk biznesowy spotyka webhooki przy specyfikowaniu integracji, szczególnie z usługami SaaS: bramki płatności, systemy mailingowe, podpisy elektroniczne, komunikatory. Zadaniem analityka jest zmapowanie zdarzeń biznesowych na webhooki („co ma się stać u nas, gdy u nich zajdzie X?") i opisanie scenariuszy błędów.
Przykład z MediFlow: pacjent płaci online za wizytę komercyjną. Operator płatności wysyła webhook „płatność potwierdzona" na endpoint MediFlow i status wizyty zmienia się w ciągu sekund. Przed wdrożeniem webhooków system odpytywał operatora co 5 minut - pacjent płacił, potem patrzył na status „oczekuje na płatność" i dzwonił na infolinię. Po zmianie architektury integracji: 80 telefonów miesięcznie mniej.
Częsta pomyłka: mylenie webhooka z API. API to interfejs, przez który ty wołasz cudzy system; webhook to cudzy system wołający ciebie. Druga, poważniejsza w skutkach: zakładanie, że webhook zawsze dojdzie. Nie dojdzie - sieci się sypią, serwery restartują. Specyfikacja integracji musi przewidywać ponowienia (retry), idempotencję (ten sam webhook dostarczony dwa razy nie może zaksięgować płatności podwójnie) i mechanizm uzgadniania stanu, gdy powiadomienie przepadnie. Analityk, który o to nie zapyta, znajdzie odpowiedź na produkcji.