Odpowiadaj na wiadomości WhatsApp za pomocą chatflow we Flowise

Dlaczego Flowise potrzebuje czegoś przed sobą?

Ponieważ webhook Meta i API Flowise używają różnych formatów. Meta weryfikuje adres docelowy żądaniem GET, które musi zwrócić hub.challenge jako surową treść odpowiedzi, a następnie dostarcza każdą wiadomość jako zagnieżdżony JSON w żądaniu POST. Prediction API Flowise oczekuje żądania POST na /api/v1/prediction/ z identyfikatorem przepływu na końcu oraz polem question. Żadna ze stron nie dostosuje się do drugiej, więc tłumaczy odbiornik.

Odbiornikiem może być węzeł Webhook w n8n, trasa w Pythonie lub Node albo dowolna funkcja serverless. Odpowiada na weryfikacyjne żądanie GET, sprawdza długi losowy sekret umieszczony w adresie URL webhooka, od razu odsyła Meta odpowiedź 200, a dopiero potem wykonuje pracę. Sekret w adresie URL to uwierzytelnianie, które tu działa: Meta podpisuje dostawy sekretem aplikacji Tech Provider, który nigdy nie jest udostępniany, więc po Twojej stronie nie da się zweryfikować nagłówka X-Hub-Signature-256.

Jak odbiornik powinien wywoływać Prediction API?

Z tekstem klienta jako question i numerem WhatsApp klienta jako sesją. Flowise przyjmuje overrideConfig w każdym żądaniu, a sessionId w nim sprawia, że węzły pamięci prowadzą jedną rozmowę na osobę, zamiast mieszać wszystkich w jednym wątku. Numer nadawcy z payloadu webhooka to do tego stabilny, naturalny klucz.

Jeśli chatflow jest chroniony kluczem API, odbiornik wysyła go jako token typu bearer. Ustaw streaming na false, chyba że odbiornik potrafi złożyć strumień, ponieważ WhatsApp dostarcza jedną gotową wiadomość, a nie token po tokenie.

Odpowiedź wychodzi jako wiadomość tekstowa Cloud API z tego samego numeru. Jest to bezpłatne i dozwolone w 24-godzinnym oknie otwartym przez wiadomość klienta. Wszystko, co przepływ chce wysłać później, na przykład przypomnienie, musi być zatwierdzonym szablonem.

POST https://your-flowise-host/api/v1/prediction/<flow-id>
Authorization: Bearer <flowise-api-key>
Content-Type: application/json

{
  "question": "do you have anything friday?",
  "streaming": false,
  "overrideConfig": { "sessionId": "14155550188" }
}

Czy agent Flowise może korzystać z serwera MCP EasyCoexistence?

Obecnie nie. Custom MCP we Flowise łączy się z serwerem Streamable HTTP za pomocą adresu URL i zestawu nagłówków, zwykle statycznego tokenu typu bearer przechowywanego w zmiennej Flowise. Serwer MCP EasyCoexistence uwierzytelnia przez OAuth, z logowaniem w przeglądarce i tokenami, które sam wydaje, więc nie ma statycznego klucza, który można wstawić do nagłówka.

Działający podział polega na tym, że przepływ decyduje, a odbiornik wysyła. Przepływ zwraca tekst do wysłania albo nazwę szablonu, gdy klient milczy od ponad doby, a odbiornik wykonuje wywołanie Cloud API z tokenem numeru. Dzięki temu token nigdy nie trafia do Flowise, a reguła 24 godzin jest egzekwowana w kodzie przez sprawdzenie, kiedy kontakt ostatnio pisał, zamiast polegać na modelu, który może o niej zapomnieć.

Wiadomości przychodzące nadal docierają wyłącznie przez webhook, niezależnie od sposobu wysyłania.

Typowe błędy

• Pominięcie sessionId. Wtedy wszyscy klienci dzielą jedną pamięć, a dane jednej osoby mogą pojawić się w odpowiedzi dla innej.
• Czekanie na Flowise przed odpowiedzią dla Meta. Wolna odpowiedź 200 jest ponawiana, więc ta sama wiadomość zostaje przetworzona dwa razy.
• Pozwolenie, by przepływ wysłał dowolny tekst dobę później. Poza oknem Meta odrzuca go z błędem 131047.

Najczęściej zadawane pytania

Czytaj dalej