-
Приём
Проверка и сохранение заявки
-
Очередь
Отдельная задача для каждого канала
-
Доставка
CRM и почта не блокируют друг друга
-
Контроль
Повторы и сверка результата
Надёжная интеграция сначала сохраняет заявку на сайте, а затем независимо доставляет её в Битрикс24 и на почту. Недоступность CRM не должна отменять письмо, а ошибка SMTP — создание сделки. Для каждого канала нужны свой статус доставки, повторы и журнал ошибок. Только после сохранения сайт подтверждает посетителю, что обращение принято.
Почему двух вызовов API недостаточно
Простой обработчик часто делает всё последовательно: получил форму, отправил письмо, создал сделку. Если второй шаг завершился исключением, третий не выполнится. Ещё опаснее тайм-аут после создания сделки: CRM успела сохранить данные, но сайт не получил ответ. Повтор всей операции может создать дубль.
Исправление начинается с локального идентификатора обращения. Он не меняется при повторе и связывает запись сайта, письмо и CRM. Сохраняйте данные и задания доставки в одной транзакции. Фоновый обработчик берёт подтверждённую запись, доставляет её и фиксирует результат отдельно для каждого канала. Так перезапуск приложения не обнуляет очередь.
Какие данные передавать
| Данные | Правило |
|---|---|
| Телефон | Строка в согласованном международном формате, не число |
| Проверка формата; отсутствие не заменять вымышленным адресом | |
| Сообщение | Ограничение длины, безопасный вывод в CRM и письме |
| Источник | URL страницы, вид формы, разрешённые UTM-параметры |
| ID обращения | Один и тот же при всех попытках доставки |
| Согласия | Факт, время и редакция документов по принятой схеме хранения |
Телефон нельзя пропускать через числовое поле таблицы или преобразование в floating point: ведущий плюс, формат и точность могут потеряться. Проверяйте номер на сервере, а не только маской браузера. Не восстанавливайте недостающую цифру догадкой. Ошибка должна вернуться пользователю до успешного принятия формы.
Контакт и сделка решают разные задачи. Повторное обращение существующего клиента может создавать новую сделку, но не обязательно новый контакт. Правила совпадения по телефону и email согласуйте с менеджерами. Два разных человека могут пользоваться общим корпоративным адресом — автоматическое объединение всех таких записей опасно.
Как организовать повторы без дублей
Для почты и CRM храните число попыток, время следующей попытки, последнюю категорию ошибки и подтверждённый внешний ID. При временной ошибке увеличивайте интервал. При неверных правах или недопустимом поле не повторяйте запрос каждую секунду: отправьте уведомление ответственному и сохраните заявку до исправления.
При неопределённом результате запроса сначала ищите созданную сущность по внешнему ID. Если она найдена, сохраните связь, а не создавайте новую. Сам вебхук не решает эту задачу: он лишь даёт способ вызвать API. Логику идемпотентности, ошибок и восстановления проектируют отдельно.
Для email полезен стабильный Message-ID, но он не гарантирует, что почтовый сервер удалит повторы. Различайте «SMTP принял письмо», «получено уведомление о недоставке» и «менеджер увидел сообщение». Если письма задерживаются, используйте отдельную инструкцию по SMTP и DNS.
Что проверить перед публикацией
- Обычная заявка создаёт одну запись сайта, одну сделку и одно письмо.
- Повтор нажатия не создаёт вторую заявку с тем же идентификатором отправки.
- При отключённом Битрикс24 письмо уходит, а CRM-задание остаётся в очереди.
- При ошибке SMTP сделка создаётся независимо от письма.
- После восстановления доступа повтор доставляет заявку и не дублирует уже созданную сущность.
- Неверный телефон или отсутствие обязательного согласия не приводят к успеху формы.
- После перезапуска процесса незавершённые задания остаются доступны обработчику.
Используйте явно обозначенные тестовые контакты и согласованную тестовую воронку. Не отправляйте десятки проверок в рабочую очередь менеджеров без предупреждения. Результаты запишите в таблицу приёмки вместе с локальным и внешним ID; ключи API и персональные данные в публичный отчёт не включайте.
Что будет при окончании подписки Битрикс24
Доступность REST и отдельных функций зависит от действующих условий портала. Интеграция должна обнаружить отказ, сохранить обращения и продолжить независимую доставку на email. После восстановления доступа очередь можно обработать по согласованным правилам. Это не способ обойти ограничения тарифа, а защита от потери заявок.
Такую схему мы применяем на собственном сайте: технический кейс ISKAR. Для своего проекта начните с ТЗ на интеграцию: оно определит поля, роли, повторы и критерии готовности до разработки.
Учебный сценарий: CRM ответила с задержкой
Посетитель отправил форму, сайт сохранил обращение и поставил две задачи доставки. Почта приняла уведомление, а запрос создания сделки завершился таймаутом. В этот момент нельзя уверенно утверждать, что сделки нет: Битрикс24 мог выполнить операцию, но ответ не успел вернуться. Слепой повтор создания способен добавить второй контакт или сделку. Проверка по устойчивому идентификатору обращения должна предшествовать повторной записи.
Идентификатор создаётся при приёме заявки и остаётся одинаковым для всех попыток доставки. Где его хранить в CRM, определяют при проектировании: например, в отдельном поле или поддерживаемой интеграционной связи. Телефон сам по себе не заменяет идентификатор заявки. Один человек может заказать две разные услуги, а один общий номер может принадлежать нескольким сотрудникам компании. Правила объединения контактов и правила устранения повторной доставки решают разные задачи.
После восстановления API обработчик повторяет только незавершённый канал. Уже отправленное письмо не нужно отправлять снова из-за ошибки CRM. В журнале сохраняют номер обращения, канал, время попытки, категорию ошибки и время следующего повтора. Полный текст сообщения и ключи доступа в технический журнал не выводят. Доступ к заявкам отделяют от доступа к диагностике очереди.
Как принимать такую работу у разработчика
Попросите продемонстрировать обычную отправку, двойное нажатие, перезагрузку страницы после отправки и временный отказ каждого внешнего сервиса. Для каждого сценария заранее запишите ожидаемое число заявок, писем и CRM-сущностей. Восстановление после отказа проверяйте фактически: недостаточно показать статус «запланирован повтор», если обработчик очереди не запускается на сервере.
Отдельно согласуйте наблюдение за застрявшими обращениями. У ответственного должен быть способ увидеть возраст очереди и причину задержки. Успешная техническая приёмка не отменяет эксплуатацию: тариф CRM, пароль почты или права интеграции могут измениться позднее. В регламент поддержки включите контрольную заявку после таких изменений и безопасный порядок повторной доставки. Это делает интеграцию проверяемой и после окончания проекта, а не только в день демонстрации.
