Почему прямой запрос из формы в CRM недостаточен
Если браузер или backend формы отправляет заявку только в CRM, временная недоступность API превращается в риск потери обращения. Надёжнее сначала сохранить заявку в собственной системе, вернуть пользователю подтверждение приёма, а передачу в CRM выполнять отдельным процессом.
Базовая схема интеграции
- Форма принимает данные. Сервер проверяет обязательные поля, ограничения и согласие на обработку данных.
- Заявка получает внутренний идентификатор. Он нужен для трассировки и защиты от повторной отправки.
- Запись сохраняется локально. Приём обращения не зависит от кратковременной доступности CRM.
- Событие попадает в очередь. Worker или bridge передаёт данные в CRM через API.
- Сохраняется внешний идентификатор. Он связывает локальную заявку со сделкой, лидом или обращением CRM.
- Ошибки обрабатываются повторно. Временные сбои не должны требовать ручного повторного заполнения формы клиентом.
Как избежать дублей
Для каждой операции нужен стабильный ключ идемпотентности или согласованное правило поиска существующей записи. В зависимости от процесса это может быть внутренний ID заявки, внешний ID, комбинация источника и события или иной технический ключ. Поиск дублей только по телефону или e-mail часто недостаточен: один клиент может закономерно оставить несколько разных заявок.
Что передавать вместе с заявкой
До разработки составляют карту полей: контактные данные, тема обращения, текст, выбранный продукт, источник, UTM-метки и другие сведения, которые реально используются в CRM. Не стоит отправлять «всё на всякий случай»: состав персональных данных должен соответствовать цели обработки.
Webhooks и обратный обмен
Если сайту или личному кабинету нужно показывать статус, интеграция становится двусторонней. CRM может отправлять webhook при изменении сделки, а backend сайта — проверять подпись или другой механизм авторизации, находить связанную запись и обновлять разрешённые поля.
Безопасность интеграции
- API-ключи и токены хранятся на сервере, а не в клиентском JavaScript.
- Интеграционной учётной записи выдаются минимально необходимые права.
- В журнал не записываются секреты и лишние персональные данные.
- Повторные запросы ограничиваются по частоте и количеству попыток.
- Для персональных данных отдельно проверяются правовые основания, получатели и хранение.
Что подготовить для оценки
Достаточно указать CRM, источник заявок, желаемые поля, направление обмена и доступность тестового контура. Полезно заранее описать, что должно происходить при дубле, недоступности CRM и повторном webhook.