Połącz WhatsApp z Bitrix24 CRM na numerze Coexistence

Jak n8n komunikuje się z Bitrix24?

Przez przychodzący webhook, który w Bitrix24 nie jest odbiornikiem, tylko danymi uwierzytelniającymi. Tworzysz go w zasobach dla deweloperów Bitrix24, wybierasz zakresy uprawnień, z których może korzystać, i dostajesz adres URL zawierający adres Twojego portalu, identyfikator użytkownika, który go utworzył, oraz tajny kod. Dopisanie nazwy metody do tego adresu wywołuje REST API jako ten użytkownik, z jego uprawnieniami.

W n8n każdy krok dotyczący Bitrix24 to więc węzeł HTTP Request wysyłający żądanie POST na ten adres wraz z metodą, na przykład crm.lead.add.json. Nie ma przepływu OAuth do ukończenia ani aplikacji do publikowania. Nadaj webhookowi wyłącznie zakres CRM i utwórz go z konta użytkownika, którego uprawnienia obejmują leady i kontakty potrzebne przepływowi, ponieważ Bitrix24 sprawdza dostęp właśnie jako ten użytkownik.

Jakie metody Bitrix24 wywołuje przepływ?

Trzy, po kolei, gdy węzeł Webhook w n8n odbierze wiadomość od Meta.

crm.duplicate.findbycomm z typem PHONE i numerem nadawcy zwraca identyfikatory leadów, kontaktów i firm, które ten numer posiadają. To właściwe wyszukiwanie, bo przeszukuje wszystkie trzy typy naraz i jest zaprojektowane do dopasowywania po danych kontaktowych, a nie po polu tekstowym.

Gdy nic nie zwróci, crm.lead.add tworzy lead z nazwą profilu WhatsApp jako tytułem i numerem w polu telefonu. Następnie crm.timeline.comment.add zapisuje treść wiadomości jako komentarz do rekordu, przyjmując ENTITY_TYPE, ENTITY_ID i COMMENT. Komentarz pojawia się na osi czasu rekordu obok połączeń i e-maili, czyli tam, gdzie handlowiec już zagląda.

POST https://yourcompany.bitrix24.com/rest/1/<secret>/crm.duplicate.findbycomm.json
{ "type": "PHONE", "values": ["14155550188"] }

POST .../crm.lead.add.json
{ "fields": { "TITLE": "WhatsApp: Maria", "PHONE": [{ "VALUE": "14155550188", "VALUE_TYPE": "MOBILE" }] } }

POST .../crm.timeline.comment.add.json
{ "fields": { "ENTITY_TYPE": "lead", "ENTITY_ID": 4211, "COMMENT": "do you have anything friday?" } }

Jak limit żądań wpływa na przepływ?

Bitrix24 mierzy wywołania REST metodą cieknącego wiadra. Każde żądanie zwiększa licznik, licznik opada ze stałą szybkością co sekundę, a gdy przekroczy próg, kolejne żądanie dostaje odpowiedź 503 z QUERY_LIMIT_EXCEEDED. W planach Enterprise licznik opada o 5 na sekundę przy progu 250, w pozostałych planach o 2 przy progu 50.

Każda przychodząca wiadomość kosztuje dwa lub trzy wywołania, więc stały, niewielki strumień nigdy nie zbliża się do limitu. Nagły wzrost już tak: pięćdziesięciu klientów odpowiadających na ten sam szablon w ciągu minuty to nawet 150 wywołań. Ustaw w węzłach HTTP Request ponawianie po błędzie z krótkim czasem oczekiwania i uruchamiaj wykonania przepływu po jednym, aby nagły wzrost spłynął do Bitrix24, zamiast się od niego odbijać.

Czy odpowiedzi pisane na telefonie trafiają do Bitrix24?

Mogą. Na numerze Coexistence aplikacja WhatsApp Business nadal działa, a gdy ktoś odpowiada z niej, Meta wysyła echo wychodzącej wiadomości na ten sam adres docelowy webhooka, w polu smb_message_echoes.

Druga gałąź przepływu obsługuje te echa tak samo jak wiadomości przychodzące, a komentarz jest oznaczony jako wychodzący. Rekord pokazuje wtedy całą rozmowę, z wypowiedziami klienta i odpowiedziami sklepu w kolejności.

Odpowiedzi, które przepływ wysyła sam przez Cloud API, są w jego rękach już w chwili wysłania, więc zapisuj je wtedy, zamiast czekać na powrót webhooka.

Typowe błędy

• Wklejanie adresu URL przychodzącego webhooka do kodu po stronie klienta lub we wspólnym dokumencie. Zawarty w nim sekret daje wszystkie zakresy uprawnień nadane webhookowi.
• Tworzenie webhooka z konta użytkownika, który nie widzi wszystkich leadów. Wyszukiwanie pomija wtedy rekordy, a przepływ tworzy duplikaty.
• Wysyłanie serii wywołań bez ponawiania. Bitrix24 odpowiada 503 QUERY_LIMIT_EXCEEDED, a te wiadomości nigdy nie trafiają na oś czasu.

Najczęściej zadawane pytania

Czytaj dalej