Входящий вебхук: отправка сообщений в WhatsApp и MAX

Входящий вебхук позволяет запускать автоматизацию по событию из календаря бронирований, CRM, формы или другого сервиса. Сервис отправляет данные на уникальную ссылку avChat, а правило проверяет условия и пишет клиенту через выбранный аккаунт WhatsApp или MAX.

Например, после подтверждения бронирования можно отправить гостю даты заезда и выезда. Телефон и данные для сообщения avChat берёт из JSON вебхука. Предварительная связь с диалогом Авито для такой отправки не нужна.

Общие принципы работы правил описаны в статье «Автоматизация по событиям».

Что подготовить

• Подключите в avChat аккаунт WhatsApp или MAX, через который будете писать клиентам. Аккаунт должен быть активен, а канал — доступен на вашем тарифе.

• Получите пример JSON, который внешний сервис отправляет при нужном событии. Для обычной отправки в нём должен быть телефон клиента. Сейчас поддерживаются российские мобильные номера. В тестовом сопоставлении RealtyCalendar телефон может отсутствовать.

• Убедитесь, что внешний сервис умеет отправлять вебхуки методом POST с телом JSON. Если настройкой сервиса занимается интегратор, передайте ему ссылку из avChat и требования в конце статьи.

1. Создайте подключение вебхука

1. Откройте «Автоматизация по событиям» и создайте правило.

2. В блоке события выберите «Входящий вебхук».

3. В поле «Подключение вебхука» выберите «Новое подключение».

4. Укажите название, например «Календарь — подтверждение брони».

5. Заполните «Путь к телефону в JSON». Это расположение телефона внутри данных сервиса, например data.booking.client.phone.

6. Оставьте включённым «Принимать вебхуки» и нажмите «Создать подключение».

7. Нажмите «Копировать URL» и вставьте полученный адрес в настройки вебхуков внешнего сервиса.

Сохранение подключения и сохранение правила — разные действия. Кнопка «Сохранить подключение» сохраняет название, путь к телефону и настройки приёма. Условия и действия нужно сохранить кнопкой сохранения самой автоматизации, а затем включить правило.

Ссылка даёт возможность запускать ваши правила. Передавайте её только тому сервису, который должен присылать события. Кнопка «Заменить ссылку» сразу отключает старый URL: после замены обновите адрес во всех внешних сервисах, где он использовался.

2. Укажите путь к телефону

Путь записывается через точки: от внешнего поля к вложенному. Для первого элемента массива используйте индекс 0, например guests.0.phone. В поле пути не нужны фигурные скобки, префикс webhook. или знак $.

Ниже учебный пример. Названия полей и события условные: это не готовый формат RealtyCalendar или другого сервиса. Используйте структуру из своего фактического вебхука. Телефон в примере вымышленный.

{
  "event_id": "evt-demo-001",
  "event": "booking_confirmed",
  "data": {
    "booking": {
      "id": "DEMO-123",
      "status": "confirmed",
      "check_in": "2026-11-20",
      "check_out": "2026-11-23",
      "client": {
        "name": "Анна",
        "phone": "+7 (999) 000-00-00"
      }
    }
  }
}

Для этого примера путь к телефону — data.booking.client.phone. Если телефон находится прямо в корне JSON, например {"phone":"+79990000000"}, достаточно указать phone.

Пробелы, скобки и дефисы в номере допустимы. avChat приводит российский мобильный номер к единому формату. Если поле отсутствует, пустое или номер не подходит, событие не запускает автоматизацию.

3. Настройте условия по JSON

В блоке «Условия по JSON для этого правила» нажмите «Добавить условие». Укажите путь поля, проверку и значение.

Для учебного примера выше добавьте:

Все условия должны выполниться одновременно. Без условий правило подходит для всех принятых событий выбранного подключения. Можно добавить до 30 условий.

• Равно / Не равно — сравнение значения. Строки учитывают регистр: confirmed и Confirmed отличаются.

• Содержит / Не содержит — поиск фрагмента строки с учётом регистра.

• Больше / Не меньше / Меньше / Не больше — сравнение чисел.

• Поле существует / Поля нет — проверка наличия поля без ввода значения. Существующее поле со значением null считается существующим; это не проверка заполненности.

Для логических значений указывайте true или false. Если поля нет, сравнения, включая «Не равно» и «Не содержит», не выполняются. Для отсутствующего поля используйте проверку «Поля нет».

Проверка статуса не отслеживает его изменение. Условие «status равно confirmed» проверяет каждый полученный вебхук. Если сервис присылает обновление других данных с тем же статусом, правило тоже может сработать. Для отправки именно при подтверждении выберите соответствующее событие у отправителя или проверяйте поле, которое явно сообщает о подтверждении либо смене статуса.

4. Добавьте сообщение клиенту

1. Добавьте действие «Написать в мессенджер».

2. В поле «Мессенджер» выберите WhatsApp или MAX аккаунт.

3. Обязательно выберите конкретный «Аккаунт мессенджера», через который нужно отправлять сообщение.

4. Заполните «Текст сообщения». Для подстановки данных используйте {{webhook.путь.к.полю}}.

Пример текста для нашего JSON:

Здравствуйте, {{webhook.data.booking.client.name}}!
Бронирование № {{webhook.data.booking.id}} подтверждено.
Заезд: {{webhook.data.booking.check_in}}.
Выезд: {{webhook.data.booking.check_out}}.
Будем рады вас видеть!

Получится:

Здравствуйте, Анна!
Бронирование № DEMO-123 подтверждено.
Заезд: 2026-11-20.
Выезд: 2026-11-23.
Будем рады вас видеть!

Значения подставляются в том виде, в котором их прислал сервис: даты автоматически не переформатируются. Используйте путь к конкретному значению, а не ко всему объекту. Если указанного поля webhook.… в событии нет, отправка этого текста завершится ошибкой. Для разных форматов событий настройте отдельные правила и шаблоны.

Чтобы отправить в WhatsApp и MAX, добавьте два действия. В каждом выберите свой мессенджер, аккаунт и текст. Это две отдельные отправки: клиент, доступный в обоих каналах, может получить оба сообщения.

Если аккаунтов несколько, выбор в действии определяет отправителя. Например, для разных объектов можно создать отдельные правила, отфильтровать их по ID объекта в JSON и выбрать соответствующие аккаунты.

avChat проверяет доступность получателя по телефону через выбранный аккаунт. Если контакт не найден или отправка недоступна, сообщение через этот аккаунт не отправляется. В обычном режиме связь с диалогом Авито не требуется. Для проверки сопоставления брони с диалогом предусмотрена отдельная тестовая настройка, описанная ниже.

5. Проверьте настройку без отправки

1. В блок «Проверка JSON без отправки сообщений» вставьте пример данных внешнего сервиса. Если вебхук уже поступал, нажмите «Обновить полученные данные», чтобы загрузить последний пример.

2. В поле «Текст для предпросмотра» вставьте тот же шаблон, который планируете использовать в действии.

3. Нажмите «Проверить телефон, условия и текст».

4. Убедитесь, что телефон найден, условия выполнены, а в сообщении стоят нужные значения.

В списке «Переменные из JSON» можно нажать на переменную, чтобы скопировать её, или выбрать «Использовать как телефон». После изменения пути сохраните подключение.

Предпросмотр не отправляет сообщения, не проверяет доступность клиента в мессенджере и не переносит текст автоматически в действие. Скопируйте готовый шаблон в «Текст сообщения», сохраните автоматизацию и включите правило.

Для проверки реальной доставки используйте отдельное тестовое событие и свой номер. В обычном режиме POST на URL подключения при включённом правиле запускает настоящие действия. При включённом тестовом сопоставлении RealtyCalendar действия не запускаются.

Тестовое сопоставление брони RealtyCalendar с диалогом Авито

Это дополнительная настройка конкретного подключения входящего вебхука. Без неё вебхук остаётся универсальным: его можно использовать с CRM, формами и другими сервисами по инструкции выше.

Тест ищет диалог среди выбранных аккаунтов Авито по имени гостя и времени системного сообщения «У вас новая бронь». Привязывать объекты календаря к объявлениям не нужно. Ссылки из переписки не анализируются, запросы к API бронирований Авито не выполняются: используются сообщения, уже сохранённые в avChat.

В тестовом режиме никакие действия автоматизаций на этой ссылке не запускаются. Сообщения не отправляются ни в Авито, ни в WhatsApp, ни в MAX — даже если диалог найден или в вебхуке уже есть телефон. Режим нужен для проверки качества сопоставления.

Как включить тест

1. Откройте «Автоматизация по событиям», создайте или откройте правило и выберите событие «Входящий вебхук».

2. В поле «Подключение вебхука» выберите «Новое подключение». Для теста лучше создать отдельную ссылку, например «RealtyCalendar — тест сопоставления», чтобы не останавливать действующие автоматизации.

3. В поле «Путь к телефону в JSON» укажите data.booking.client.phone. Сам телефон в тестовых событиях может отсутствовать или иметь значение null.

4. Включите «Тест сопоставления брони RealtyCalendar — без отправки».

5. В поле «Аккаунты Авито для поиска» выберите один или несколько подключённых аккаунтов, в которых могут находиться диалоги гостей. Искать по всем аккаунтам автоматически система не будет.

6. Задайте «Допустимая разница времени, минут (1–60)». По умолчанию — 15 минут. Сравнивается время создания брони в календаре и время системного сообщения о новой брони, а не время последней переписки. Учитываются часовые пояса; сообщение может быть раньше или позже создания брони в пределах выбранного интервала.

7. Оставьте включённым «Принимать вебхуки» и нажмите «Создать подключение» или «Сохранить подключение». Затем сохраните правило, чтобы сохранить выбранное подключение; само правило для теста можно оставить выключенным.

8. Нажмите «Копировать URL» и настройте в RealtyCalendar отправку событий создания и обновления брони на эту ссылку методом POST с телом JSON.

Настройка теста общая для подключения. Если одну ссылку используют несколько правил, тестовый режим отключает запуск действий для всех этих правил. Для подбора диалога не нужно добавлять условия по JSON: они относятся к обычным автоматизациям, а тест отдельно проверяет имя и время.

Используйте фактический вебхук RealtyCalendar. Для теста нужны data.booking.id, agency_id, created_at и updated_at с часовым поясом, а для поиска — source: "Avito" и client.fio внутри data.booking. Учебный JSON из раздела об универсальном вебхуке выше для этого режима не подходит. Путь к уникальному ID события в тестовом режиме не используется.

Где смотреть результаты

Снова откройте правило с событием «Входящий вебхук» и выберите сохранённое тестовое подключение. Под настройками подключения появится блок «Результаты тестового сопоставления».

Нажмите «Обновить результаты». Для каждой брони показаны:

• номер брони и имя гостя;

• результат сопоставления и наличие телефона: «есть» или «пока нет»;

• время создания и обновления брони в календаре, последнее событие;

• ссылка «Открыть сохранённый диалог», если связь установлена;

• кандидаты с номерами диалогов, объявлениями и разницей времени.

Разница со знаком «+» означает, что бронь появилась в календаре позже системного сообщения Авито. Например, «+4 мин 57 сек» — сообщение пришло почти на пять минут раньше. Результаты показывают последнее сохранённое состояние каждой брони; при большом количестве записей доступны кнопки «Назад» и «Далее».

Имя сравнивается без учёта регистра, лишних пробелов и различий «е/ё». Разные варианты имени, например «Лера» и «Валерия», автоматически одинаковыми не считаются.

Повторная проверка и появление телефона

Если сообщение Авито поступило позже вебхука или вы изменили параметры поиска, сохраните подключение и нажмите у нужной брони «Повторить проверку без отправки». Проверка не отправляет сообщения. Уже установленная связь сохраняется: повторная проверка не выбирает для неё другой диалог.

Следующий вебхук той же брони обновляет запись по подключению, агентству и ID брони. Когда календарь пришлёт телефон по настроенному пути, отметка сменится на «Телефон: есть». Новая запись и новая связь для этого не создаются. Даже после появления телефона отправка остаётся отключённой.

Для разовой проверки примера используйте блок «Проверка JSON без отправки сообщений» и кнопку «Проверить телефон, условия и текст». Поиск использует сохранённые аккаунты и интервал. Такой предпросмотр показывает кандидата, но не сохраняет бронь и связь в списке результатов — для сохранения нужен вебхук на URL подключения.

Отключение теста не включает отправку по найденным связям. Оно возвращает обычную обработку входящего вебхука, при которой включённые правила могут отправлять сообщения по телефону. Не отключайте тест как способ проверки доставки: сначала отдельно настройте и проверьте правила обычного режима.

Повторные вебхуки и ID события

Следующие правила защиты от повторов относятся к обычному режиму вебхука. Внешний сервис может повторить доставку одного события. avChat пропускает его повторы в течение 48 часов в рамках одного подключения.

• Если сервис передаёт уникальный ID каждого события, укажите его путь в поле «Путь к уникальному ID события», например event_id. Повтор с тем же ID будет пропущен, даже если другие поля изменились.

• Если такого ID нет, оставьте поле пустым. avChat сравнивает весь JSON: перестановка ключей не делает событие новым, а изменение значения, например времени отправки, делает.

Не используйте номер брони как ID события. Подтверждение, изменение дат и отмена одной брони — разные события. Если у них один ID, последующие события могут быть пропущены. Если путь к ID заполнен, это поле должно присутствовать в каждом запросе и содержать непустое значение.

Защита от повторов не означает «одна отправка на бронь навсегда». Спустя 48 часов событие может быть принято снова. Событие также считается принятым, если ни одно правило не подошло по условиям: после исправления правила для теста используйте новое тестовое событие.

Одно подключение и несколько правил

Одну ссылку можно использовать для нескольких правил: например, подтверждение брони, изменение дат и отмена. В каждом правиле выберите одно и то же подключение, но задайте свои условия и действия. Если условия подходят сразу нескольким включённым правилам, могут выполниться все эти правила.

Название, путь к телефону, путь к ID события, ссылка и переключатель «Принимать вебхуки» общие для подключения. Их изменение влияет на все правила, которые его используют. Условия по JSON и действия задаются отдельно в каждом правиле.

Если сообщение не пришло

• «Вебхуков пока нет». Проверьте URL и настройки отправителя. Внешний сервис должен отправить POST с JSON именно на эту ссылку. После отправки нажмите «Обновить полученные данные».

• «Телефон не найден: проверьте путь». Откройте последний JSON и проверьте путь и сам номер. Если сервис не прислал телефон, avChat не сможет написать клиенту. Нужно получить новое событие с телефоном или повторить запрос после исправления данных.

• «ID события не найден: проверьте путь». Исправьте путь к ID или очистите его, если уникального ID в вебхуках сервиса нет.

• «Повтор — пропущен». Этот ID события или такой же JSON уже был принят за последние 48 часов.

• «Передан в автоматизации», но сообщения нет. Это означает приём события, а не доставку сообщения. Проверьте, что правило включено, выбрано нужное подключение, условия выполнены, аккаунт отправки активен, а клиент доступен в выбранном мессенджере. Проверьте также переменные текста и журнал выполнения автоматизации.

• После замены ссылки события перестали приходить. Обновите URL у отправителя. Старый адрес больше не работает.

Данные для настройки внешнего сервиса

• Адрес: точный URL из поля «URL входящего вебхука».

• Метод: POST.

• Формат тела: JSON-объект; заголовок Content-Type: application/json. Корневой массив не принимается.

• Размер: до 256 КБ; вложенность — до 32 уровней.

• Успешный ответ: HTTP 200. Повтор также получает HTTP 200, с признаком duplicate: true. Приём события не гарантирует отправку: далее проверяются правила и доступность мессенджера.

• Ошибки: 422 — некорректный JSON, отсутствующий или некорректный телефон либо ID события; 404 — ссылка не найдена или приём выключен; 413 — слишком большой запрос. При временном ответе 503 запрос можно повторить позже.