Wysyłanie i odbieranie wiadomości WhatsApp z Node.js
Odbieranie to trasa, która odpowiada na weryfikacyjny GET od Meta i przyjmuje żądania POST. Wysyłanie to wywołanie fetch do Cloud API z identyfikatorem numeru telefonu i tokenem. Nie ma naszego SDK ani niczego do zainstalowania.
GET do weryfikacji Meta i POST dla zdarzeń.
Okno po wiadomości klienta, w którym można wysyłać dowolny tekst.
Błąd zwracany przy wysyłaniu dowolnego tekstu poza tym oknem.
Jak odbierać wiadomości w Node?
Jedna trasa z dwiema metodami, w Express, Fastify, handlerze trasy Next albo zwykłym serwerze.
GET odpowiada na weryfikację Meta: odczytaj hub.mode, hub.verify_token i hub.challenge z parametrów zapytania, porównaj token ze swoim i zwróć challenge jako zwykły tekst. Zwracanie go jako JSON to typowy błąd. Powstaje endpoint, który nigdy niczego nie odbiera, choć wygląda poprawnie.
POST odbiera zdarzenia. Odpowiedz natychmiast kodem 200, a potem je przetwórz. Meta ponawia powolne żądania, a handler, który najpierw wykonuje pracę, zobaczy tę samą wiadomość więcej niż raz. Szczególnie w środowisku serverless zwrócenie odpowiedzi przed dodaniem pracy do kolejki zapobiega zamianie zimnego startu w duplikat.
Jak wysyłać?
Wywołanie fetch do endpointu messages w Cloud API dla identyfikatora numeru telefonu, z tokenem w nagłówku bearer.
Nic w tym rozwiązaniu nie jest specyficzne dla nas, więc żądanie dokładnie odpowiada własnej dokumentacji Meta i nie ma żadnej nakładki, której trzeba się uczyć ani z którą trzeba się wiązać. Obie wartości znajdziesz w panelu, a get_api_credentials zwraca je przez konektor MCP, jeśli asystent konfiguruje połączenie.
Treść zależy od czasu. W ciągu 24 godzin od ostatniej przychodzącej wiadomości klienta wyślij obiekt tekstowy. Po tym czasie wyślij obiekt szablonu z zatwierdzoną nazwą szablonu i językiem. Kod, który wysyła wyłącznie tekst, przechodzi każdy test i zawodzi przy pierwszej wiadomości, która nadejdzie w nocy.
Co zmienia się w środowisku serverless?
Dwie rzeczy i obie dotyczą końca funkcji, zanim zakończy się praca.
Zwrócenie 200 i dalsze przetwarzanie nie działa, gdy funkcja zatrzymuje się natychmiast po odpowiedzi. Użyj mechanizmu dostępnego na Twojej platformie, który podtrzymuje pracę po odpowiedzi, albo dodaj payload do kolejki i pozwól osobnej funkcji go obsłużyć. Meta potrzebuje szybkiego potwierdzenia, a nie zakończonej pracy.
Zimne starty zwiększają też ryzyko powolnych odpowiedzi, co oznacza więcej ponowień i duplikatów. Usuwanie duplikatów na podstawie identyfikatora wiadomości wamid nie jest opcjonalne w takim układzie. To ono zapewnia niezawodność.
Typowe błędy
- Zwracanie challenge jako JSON zamiast surowej treści odpowiedzi.
- Wykonywanie pracy przed odpowiedzią 200. W środowisku serverless funkcja może zatrzymać się natychmiast po odpowiedzi.
- Pomijanie usuwania duplikatów. Meta celowo ponawia żądania, a duplikaty są normalne, nie wyjątkowe.
Połącz numer na easycoexistence.com, ustaw adres webhooka na swoją trasę i odczytaj identyfikator numeru telefonu oraz token z panelu. Od US$ 9 za numer miesięcznie, przy większej liczbie numerów cena spada do US$ 2, a pierwsze 7 dni jest bezpłatne.
Najczęściej zadawane pytania
Czy potrzebuję biblioteki?
Nie. Wystarczy trasa i fetch, a wywołanie dokładnie odpowiada dokumentacji Meta.
Czy to działa na Vercel lub Lambda?
Tak, z typowym zastrzeżeniem dla środowiska serverless: najpierw potwierdź odbiór, a potem przetwórz dane przez kolejkę lub mechanizm działający w tle, zamiast robić to bezpośrednio.
Jak sprawdzić, czy żądanie pochodzi od Meta?
Sprawdź nagłówek podpisu względem sekretu aplikacji. Warto zrobić to, gdy tylko endpoint stanie się publiczny.
Czy mogę używać TypeScript?
Tak. Nie ma niczego, co trzeba typować po naszej stronie, ponieważ payload należy do Meta i jest przez Meta udokumentowany.
Czytaj dalej
Gotowy, aby zacząć?
Skonfiguruj WhatsApp Coexistence w kilka minut, nie miesięcy. Aplikacja nadal działa na telefonie.
Rozpocznij bezpłatny okres próbnyZweryfikowano w