> ## Documentation Index > Fetch the complete documentation index at: https://docs.yume.cloud/llms.txt > Use this file to discover all available pages before exploring further. # Приём заявок с сайта и синхронизация Wazzup > Два внешних канала работы с лидами: неаутентифицированный приём заявок через публичный вебхук (источник, клиент по телефону, лид на стартовом этапе) и фоновая синхронизация сделок с Wazzup при сохранении и удалении лида. Полный перечень полей — в [глоссарии](/ru/logic/sales/lead-intake-glossary). ## Что это за раздел Здесь описаны два внешних канала работы с лидами, которые действуют «сами по себе», без участия менеджера в интерфейсе: 1. **Публичный адрес приёма заявок** — открытый (без входа в систему) адрес, на который сайт компании или сторонняя форма присылает заявку; система сама заводит клиента и ставит новый лид на первый рабочий этап нужной воронки. 2. **Фоновая синхронизация сделок с Wazzup** — при каждом сохранении или удалении лида система в фоне отражает соответствующую сделку в Wazzup. Оба механизма работают в контексте конкретной компании и опираются на её настройки и интеграции. ## Публичный адрес приёма заявок ### Адрес и доступ Приём заявок работает по отдельному адресу, который выдаётся для конкретной воронки. На него отправляется заявка с сайта. Этот адрес **не требует авторизации**: у него нет проверки прав и входа в систему. Любой, кто знает адрес и идентификатор воронки, может отправить заявку и создать лид. Это осознанное решение (чтобы формы на сайте могли слать заявки напрямую), но идентификатор воронки следует считать полусекретным. ### Пошаговый разбор обработки Когда приходит запрос, система выполняет шаги строго по порядку: 1. **Находит воронку** по идентификатору из адреса. Если воронки с таким идентификатором нет — ответ «не найдено», ничего не создаётся. 2. **Выбирает стартовый этап** — первый по ручному порядку **обычный** этап этой воронки, который не отключён. Системные этапы (успех, отказ) для приёма заявок не используются. Если ни одного подходящего обычного этапа нет — ответ «не найдено», ничего не создаётся. 3. **Проверяет тестовый вызов.** Если в теле запроса передан признак проверки (поле проверки со значением «test»), система сразу отвечает успехом с пустым телом и **не создаёт ни клиента, ни источник, ни лид**. Это нужно, чтобы можно было проверить работоспособность адреса, не засоряя воронку. 4. **Определяет источник привлечения.** Если в заявке передан идентификатор формы, система находит источник привлечения с таким названием или создаёт его, если его ещё нет. Если идентификатор формы не передан — у лида просто не будет источника. 5. **Находит или заводит клиента по телефону.** Система ищет клиента с телефоном из заявки. Если такого нет — создаёт нового клиента с именем и телефоном из заявки. 6. **Создаёт лид** на выбранном стартовом этапе воронки: с найденным/созданным клиентом, определённым источником и всеми данными заявки, сохранёнными в дополнительных данных лида. 7. Отвечает успехом с пустым телом. ### Как читаются поля заявки | Что берётся из заявки | Куда попадает | Значение по умолчанию, если поля нет | | ------------------------------------ | ----------------------------------------------- | ------------------------------------ | | Идентификатор формы | Название источника привлечения (поиск/создание) | Источник не назначается | | Телефон | Телефон клиента (поиск/создание) | Подставляется телефон-заглушка | | Имя | Имя нового клиента | «Новый клиент» | | Признак проверки со значением «test» | Ранний выход без создания записей | — | | Всё тело заявки целиком | Дополнительные данные лида | — | Если в заявке **нет телефона**, подставляется единый телефон-заглушка. Все такие «безтелефонные» заявки будут привязываться к **одному и тому же** клиенту-заглушке и накапливаться на нём. Для корректной атрибуции форма на сайте должна всегда передавать телефон. В дополнительные данные лида кладётся **всё тело заявки целиком**, плюс отдельно фиксируется значение куки (если оно было). Так внутри лида сохраняется исходный контекст обращения — все поля формы, идентификатор формы, метки и т. п. ### Идемпотентность и повторы Приём **не** пытается распознать повторную отправку той же заявки: при каждом POST создаётся **новый** лид, даже если клиент и телефон совпадают с уже существующим лидом. Совпадает лишь клиент (по телефону он находится, а не дублируется) и источник (по названию формы он переиспользуется, а не создаётся заново). Сами лиды каждый раз новые. ## Фоновая синхронизация сделок с Wazzup ### Когда запускается Синхронизация привязана к жизненному циклу лида и срабатывает автоматически: * **При каждом сохранении лида** (создание или изменение) — запускается обновление сделки в Wazzup. * **При удалении лида** — запускается удаление сделки в Wazzup. Оба действия выполняются **в фоновом потоке**: система не ждёт ответа Wazzup и не блокирует ни сохранение лида, ни ответ пользователю. В момент запуска фоновая задача «запоминает» текущую компанию и передаёт её внутрь, чтобы работать с нужными настройками интеграции. Синхронизация срабатывает при **любом** сохранении лида — не только при ручном редактировании в интерфейсе, но и при создании лида через публичный вебхук, а также при любых автоматических изменениях лида. ### Что делает обновление сделки 1. Берёт токен интеграции Wazzup для текущей компании. 2. Если токена нет (интеграция не подключена) — **тихо ничего не делает**. 3. Если токен есть — запрашивает у Wazzup сделку по идентификатору лида и затем создаёт (пересоздаёт) её с признаком «закрыта». Обновление всегда пересоздаёт сделку с признаком «закрыта». То есть любое сохранение лида, синхронизируемого с Wazzup, помечает соответствующую сделку в Wazzup как закрытую. Это важно понимать: механизм не переносит текущий этап лида в статус сделки Wazzup, а именно закрывает сделку. ### Что делает удаление сделки 1. Берёт токен интеграции Wazzup для текущей компании. 2. Если токена нет — **тихо ничего не делает**. 3. Если токен есть — просит Wazzup удалить сделку по идентификатору удалённого лида. ### Особенности фонового выполнения Фоновый поток — «запусти и забудь»: у него нет повторных попыток и нет видимой пользователю обработки ошибок. Если Wazzup недоступен, токен неверен или сделки в Wazzup не существует, сбой останется незамеченным в интерфейсе — лид при этом уже сохранён/удалён. Синхронизация с Wazzup является «мягкой»: её сбой никогда не мешает основной операции над лидом. ## Как это используется на практике * **Форма на сайте → лид.** Маркетинговая форма или лендинг отправляют заявку на публичный адрес вебхука конкретной воронки. Клиент автоматически появляется в базе (или переиспользуется по телефону), а новый лид встаёт на первый рабочий этап воронки — дальше по нему могут срабатывать триггеры этапа (уведомления, задачи, заявки и т. п.). * **Разные формы → разные источники.** Передавая в заявке разный идентификатор формы, можно автоматически размечать лиды по каналам привлечения — источник заводится один раз и переиспользуется. * **Зеркалирование сделок в Wazzup.** Пока подключена интеграция Wazzup, изменения и удаления лидов отражаются в сделках Wazzup в фоне, не замедляя работу менеджеров. ## Связанные страницы Полный перечень полей заявки и настроек интеграции, используемых этими двумя каналами. Обзорная страница модуля продаж со ссылками на все его разделы. Воронки продаж и их этапы: системные типы, автосоздание стартовых этапов и мягкое отключение. Лиды воронки: связь с клиентом, заявкой и продажей, ручное упорядочивание, фильтры и создание заявки. Задачи по лидам с дедлайном, назначением менеджера и уведомлением. Триггеры этапов и их исполнение при смене этапа лида: сообщения, задачи, заявки, вебхук. История смены этапов лида и массовые действия над лидами этапа: перенос, удаление, рассылка.