--- title: "WhatsApp Business и n8n: как подключить сообщения — Nodbot" source_url: "https://nodbot.ru/integrations/whatsapp-twilio/" canonical_url: "https://nodbot.ru/integrations/whatsapp-twilio/" language: "ru" content_type: "IntegrationGuide" section: "integrations" generated_at: "2026-05-30" word_count_source: 1242 --- # WhatsApp Business и n8n: как подключить сообщения, шаблоны, CRM и AI-support через Cloud API или Twilio без дублей и нарушений правил ## AI summary Глубокий гайд по WhatsApp Business в n8n через Cloud API или Twilio: webhooks, templates, CRM, media, AI-support, opt-in, idempotency, безопасность и тесты. ## Best used for Страница объясняет «WhatsApp Business и n8n: как подключить сообщения — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Короткий ответ - Как выбрать путь: Cloud API, Twilio или провайдер - Что умеют WhatsApp/Twilio nodes в n8n - Архитектура диалога - Templates, opt-in и окно поддержки - AI-support в WhatsApp - Media, attachments и документы - Idempotency, retries и провайдерские webhooks ## Source outline # WhatsApp Business и n8n: как подключить сообщения, шаблоны, CRM и AI-support через Cloud API или Twilio без дублей и нарушений правил Обновлено: 2026-05-29 ## Короткий ответ WhatsApp в n8n можно строить через WhatsApp Business Cloud node/Trigger, через Twilio node или через HTTP Request к провайдеру. Production-сценарий должен учитывать opt-in, шаблонные сообщения, 24-hour customer care window, media, idempotency, CRM mapping, human handoff и запрет на бесконтрольные AI-ответы. Главная цель — не просто отправить сообщение, а безопасно вести диалог: понять клиента, сохранить контекст, обновить CRM и не нарушить политику канала. ## Как выбрать путь: Cloud API, Twilio или провайдер Есть три практических пути. Первый — WhatsApp Business Cloud node/Trigger в n8n, если вам подходит прямой сценарий с Meta WhatsApp Business. Второй — Twilio node, если ваша коммуникация уже идёт через Twilio и вы хотите единый слой для SMS/WhatsApp. Третий — HTTP Request к стороннему провайдеру, если у вас локальная специфика, готовые шаблоны и договорённости с BSP. Выбор зависит от владения номером, шаблонов, верификации, стоимости, поддержки media, compliance, webhooks и того, где уже живёт CRM. В статье важно не смешивать эти пути: Twilio WhatsApp и Meta Cloud API имеют разные credentials, webhooks, ошибки и ограничения. n8n может быть orchestration layer в обоих случаях. ## Что умеют WhatsApp/Twilio nodes в n8n n8n документирует WhatsApp Business Cloud node для отправки сообщений и работы с media, а WhatsApp Trigger — для событий account, message и phone number. Twilio node поддерживает отправку SMS/MMS и WhatsApp messages, а Twilio Trigger умеет реагировать на события вроде новых SMS и calls. Поэтому страницу нужно строить не только вокруг “send message”, но и вокруг inbound/outbound lifecycle. Production-процесс обычно такой: входящее сообщение → нормализация → определение клиента → CRM/ticket update → AI или rule-based ответ → шаблон/свободное сообщение → лог → handoff. Для исходящих уведомлений важно понимать, можно ли отправить свободный текст или нужен approved template. Если workflow ошибётся, сообщение может не уйти или аккаунт получит проблемы с качеством. ## Архитектура диалога Схема: WhatsApp webhook/trigger → Verify payload → Normalize contact → Load conversation state → Classify intent → Decide automation/human → Send response/template → Update CRM → Save audit. Нормализованный объект: wa_message_id , phone , contact_id , direction , message_type , text , media_id , timestamp , conversation_id , source_provider , correlation_id . Состояние диалога храните отдельно: crm_contact_id , last_inbound_at , assigned_agent , open_ticket_id , language , consent_status , last_template_name , handoff_status , blocked . Нельзя строить WhatsApp-support только на executions n8n: история нужна для handoff, повторной доставки, отчётов и восстановления после сбоя. ## Templates, opt-in и окно поддержки WhatsApp Business требует аккуратного отношения к шаблонным и пользовательским сообщениям. Если пользователь написал первым, у вас есть окно для обычного customer care ответа. Если вы инициируете диалог или окно закрыто, часто нужен approved template. Поэтому n8n workflow должен знать: кто инициатор, когда был последний inbound, какой template разрешён, какие переменные передаются и есть ли согласие. В данных template не передавайте лишнюю персональную информацию. Перед отправкой проверяйте, что все placeholders заполнены, язык соответствует пользователю, template_name существует у провайдера, а fallback описан. Если template failed, не пытайтесь бесконечно отправлять его заново. Создайте task менеджеру или отправьте альтернативный канал, если он разрешён. ## AI-support в WhatsApp AI может классифицировать намерение, предложить ответ, найти статью в базе знаний, собрать данные лида, перевести диалог менеджеру и сделать summary. Но WhatsApp — личный канал, поэтому ошибки воспринимаются болезненнее, чем в внутреннем чате. Для AI-ответов нужен policy layer: запрещённые темы, PII, финансовые обещания, юридические советы, скидки, angry customer, low confidence, request for human. Пример JSON output: ``` { "intent": "pricing_question", "reply_type": "draft", "safe_reply": "Можем подсказать стоимость после уточнения CRM и каналов. Напишите, какая система используется сейчас.", "requires_human": false, "lead_score": 58, "risk_flags": [] } ``` Для high-risk сообщений AI готовит draft и summary, а отправляет человек. Для low-risk FAQ можно автоответить, если источник ответа найден в базе знаний. ## Media, attachments и документы WhatsApp часто содержит голосовые, изображения, документы и скриншоты. n8n workflow должен различать message_type. Для media: скачать файл, проверить тип/размер, сохранить в S3/Drive, привязать к CRM/ticket, не отправлять в LLM без необходимости. Для голосовых можно добавить transcription, но обязательно пометить confidence и оригинал. Не храните sensitive media в публичных ссылках. Если менеджер должен посмотреть файл, используйте защищённое storage и срок жизни ссылки. В audit log храните media_id, storage_key, hash, size, content_type, но не обязательно сам файл. ## Idempotency, retries и провайдерские webhooks Провайдеры могут доставлять webhooks повторно. Используйте wa_message_id /provider event id как dedupe key. Входящее сообщение должно обрабатываться один раз, а повторное событие только обновляет status. Для исходящих сообщений храните provider message id, status, template, phone, correlation_id. Если API вернул retryable error, повторяйте с тем же business key, чтобы не отправить два одинаковых уведомления. Статусы delivered/read/failed не должны создавать новые CRM events как отдельные лиды. Это updates к тому же conversation. Для массовых рассылок добавьте rate limiting, quiet hours, consent check и unsubscribe/stop handling. ## Тестирование и rollout Тест-кейсы: новый inbound, повторный webhook, template send, closed customer window, missing placeholder, media message, blocked user, invalid phone, Twilio/Meta API error, AI low confidence, human handoff, manager reply, CRM недоступна, retry, unsubscribe. Rollout: сначала sandbox/test number, затем внутренние пользователи, затем одна категория диалогов, потом полный канал. Метрики: first response time, automation rate, handoff rate, AI correction rate, template failure rate, duplicate messages, blocked users, opt-out rate, CRM match rate, unresolved conversations, cost per conversation. Если растёт количество handoff или жалоб, не расширяйте автоматизацию — сначала улучшите knowledge base и policy layer. ## FAQ ### Что выбрать: WhatsApp Cloud API или Twilio? Cloud API лучше для прямого сценария Meta WhatsApp Business, Twilio удобен, если SMS/WhatsApp/calls уже централизованы в Twilio. n8n может оркестрировать оба пути. ### Можно ли отвечать AI автоматически? Да для низкорисковых FAQ и понятных сценариев. Для денег, жалоб, юридических тем, персональных данных и low confidence нужен human review. ### Как избежать дублей? Используйте provider message id/event id для входящих webhook и business idempotency key для исходящих сообщений. Сохраняйте conversation state вне executions. ### Что делать с шаблонами? Храните allowlist шаблонов, проверяйте placeholders, язык, consent и customer care window. При ошибке создавайте task, а не делайте бесконечные retry. ### Нужно ли хранить историю диалога? Да. Храните conversation state, CRM contact, ticket, last inbound, status и audit. Но чувствительные данные и media храните с минимизацией и контролем доступа. ## Практический контракт интеграции Интеграция «WhatsApp Business и n8n» должна начинаться с контракта данных: кто источник, какой внешний ID считается главным, какие поля можно перезаписывать и что делать при повторной доставке. Без этого n8n быстро превращается в слой случайного mapping между сервисами. Минимально опишите лид, сделка, контакт или задача из CRM с external_id и ответственным. Главный риск — получить уверенный, но непроверенный ответ модели, сломанный JSON или дорогой цикл retry. - Слой | Что зафиксировать | Зачем - Вход | лид, сделка, контакт или задача из CRM с external_id и ответственным | позволяет повторить проблему без доступа к production-секретам - Контроль | validation_error_rate, token_cost, fallback_usage, human_review_rate, source_coverage | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | получить уверенный, но непроверенный ответ модели, сломанный JSON или дорогой цикл retry | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «WhatsApp Business и n8n» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` { "request_id": "req_demo_001", "prompt_version": "2026-05-29", "input": "краткое нормализованное сообщение пользователя", "allowed_actions": ["read", "draft", "classify"], "forbidden_actions": ["send_without_review", "change_payment"], "expected_output": { "intent": "technical|support|sales|unknown", "confidence": 0.0, "needs_human_review": true, "sources": [] } } ``` ### Критерий готовности - описан основной external_id и политика upsert/dedupe - credentials имеют минимально нужные права и понятного владельца - известно, какие поля можно менять автоматически, а какие только после review - есть обработка 401/403, 429, 5xx и изменения схемы payload ## Related Nodbot pages - [Основы](/basics/) - [Ноды](/nodes/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) - [Сравнения](/compare/) - [Блог](/blog/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.