Przejdź do treści
fromHello

Webhook

Webhook to wywołanie zwrotne HTTP: jeden system wysyła automatyczne żądanie POST na kontrolowany przez Ciebie URL w chwili, gdy zajdzie wybrane zdarzenie, zamiast czekać, aż o to zapytasz. To wypychanie danych, a nie odpytywanie (polling) – źródło przesyła dane w miarę pojawiania się zdarzeń, więc Twój endpoint dostaje je w ciągu kilku sekund, zamiast odpytywać źródło według harmonogramu.

Zaktualizowano 2 min czytaniaAutor: fromHello

Najważniejsze wnioski

  1. Webhook to wypychanie danych, a nie odpytywanie: system źródłowy wysyła dane w chwili, gdy zajdzie zdarzenie, więc odpadają ciągłe zapytania „czy jest coś nowego?”.

  2. Na platformach customer engagement liczą się dwa kierunki – węzły wychodzące wywołują systemy zewnętrzne w trakcie ścieżki, a odbiorniki przychodzące przyjmują od nich zdarzenia.

  3. Ponieważ każdy może wysłać POST na publiczny URL, traktuj każdy ładunek jako niezaufany: weryfikuj podpis i odpowiadaj szybko.

Jak działa webhook?

Rejestrujesz URL – endpoint – w systemie, który przechowuje dane, i wskazujesz, które zdarzenia Cię interesują. Gdy jedno z nich zajdzie, ten system wysyła na Twój endpoint żądanie HTTP POST z ładunkiem opisującym, co się stało, zwykle w formacie JSON. Twój serwer odczytuje ładunek, wykonuje swoją pracę i zwraca status 2xx, żeby potwierdzić odbiór. Nie wywołało go żadne Twoje żądanie – źródło zadziałało z własnej inicjatywy. Większość dostawców podpisuje każde żądanie, żeby można było potwierdzić, że naprawdę pochodzi od nich.

Webhook vs odpytywanie API: jaka jest różnica?

Odpytywanie (polling) to model pobierania: Twój kod pyta API „czy jest coś nowego?” według stałego harmonogramu, niezależnie od tego, czy cokolwiek się zmieniło. Webhook to model wypychania: źródło wywołuje Cię tylko wtedy, gdy ma coś do przekazania. Odpytywanie marnuje większość żądań i dodaje opóźnienie między zdarzeniem a Twoją reakcją; webhooki dostarczają dane w ciągu kilku sekund, a poza tym milczą. Kosztem jest to, że Twój endpoint musi być publicznie dostępny i gotowy na nagłe skoki ruchu.

Webhook i pokrewne pojęcia.

Jak platformy customer engagement używają webhooków?

  • Wychodzące – węzeł webhook wewnątrz ścieżki wysyła POST do systemu zewnętrznego w trakcie przebiegu: powiadamia Slacka, gdy lead dokona konwersji, synchronizuje status z Twoim CRM-em, uruchamia krok realizacji zamówienia.
  • Przychodzące – odbiornik przyjmuje zdarzenia z innych narzędzi: operator płatności zgłasza udane obciążenie, narzędzie do formularzy przekazuje nowego leada, więc profile i ścieżki reagują bez nocnego importu.
  • Ta dwukierunkowa instalacja sprawia, że platforma customer engagement może stać w centrum Twojego stosu narzędzi. Wyspecjalizowane usługi dostarczania, takie jak Knock, zajmują się wyłącznie stroną wychodzącą.

Dlaczego to ważne dla małego zespołu

Dwuosobowy zespół nie może siedzieć i odpytywać o zmiany, a zadania cron sprawdzające co kilka minut dodają i opóźnienie, i koszt. Webhooki pozwalają jednemu narzędziu reagować na drugie w chwili, gdy coś się dzieje, bez nikogo, kto by tego pilnował. Dwie przestrogi: ponieważ każdy może wysłać POST na publiczny URL, weryfikuj podpis każdego żądania i traktuj treść jako niezaufaną; oraz loguj zdarzenia, które wysyłasz i odbierasz, żeby zgadzały się z Twoim planem śledzenia, zamiast stać się nieśledzonym kanałem bocznym.

Źródła

  1. Red Hat – What is a webhook? (otwiera się w nowej karcie)
  2. GitHub Docs – About webhooks (otwiera się w nowej karcie)

FAQ

Najczęstsze pytania

  • Czym różni się webhook od API?

    API to coś, co wywołujesz, gdy chcesz dostać dane; webhook to coś, co wywołuje Ciebie, gdy dane się zmieniają. Uzupełniają się: często używasz REST API do odczytu lub aktualizacji rekordów, a webhooka do powiadamiania Cię w chwili zmiany rekordu, żeby nie trzeba było ciągle pytać.

  • Jak zabezpieczyć endpoint webhooka?

    Traktuj każde żądanie jako niezaufane. Większość dostawców podpisuje ładunek wspólnym sekretem – oblicz podpis ponownie i odrzuć wszystko, co się nie zgadza. Udostępniaj endpoint przez HTTPS i szybko zwracaj 2xx, a wolną pracę wykonuj w zadaniu w tle, żeby nadawca nie przekroczył limitu czasu i nie ponawiał wysyłki.

  • Co się stanie, jeśli mój endpoint nie działa, gdy webhook zostaje wywołany?

    Większość dostawców przez jakiś czas ponawia nieudane dostarczenia z rosnącymi odstępami (backoff), a potem się poddaje, więc krótką awarię zwykle da się przetrwać. Ponawianie nie trwa jednak w nieskończoność – zadbaj o idempotentność obsługi, bo to samo zdarzenie może przyjść więcej niż raz, i uzgadniaj dane z API źródła we wszystkim, czego nie możesz przegapić.

  • Czy muszę coś budować, żeby odbierać webhooki?

    Potrzebujesz publicznie dostępnego URL-a HTTPS, który przyjmuje żądania POST i zwraca 2xx. W przypadku webhooków przychodzących do platformy customer engagement taki odbiornik jest zwykle wbudowany – wklejasz swój URL w narzędziu wysyłającym. W przypadku wywołań wychodzących wysyłką zajmuje się za Ciebie węzeł webhook w ścieżce.

fromHello to oprogramowanie open source do automatyzacji marketingu: wiadomości uruchamiane przez to, co robią ludzie.

fromHello Cloud udostępniamy w ramach wczesnego dostępu, przez listę oczekujących.

Dołącz do listy oczekującychDaj gwiazdkę na GitHubie (otwiera się w nowej karcie)

Czytaj dalej

Wszystkie poradniki

Wczesny dostęp

fromHello Cloud

Nikt nie zakłada firmy, żeby była mała.

Wczesny dostęp do fromHello Cloud otwieramy etapami. Onboarding prowadzimy razem z Tobą: pomagamy wszystko skonfigurować i przenieść Twoje kontakty.

Napiszemy do Ciebie, gdy otworzymy Ci dostęp. Bez spamu.

Jeszcze nie teraz? Zobacz na GitHubie