Odpowiadaj na wiadomości WhatsApp za pomocą aplikacji Dify

Czy Meta może wysyłać wiadomości WhatsApp prosto do Dify?

Nie w sposób, który kończy uzgadnianie. Zanim Meta cokolwiek dostarczy, wywołuje adres docelowy metodą GET i oczekuje wartości hub.challenge jako surowej treści odpowiedzi. Webhook Trigger w Dify przyjmuje jedną metodę HTTP na wyzwalacz, a jego dokumentacja podaje, że treść odpowiedzi inna niż JSON jest automatycznie konwertowana na JSON, więc zamiast OK wraca obiekt wiadomości. Challenge nigdy nie zostanie zwrócony dokładnie, a Meta nie zacznie dostarczać wiadomości.

Dlatego z przodu potrzebny jest mały element. Węzeł Webhook w n8n, trasa w Pythonie lub Node albo funkcja serverless odpowiada na GET, przyjmuje POST i przekazuje tekst do Dify. W odbiorniku sprawdzasz też długi losowy sekret w adresie URL webhooka, ponieważ nagłówek X-Hub-Signature-256 jest podpisany sekretem aplikacji Tech Provider i klient nie może go zweryfikować.

Jak odbiornik komunikuje się z aplikacją Dify?

Jednym wywołaniem Service API w Dify: POST /chat-messages, uwierzytelnionym kluczem API aplikacji. Treść żądania zawiera query, czyli tekst klienta, oraz user, czyli zdefiniowany przez Ciebie identyfikator. Jako user użyj numeru WhatsApp nadawcy i zachowaj conversation_id zwrócone przez Dify, aby kolejna wiadomość od tej samej osoby kontynuowała tę samą rozmowę.

Ważne jest response_mode. Tryb blocking zwraca wynik, gdy odpowiedź jest kompletna, a dokumentacja Dify ostrzega, że w Dify Cloud długie generowanie może zostać przerwane przez serwer proxy brzegowy. Aplikacje typu Agent obsługują tylko streaming, a żądanie blocking do takiej aplikacji kończy się błędem 400. Najpewniejszy jest odbiornik, który czyta strumień i na końcu wysyła jedną wiadomość WhatsApp.

Odpowiedź wychodzi następnie jako wiadomość tekstowa Cloud API na ten sam numer, bezpłatnie w 24-godzinnym oknie otwartym przez wiadomość klienta.

Co serwer MCP dodaje w Dify?

Możliwość, by agent Dify działał na numerze bez ręcznego podłączania każdego wywołania. Dify łączy się z serwerami MCP przez HTTP i domyślnie rejestruje się na serwerze przez dynamiczną rejestrację klienta OAuth, którą obsługuje serwer MCP EasyCoexistence. Dodaj go w sekcji Tools, zaloguj się raz, a agent dostanie narzędzia: lista numerów, sprawdzenie kondycji numeru, wysłanie wiadomości, wysłanie zatwierdzonego szablonu, odczyt statusu szablonu.

To właściwe miejsce na działania proaktywne: przepływ w Dify, który wraca do klienta następnego dnia, musi użyć send_template, bo dowolny tekst poza oknem zwraca błąd 131047, o czym informują model opisy narzędzi.

MCP nie potrafi natomiast obudzić Dify, gdy klient napisze. Protokół opiera się na żądaniu i odpowiedzi, więc wiadomości przychodzące nadal docierają przez webhook i odbiornik umieszczony z przodu.

Typowe błędy

• Użycie adresu URL Webhook Trigger z Dify jako miejsca docelowego webhooka. Challenge wraca opakowany w JSON, a Meta nigdy nie weryfikuje endpointu.
• Wysłanie żądania blocking do aplikacji Agent w Dify. Aplikacje Agent obsługują tylko streaming, a wywołanie kończy się błędem 400.
• Użycie nowej wartości user przy każdej wiadomości. Dify przypisuje rozmowy do user, więc każda wiadomość zaczyna nową rozmowę bez pamięci.

Najczęściej zadawane pytania

Czytaj dalej