Интеграция сайта с CRM — это обмен событиями и состояниями между двумя системами. До разработки нужно определить источник истины, идентификаторы сущностей и правила повторной передачи.

Какие данные действительно нужны CRM

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

request_id: 01J6...
created_at: 2026-08-27T12:40:00+03:00
source: website
form: project_brief
contact: { name, phone, email }
interest: { service, product_id, comment }
attribution: { utm_source, landing_page, client_id }

request_id должен создаваться на стороне сайта до отправки. Он позволяет повторить запрос после сетевой ошибки и не создать вторую сделку.

Синхронный ответ — ещё не результат

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

  1. Сайт проверяет поля и создаёт неизменяемый идентификатор.
  2. Заявка сохраняется до обращения к внешнему API.
  3. Интеграционный слой ищет контакт и активные сделки.
  4. Правило маршрутизации выбирает воронку и ответственного.
  5. CRM возвращает идентификаторы созданных или обновлённых сущностей.
  6. Сайт сохраняет подтверждение либо планирует повтор.
Не показывайте «заявка принята», если она существует только в памяти браузера. Подтверждение должно означать, что сервер сайта надёжно сохранил обращение.

Откуда берутся дубли

Повторный клик, обновление страницы, тайм‑аут API и повтор webhook — нормальные события. Защита от дублей строится не только на телефоне: один клиент может отправлять разные обращения, а один заказ — обновляться несколько раз.

Используйте два уровня: идемпотентный request_id для конкретного события и бизнес‑правило поиска контакта или открытой сделки. Все автоматические объединения должны оставлять журнал решения.

Что делает интеграцию наблюдаемой

Минимальный журнал содержит время, тип события, идентификатор запроса, код ответа, число попыток и ссылку на сущность CRM. Персональные данные и токены нельзя бесконтрольно писать в лог.

Добавьте очередь повторов с увеличивающимся интервалом, отдельный статус окончательной ошибки и уведомление ответственному. Webhook также нужно проверять на подлинность и обрабатывать повторно безопасно.

Чек‑лист приёмки

  1. Одна заявка при двойном клике создаётся один раз.
  2. Временная недоступность CRM не теряет обращение.
  3. UTM и посадочная страница доходят до сделки.
  4. Изменение статуса заказа не создаёт новый заказ.
  5. Ошибку можно найти по request_id.
  6. Токены хранятся вне клиентского JavaScript.
  7. Есть тестовый контур и сценарий отката.

Начинайте с карты событий и ответственности систем. Выбор CRM и конкретного метода API — следующий шаг, а не отправная точка.