Automatyzacja w HubSpot: webhooki i onboarding klienta
Jak połączyliśmy HubSpot z Microsoft 365 przez webhooki, żeby nowa transakcja uruchamiała onboarding klienta. Opisujemy architekturę i zabezpieczenia.
HubSpot da się połączyć z innymi systemami bez ręcznego przepisywania danych. Gdy w CRM zmienia się transakcja, HubSpot może wysłać webhook (żądanie HTTP z informacją o zdarzeniu) do Twojej aplikacji. Aplikacja wykonuje dalsze kroki. U siebie użyliśmy tego do onboardingu: nowa transakcja w HubSpot uruchamia proces, który zakłada potrzebne konta w Microsoft 365.
Poniżej opisujemy, jak taki przepływ zbudować, żeby był bezpieczny i odporny na błędy. To narzędzie wewnętrzne. Dlatego pokazujemy zasady, według których budujemy takie przepływy, bez szczegółów konfiguracji.
Problem z ręcznym onboardingiem
Ręczny onboarding to zwykle lista kroków w czyjejś głowie: założyć konta, nadać licencje, dodać do grup, wysłać dane dostępowe, zapisać wszystko w CRM. Każdy krok jest prosty, ale razem łatwo o pominięcie albo literówkę w adresie e-mail. Problem rośnie, gdy kilka osób zamyka transakcje i każda robi to trochę inaczej.
Automatyzacja nie zastępuje decyzji handlowca. Przesuwa moment, w którym trzeba pamiętać o krokach technicznych. Handlowiec zmienia etap transakcji w HubSpot, a resztę wykonuje system, za każdym razem tak samo.
Jak działa przepływ od transakcji do kont w Microsoft 365?
Taki przepływ warto podzielić na cztery etapy:
| Etap | Co się dzieje | Na co uważać |
|---|---|---|
| Zdarzenie w HubSpot | Transakcja trafia do określonego etapu, HubSpot wysyła webhook | Wysyłaj tylko zdarzenia, których naprawdę potrzebujesz |
| Odbiór webhooka | Usługa odbierająca sprawdza podpis żądania i zapisuje zdarzenie do przetworzenia | Odpowiedz szybko, przetwarzaj później |
| Przetwarzanie | Pobranie pełnych danych transakcji z API HubSpot (interfejsu do wymiany danych), założenie kont w Microsoft 365 | Każdy krok musi dać się bezpiecznie powtórzyć |
| Zapis wyniku | Informacja o wyniku wraca do HubSpot, a błąd trafia do zespołu jako powiadomienie | Błąd ma być widoczny dla człowieka, nie tylko w logach |
Nasze narzędzia wewnętrzne uruchamiamy w AWS. Dlaczego do krótkich zadań uruchamianych zdarzeniem wybieramy usługi bezserwerowe, opisaliśmy we wpisie hosting aplikacji: AWS czy własny serwer.
Odbiór webhooka oddzielony od przetwarzania
Najprostsza implementacja webhooka wygląda tak: odbierz żądanie, załóż konta, odpowiedz. Działa na demo, a w praktyce sprawia kłopoty:
- Operacje trwają długo. Zakładanie kont i nadawanie licencji to kilka wywołań API, z których każde może chwilę trwać albo chwilowo się nie udać. Nadawca webhooka nie powinien czekać na ich zakończenie.
- Zdarzenia się powtarzają. Każdy system webhooków może dostarczyć to samo zdarzenie więcej niż raz, np. gdy odpowiedź nie dotarła na czas. Jeśli każde wywołanie zakłada konta od zera, powstają duplikaty.
- Błędy bywają częściowe. Gdy trzy kroki się udały, a czwarty nie, trzeba wiedzieć, od którego miejsca zacząć ponownie.
Dlatego odbiór warto oddzielić od przetwarzania. Usługa odbierająca webhook tylko sprawdza podpis, zapisuje zdarzenie i od razu odpowiada. Przetwarzanie dzieje się osobno, krok po kroku. Każdy krok najpierw sprawdza, czy nie został już wykonany (np. czy konto o tym adresie już istnieje). Taką właściwość nazywa się idempotencją. Ponowne wykonanie daje ten sam wynik i nie tworzy drugiego konta.
Jak zabezpieczyć adres odbierający webhooki?
Adres, pod który HubSpot wysyła webhooki, jest publiczny. Bez zabezpieczeń każdy, kto go pozna, może wywołać onboarding. Minimum, które uważamy za obowiązkowe:
- Sprawdzaj podpis. HubSpot podpisuje żądania. W nowszej wersji (v3) podpis to HMAC SHA-256 liczony z sekretu aplikacji, metody, adresu, treści żądania i znacznika czasu. HubSpot zaleca odrzucać żądania starsze niż 5 minut (walidacja żądań w dokumentacji HubSpot, stan na 6.11.2026). Uwaga: żądania z akcji webhook w workflow są podpisywane starszą wersją (v2). Sprawdź, którą obsługujesz.
- Pobieraj szczegóły transakcji z API HubSpot. Treść webhooka traktuj tylko jako sygnał „coś się zmieniło”. Wtedy nawet spreparowana treść żądania nie zdecyduje o tym, jakie konta powstaną.
- Nadawaj najmniejsze potrzebne uprawnienia. Token do HubSpot powinien mieć dostęp tylko do obiektów, których proces potrzebuje. Uprawnienia po stronie Microsoft 365 powinny obejmować tylko operacje, które proces wykonuje.
- Trzymaj sekrety poza kodem. Klucze i sekrety należą do usługi do zarządzania sekretami. Nie zapisuj ich w repozytorium ani na sztywno w kodzie.
Inne integracje z HubSpot w naszych narzędziach
Onboarding nie jest jedyną integracją w naszych narzędziach wewnętrznych. Mamy też przesyłanie danych z Fakturowni do HubSpot, raporty czasu z Jiry i pobieranie danych z KRS. Wszystkie łączą programy, między którymi inaczej trzeba by przenosić dane ręcznie.
Z tych projektów mamy kilka wniosków, które przenosimy na integracje budowane dla klientów:
- Zacznij od jednego procesu, który sprawia najwięcej kłopotu, zamiast od „integracji wszystkiego ze wszystkim”.
- Ustal, który system jest źródłem prawdy dla każdego pola. Jeśli adres firmy można zmienić w dwóch miejscach, po miesiącu będą dwa różne adresy.
- Zaplanuj obsługę błędów od początku. Integracja bez powiadomień o błędach, która „zwykle działa”, jest gorsza niż ręczny proces. Nikt nie wie, kiedy przestała działać.
- Zapisuj, co integracja zrobiła. Historia zdarzeń pozwala odpowiedzieć na pytanie „dlaczego to konto powstało?” bez przeszukiwania logów.
Co zmieniła automatyzacja onboardingu
Cel był przede wszystkim jakościowy. Onboarding ma nie zależeć od tego, kto zamknął transakcję i czy pamiętał o wszystkich krokach. Konta powstają według jednego schematu. Błąd w którymkolwiek kroku ma trafić do człowieka i nie zginąć w logach.
Kiedy taka automatyzacja ma sens w Twojej firmie?
Integracja przez webhooki opłaca się, gdy ten sam ciąg kroków powtarza się regularnie, kroki są jasno opisane, a oba systemy mają API. Jeśli proces jest rzadki albo każdy przypadek wygląda inaczej, lepiej zacząć od listy kontrolnej w CRM. Inny przypadek to logowanie do własnej aplikacji kontem firmowym Microsoft 365. Do tego potrzebujesz innej integracji: logowania przez Microsoft Entra ID.
Jeśli w Twojej firmie ktoś codziennie przepisuje dane między CRM a innymi programami, opisz nam ten proces. Ocenimy, czy da się go zautomatyzować i ile pracy to wymaga.
