Połącz WhatsApp z n8n przez oficjalne Cloud API

Jak wiadomość WhatsApp trafia do workflow n8n?

Meta dostarcza każdą wiadomość wysłaną na numer do jednego wskazanego przez Ciebie adresu URL jako żądanie HTTP POST. Ten adres URL stanowi całą integrację. Umieść węzeł n8n Webhook pod produkcyjnym adresem URL, ustaw go jako miejsce docelowe webhooka numeru, a workflow uruchomi się przy każdej wiadomości przychodzącej.

Payload zawiera nadawcę, tekst lub odwołanie do multimediów, znacznik czasu i identyfikator wiadomości. Dalej jest to zwykły workflow n8n: rozgałęź go na podstawie treści, znajdź klienta, wywołaj pozostałe używane usługi i zdecyduj, czy odpowiedzieć.

Ponieważ to Coexistence, ta sama wiadomość jest też widoczna w aplikacji WhatsApp Business na telefonie. Człowiek może na nią odpowiedzieć. Workflow widzi odpowiedź człowieka, a człowiek widzi odpowiedź workflow, więc żadna ze stron nie odpowiada na drugą.

{
  "from": "14155550188",
  "id": "wamid.HBgLMTQxNTU1NTAxODgVAgAS",
  "timestamp": "1758412800",
  "type": "text",
  "text": { "body": "do you have anything friday?" }
}

Jak workflow wysyła odpowiedź?

Za pomocą węzła HTTP Request skierowanego do Cloud API, z użyciem phone number id i access token numeru. Oba elementy odczytasz z panelu albo przez łącznik MCP, jeśli wolisz, aby asystent je pobrał.

To, co należy wysłać, zależy od czasu, i właśnie tu wiele osób popełnia błąd. W ciągu 24 godzin od ostatniej wiadomości klienta działa dowolny tekst, a odpowiedź jest dokładnie taka, jaką utworzył workflow. Poza tym oknem przejdzie tylko szablon wcześniej zatwierdzony przez Meta. Workflow wysyłający wyłącznie dowolny tekst wygląda idealnie podczas testów, bo testy zawsze odbywają się kilka sekund po wiadomości, a potem milknie przy pierwszym prawdziwym przypadku nocnym.

Najbezpieczniejszy schemat to rozgałęzienie: sprawdź, ile czasu minęło od ostatniej wiadomości przychodzącej, i wybierz dowolny tekst albo szablon.

Czy n8n może również używać łącznika MCP?

Tak, i n8n jest pod tym względem nietypowy. Jego węzeł MCP Client Tool łączy się ze zdalnym serwerem MCP i obsługuje OAuth2, którego wymaga nasz serwer, więc węzeł AI Agent w workflow może bezpośrednio wywoływać nasze narzędzia.

Warto o tym wiedzieć, ponieważ większość platform automatyzacji nie potrafi tego zrobić. Make i Zapier uruchamiają własne serwery MCP i żaden z nich nie działa jako klient, więc żaden nie może połączyć się z serwerem zewnętrznym. n8n może.

To rozwiązanie sprawdza się po stronie wykonywania działań: węzeł agenta może zdecydować o wysłaniu wiadomości, sprawdzeniu stanu numeru albo odczytaniu statusu zatwierdzenia szablonu podczas działania workflow. Nie zastąpi jednak webhooka, ponieważ MCP nie ma sposobu na wybudzenie po nadejściu wiadomości.

Której z tych dwóch metod powinien użyć workflow?

Obu, ale do różnych zadań. To nie kwestia preferencji.

Webhook uruchamia cały proces. Klient pisze, Meta dostarcza wiadomość do węzła Webhook, a workflow się wykonuje. Żadne narzędzie nie oferuje odpowiednika MCP do tego celu, ponieważ ten protokół opiera się na żądaniu i odpowiedzi, a nie na wywołaniu z zewnątrz.

MCP Client Tool służy agentowi wewnątrz workflow do wykonywania działań bez wpisywania wywołania na sztywno. Jeśli workflow dokładnie wie, co wysłać, prostszy będzie węzeł HTTP Request skierowany do Cloud API, z mniejszą liczbą możliwych problemów. Jeśli decyzję podejmuje agent, łącznik udostępnia mu jedenaście narzędzi oraz reguły opisane przy każdym z nich, w tym okno 24 godzin.

Czym różni się to od używanych już w n8n węzłów WhatsApp?

Większość konfiguracji WhatsApp w n8n spotykanych w praktyce opiera się na nieoficjalnej bramie, która loguje się jako połączone urządzenie. Łatwo je uruchomić, ale narażają numer, ponieważ ten mechanizm narusza zasady WhatsApp, a Meta wykrywa wzorzec ruchu, nie konkretną bibliotekę.

Drugą częstą opcją jest oficjalne API bez Coexistence. Działa, ale migruje numer. Aplikacja WhatsApp Business przestaje na nim działać, więc zespół odpowiadający przez cały dzień musi przejść do nowego narzędzia. Dla większości małych firm to rozwiązanie odpada, dlatego tak wiele z nich trafiło wcześniej do nieoficjalnych bram.

Coexistence łączy elementy, których brakowało: oficjalne API i działający telefon.

Typowe błędy

• Używanie adresu Test URL n8n jako miejsca docelowego webhooka. Przestaje nasłuchiwać po zamknięciu edytora, więc wiadomości nie trafiają nigdzie.
• Brak odpowiedzi na żądanie weryfikacyjne Meta. Meta wysyła żądanie GET z challenge przed dostarczaniem czegokolwiek, a węzeł, który go nie zwróci, nigdy nie otrzyma wiadomości.
• Odpowiadanie dowolnym tekstem poza oknem 24 godzin. Z perspektywy workflow kończy się to po cichu, a przechodzi tylko zatwierdzony szablon.

Najczęściej zadawane pytania

Czytaj dalej