Po n8n sięga się wtedy, gdy CRM ma porozmawiać z czymś, o czym nie ma pojęcia: bazą magazynową, wewnętrzną usługą, cudzym API. I pierwsza godzina schodzi na pytanie, które poradniki omijają — gotowego węzła „Bitrix24” nie ma czego przeciągnąć na płótno. Połączenie mimo to działa, tylko składa się je z ogólnych klocków, a psuje się potem zawsze w tych samych miejscach. Poniżej działający kształt połączenia Bitrix24 (Alaio) z n8n w obie strony.

Czy w n8n jest węzeł Bitrix24?

Oficjalnego nie ma. Strona Bitrix24 u samego n8n odsyła do węzła HTTP Request z ogólnym uwierzytelnianiem — i to jest uczciwa odpowiedź: REST API wywołujesz samodzielnie. Istnieją pakiety społecznościowe, część z nich porządnie obsługuje encje CRM, zadania i telefonię, ale utrzymują je osoby trzecie, za zmianami API nadążają z opóźnieniem, a na instancjach zarządzanych ich instalacja to decyzja regulaminowa, nie kliknięcie. Przy scenariuszu na trzy–cztery metody węzeł HTTP Request kosztuje mniej niż audyt cudzego kodu: API to zwykły JSON po HTTPS, a jeden węzeł obsłuży dowolną metodę.

Jak n8n zapisuje dane w Bitrix24?

Przez webhook przychodzący. W portalu tworzy się go w sekcji dla programistów: zaznaczasz potrzebne uprawnienia i dostajesz adres w postaci https://<portal>/rest/<id-uzytkownika>/<token>/<metoda>.json. Autoryzacja siedzi w samym adresie, więc węzeł HTTP Request nie potrzebuje niczego poza tym linkiem i ostrożnością w obchodzeniu się z nim. Nazwa metody i parametry jadą dokładnie tak, jak opisuje dokumentacja: crm.item.add, crm.item.update, tasks.task.add.

Dwie cechy tego adresu decydują o niemal wszystkim, co wydarzy się później. Webhook działa z uprawnieniami pracownika, który go utworzył — scenariusz nieposiadający dostępu do lejka polegnie na uprawnieniach przy całkowicie ważnym tokenie, dlatego webhooki zakładaj na koncie serwisowym, a nie na tym, kto akurat siedział przy komputerze. Token zaś nie odnawia się sam: żyje, dopóki ktoś go nie usunie albo nie dezaktywuje tego pracownika — stąd wygoda i stąd cena wycieku. Mechanika obu kierunków jest opisana w przewodniku po webhookach.

Jak uruchomić scenariusz n8n z Bitrix24?

Są dwie drogi i zachowują się inaczej. Webhook wychodzący portalu subskrybuje zdarzenia — zmieniona szansa sprzedaży, nowy lead — i puka pod adres twojego węzła Webhook. Odpala się przy każdym pasującym zdarzeniu, nieważne, czy zmiana przyszła od człowieka, z importu, czy od innej integracji. Treść przychodzi jako dane formularza, a nie JSON, dlatego przy pierwszym przebiegu węzeł pokazuje pojedyncze pola zamiast body.

Druga droga woła n8n z samego procesu. Reguła Żądanie HTTP GET/POST uderza w adres węzła Webhook dokładnie w tym miejscu, które wybierzesz, i wysyła tylko te dane, które chcesz wysłać. Zbuduj JSON z pól złoży treść z wartości procesu bez ręcznego escapowania cudzysłowów, a Wyodrębnij wartość z JSON po ścieżce wciągnie odpowiedź n8n z powrotem do procesu — o obróbce odpowiedzi więcej w artykule o JSON w procesach biznesowych. Tam, gdzie dostarczenia nie wolno zgubić — zamówienie poszło na produkcję, dokument na podpis — postaw Niezawodny webhook: ponawia według własnego harmonogramu i melduje, ile prób było potrzebnych, zamiast zamilknąć po pierwszej porażce.

Którą połowę scenariusza lepiej zostawić w portalu?

Tę, która i tak nigdy z niego nie wychodzi. Zmiana etapu, wypełnienie pola, postawienie zadania, rozgałęzienie po warunku: przepuszczając to przez zewnętrzny scenariusz, kupujesz dodatkową drogę przez sieć, drugie miejsce do debugowania i limit, którego trzeba pilnować — i nic poza tym. Rozsądny podział jest prosty: n8n odpowiada za systemy na zewnątrz, portal za własne rekordy, a między nimi jedno wywołanie. Koszt takiej decyzji rozłożyliśmy na części w porównaniu konektorów z automatyzacją wewnątrz portalu; sama część wewnętrzna to zwyczajna konfiguracja reguł automatyzacji.

Dlaczego scenariusz milczy?

Zacznij od strony n8n: węzeł Webhook ma dwa adresy, testowy i produkcyjny, a produkcyjny odpowiada wyłącznie przy aktywnym scenariuszu — połączenie zbudowane i sprawdzone w trybie testowym milknie dokładnie wtedy, gdy przestajesz na nie patrzeć. Potem strona portalu: webhook wychodzący podpięty pod niewłaściwe zdarzenie albo pod typ encji, którego reguła nigdy nie dotyka, nie wygeneruje żadnego żądania, więc pusta lista przebiegów w n8n to sprawa subskrypcji, a nie sieci.

Jeśli żądania dochodzą, ale wracają z błędem, przeczytaj jego treść, zamiast ponawiać: brak uprawnień webhooka, zły kod pola i przekroczony limit wyglądają jednakowo jak „nie działa”, a naprawia się je inaczej. Limit warto trzymać w głowie osobno — portal dopuszcza kilka wywołań na sekundę, a pętla po kilkuset rekordach bez przerw wchodzi w niego sama z siebie. A gdy nie ruszyła reguła, od której wszystko miało się zacząć, pomaga rozbiór dlaczego reguły automatyzacji nie działają.

Co dalej

Rozłóż swój scenariusz na dwie listy: kroki dotykające systemów zewnętrznych i kroki dotykające wyłącznie rekordów portalu. Druga lista przenosi się do środka — zwykle zostaje potem po jednym webhooku w każdą stronę, a to utrzymuje się przy życiu znacznie łatwiej. Klocki do części portalowej są w katalogu reguł, a jeśli brakuje tej właściwej, opisz zadanie: Roboteka tworzy brakujące reguły za darmo i publikuje je we wspólnej bibliotece.