Интеграция сайта с CRM-системой: как передавать заявки, заказы и данные клиентов

Самый простой сценарий выглядит так:

форма на сайте → CRM

Пользователь отправил заявку, и в CRM появился лид или сделка.

Но в реальном проекте цепочка обычно длиннее:

сайт → проверка данных → поиск существующего клиента → контакт → лид/сделка → источник → ответственный → уведомление → дальнейший статус

А если на сайте есть корзина или личный кабинет:

заказ → клиент → товары → сумма → CRM → изменение статуса → сайт

То есть интеграция — это не один HTTP-запрос. Это набор правил, по которым две системы должны одинаково понимать одного клиента и одну бизнес-операцию.

Набор полей зависит от проекта, но чаще всего нужны четыре группы данных.

Контактные данные

Базовый набор:

• имя;
• телефон;
• email;
• компания;
• комментарий.

Но даже здесь нужно заранее определить правила.

Например, телефон:

+7 999 123-45-67

и:

89991234567

для человека выглядят как один номер, а для наивной проверки могут оказаться двумя разными значениями.

Если перед созданием контакта не нормализовать данные и не проверить существующие записи, CRM быстро заполнится дублями.

Данные заявки или заказа

Например:

• тип услуги;
• товар;
• количество;
• сумма;
• номер заказа;
• выбранный тариф;
• сообщение пользователя;
• прикреплённый файл;
• способ связи.

У контакта и заявки разные роли.

Контакт отвечает на вопрос «кто это?».

Лид, сделка или заказ — «что этот человек сейчас хочет?».

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

Источник обращения

Очень полезно передавать не только поле вроде:

Источник: сайт

но и конкретный контекст:

• URL страницы;
• referrer;
• UTM source;
• UTM medium;
• UTM campaign;
• UTM content;
• UTM term;
• рекламный идентификатор, если он используется;
• первая или последняя точка входа — в зависимости от принятой модели аналитики.

Иначе через месяц все записи в CRM будут выглядеть одинаково:

Источник: сайт

Хотя один клиент пришёл из поиска, другой — из рекламы, третий — из рассылки, четвёртый — со страницы конкретной услуги.

Технический контекст

Иногда стоит сохранять и служебные данные:

• ID заявки на сайте;
• ID заказа;
• timestamp;
• ID пользователя;
• URL формы;
• версия формы;
• внешний идентификатор интеграции.

Пользователю эти поля не нужны. Зато при сбое по ним можно восстановить цепочку и понять, какая запись в CRM относится к какой операции на сайте.

Это один из самых полезных вопросов до написания кода.

Допустим, пользователь заполнил форму:

Имя: Алексей

Телефон: +7…

Интересует настройка сайта

Что должна сделать CRM?

Вариантов много:

1. создать новый контакт;
2. найти существующий контакт по телефону;
3. создать лид;
4. создать сделку в конкретной воронке;
5. связать сделку с найденным контактом;
6. назначить менеджера;
7. поставить задачу;
8. сохранить UTM;
9. отправить уведомление;
10. вернуть идентификатор CRM обратно сайту.

Если эти правила не определить заранее, интеграция обычно превращается в:

«Отправим всё, что есть, а потом разберёмся».

Потом и приходится разбираться с сотнями дублей.

У разных CRM терминология немного отличается, но принцип похож.

Например, в Bitrix24 лид используется как один из объектов CRM, а для новых разработок официальная REST-документация рекомендует универсальные методы crm.item.* вместо старых crm.lead.* и crm.deal.*, развитие которых для основных операций прекращено.

В amoCRM через API отдельно работают с контактами и сделками; между сущностями можно создавать связи.

Для архитектуры интеграции важнее не название объекта, а смысл.

Например:

Иван Петров
        ↓
     контакт
        ↓
 ┌──────┴──────┐
 ↓             ↓
Заявка №1    Заявка №2

Если каждый раз создавать и нового Ивана Петрова, и новую заявку, база быстро станет бесполезной.

Есть четыре распространённых варианта.

Готовая интеграция CMS или формы

Самый простой путь.

Например, модуль интернет-магазина или форма уже умеет отправлять данные в нужную CRM.

Плюсы очевидны:

• быстро;
• меньше собственного кода;
• стандартные сценарии уже реализованы.

Но обязательно проверьте, что именно передаёт модуль.

Иногда интеграция умеет создать лид, но:

• не передаёт UTM;
• всегда создаёт новый контакт;
• не умеет выбрать воронку;
• теряет товары заказа;
• неправильно сопоставляет пользовательские поля.

То есть надпись «есть интеграция с CRM» ещё не означает, что она подходит вашему процессу.

Коннектор или сервис автоматизации

Между сайтом и CRM можно поставить промежуточный сервис.

Схема:

сайт → коннектор → CRM

Это удобно, когда требуется несложная автоматизация без собственной серверной интеграции.

Например:

новая заявка → создать сделку → отправить сообщение → записать строку в таблицу

Но появляется дополнительное звено.

Если что-то перестало передаваться, нужно понимать:

• сайт не отправил;
• коннектор не получил;
• сценарий в коннекторе упал;
• CRM отклонила запрос.

Чем длиннее цепочка, тем важнее журналирование.

Webhook

Webhook часто используют для простого события:

произошло действие — отправить данные на другой URL.

Например:

форма отправлена → POST → integration.example.ru

Дальше ваш сервер сам решает, что делать с данными.

В обратную сторону CRM тоже может использовать webhooks. Например, amoCRM поддерживает подписку на события через API, а webhook может быть подписан сразу на несколько событий.

Webhook используют там, где одна система должна сообщить другой о произошедшем событии:

• создана заявка;
• изменился статус;
• создан заказ;
• сделка перешла на этап;
• клиент изменил данные.

Но webhook — это не полноценная замена API.

Webhook сообщает:

«что-то произошло».

API позволяет спросить или изменить:

«что сейчас находится в системе?»

Прямая интеграция через API

Она нужна, когда бизнес-логика сложнее простого переноса формы.

Например, нужно:

1. найти контакт по телефону;
2. если его нет — создать;
3. проверить активные сделки;
4. создать новую сделку;
5. заполнить пользовательские поля;
6. привязать контакт;
7. добавить товары;
8. назначить ответственного;
9. сохранить полученные ID на сайте.

Такой сценарий уже удобнее контролировать собственным кодом.

Это важное различие.

Представим двустороннюю интеграцию.

Сайт создаёт заказ:

сайт → API CRM → сделка

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

CRM сообщает сайту:

CRM → webhook → сайт

Сайт получает событие и обновляет внутренний заказ.

Получается нормальная двусторонняя схема:

        API
сайт ───────→ CRM
 ↑             │
 └─────────────┘
     webhook

Пытаться сделать всю синхронизацию только webhooks или только периодическими API-запросами обычно сложнее.

Допустим, человек дважды отправил форму.

Или первый запрос прошёл, но браузер не получил ответ и повторил отправку.

Или ваш сервер получил timeout от CRM и решил повторить запрос, хотя CRM уже успела создать запись.

Результат:

Иван Петров
Иван Петров
Иван Петров

и три одинаковые сделки.

Поэтому до создания новой сущности нужно определить правила дедупликации.

Например:

Контакт:

нормализованный телефон → email → внешний ID

Заявка:

website_request_id

Заказ:

order_id

У CRM-записи также полезно сохранять внешний идентификатор сайта, а на сайте — ID объекта CRM.

Получается двусторонняя связь:

site order 1527
        ↕
CRM deal 83421

Тогда повторный запрос можно распознать.

Телефон хорошо подходит для большинства лидов, но не всегда.

Один человек может:

• использовать несколько номеров;
• оставить рабочий и личный email;
• оформить заказ от разных компаний.

И наоборот, один номер иногда используют несколько сотрудников компании.

Поэтому правило дедупликации должно соответствовать реальной модели бизнеса.

Для интернет-магазина это может быть:

customer_id

Для B2B:

ИНН компании + контакт

Для авторизованного сервиса:

user_id

Для простой формы:

телефон/email

Не существует одного универсального ключа для всех сайтов.

Одна из наиболее обидных ошибок выглядит так:

1. пользователь пришёл по рекламе;
2. сайт прекрасно записал UTM;
3. пользователь отправил заявку;
4. в CRM приехали только имя и телефон.

После этого маркетинг видит заявку, но уже не знает источник.

Поэтому UTM лучше рассматривать как часть данных заявки, а не как декоративную информацию для аналитики.

Например:

utm_source = yandex
utm_medium = cpc
utm_campaign = wordpress_repair
utm_content = ad_2
utm_term = wordpress_error

Нужно заранее решить и другую вещь:

какую UTM передавать — первую или последнюю?

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

Если это имеет значение для бизнеса, стоит сохранять обе модели отдельно:

• first touch;
• last touch.

Допустим, сайт отправляет:

service = wordpress
budget = 10000
message = "После обновления ошибка 500"

В CRM уже есть поля:

UF_SERVICE_TYPE
UF_BUDGET
COMMENTS

Нужно явно определить mapping:

service → UF_SERVICE_TYPE
budget → UF_BUDGET
message → COMMENTS

Иначе код превращается в набор случайных соответствий.

Особенно неприятны select-поля.

Например, сайт передаёт:

wordpress

а CRM ожидает внутренний идентификатор:

137

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

Иногда хочется сделать:

fetch("https://crm.example/api/...")

прямо из формы сайта.

Обычно это плохая идея.

Для доступа к CRM требуются ключи или токены, а секреты нельзя безопасно хранить в клиентском JavaScript.

Правильнее:

браузер
   ↓
backend сайта
   ↓
CRM API

Backend:

• проверяет данные;
• сам хранит токены;
• записывает логи;
• контролирует повторы;
• обрабатывает ошибки CRM.

Очень плохой сценарий:

пользователь отправил форму
→ CRM API вернул 500
→ заявка потерялась

Интеграция не должна считать CRM единственным местом, где существует заявка.

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

форма
 ↓
заявка сохранена
 ↓
попытка отправить в CRM

Если CRM недоступна:

status = crm_pending

Затем выполнить повтор.

После успеха:

status = crm_synced
crm_id = 83421

Так временный сбой внешней системы не превращается в потерянного клиента.

Если API-запрос завершился timeout, неизвестно, что произошло.

Возможны два варианта:

1. CRM запрос не получила;
2. CRM получила и обработала его, но ответ не дошёл обратно.

Если просто ещё раз создать сделку, можно получить дубль.

Поэтому операция должна иметь собственный внешний ID.

Например:

website_request_id = 01J9...

Перед созданием или при повторной обработке интеграция должна понимать:

этот запрос уже синхронизировался или нет?

Это особенно важно для очередей, background jobs и автоматических retry.

Не всегда.

Если сайт только собирает заявки, достаточно:

сайт → CRM

Но для интернет-магазина или личного кабинета может потребоваться обратное направление.

Например:

CRM: сделка → "В работе"
↓
сайт: заказ → "Обрабатывается"

Или:

CRM: договор подписан
↓
сайт: открыть доступ

Тогда нужно определить источник истины.

Кто отвечает за статус?

CRM?

Сайт?

ERP?

Если позволить всем системам свободно менять один и тот же статус, легко получить цикл:

CRM изменила сайт
→ сайт изменил CRM
→ CRM снова отправила webhook
→ ...

Поэтому заранее задаётся направление каждой операции.

Пока всё работает, логирование кажется лишним.

Потом приходит менеджер:

«Вчера в 14:32 была заявка, но в CRM её нет».

Без логов остаётся только гадать.

Минимальный диагностический журнал должен содержать:

• время;
• внутренний ID заявки;
• CRM operation;
• HTTP status;
• CRM entity ID;
• результат;
• текст технической ошибки.

Например:

2026-09-13 14:32:11
request_id=9184
operation=create_deal
status=201
crm_id=58341

или:

operation=create_deal
status=429
retry=scheduled

Но нельзя бездумно писать в лог всё тело запросов.

Там могут находиться:

• телефоны;
• email;
• персональные данные;
• API-токены.

Лог должен помогать диагностике, а не становиться ещё одной утечкой данных.

При проектировании интеграции нужно учитывать ограничения API: частоту запросов, права доступа, доступные методы и изменения версий API.

Кроме того, API со временем меняются.

Например, Bitrix24 сейчас рекомендует использовать для новых интеграций универсальные методы crm.item.* для основных операций с лидами и сделками, оставляя старые методы в основном для существующих интеграций.

Поэтому интеграцию, написанную несколько лет назад, иногда приходится обновлять даже при отсутствии изменений на самом сайте.

Проверка «заполнили форму — запись появилась» недостаточна.

Интеграцию нужно проверять не только на успешном сценарии, но и на повторах, сбоях и пограничных ситуациях. Минимальный набор проверок выглядит так.

1. Новый клиент

Контакта нет.

Ожидаем:

создан контакт → создана заявка/сделка → связь установлена

2. Существующий клиент

Телефон уже есть в CRM.

Ожидаем:

существующий контакт найден → новый дубль не создан → создано новое обращение

3. Повторная отправка одной формы

Например, двойной клик.

Ожидаем отсутствие случайных дублей.

4. CRM вернула ошибку

Заявка не должна исчезнуть.

5. CRM долго отвечает

Пользователь не должен ждать 30 секунд на странице только потому, что внешняя система зависла.

6. UTM присутствуют

Проверяем не только контактные поля, но и источник.

7. UTM отсутствуют

Интеграция должна нормально работать и без них.

8. Необязательное поле пустое

CRM не должна отклонять всю заявку из-за одного отсутствующего значения.

9. CRM изменила структуру поля

Особенно важно для списков, стадий и пользовательских полей.

10. Повторная обработка webhook

Одно событие не должно дважды выполнять действие на сайте.

11. Неверный webhook

Неизвестное или некорректное событие не должно приводить к изменению данных.

12. Истёк или отозван токен

Ошибка должна быть видна в мониторинге или логах, а не молча терять заявки.

Диагностику удобнее вести по цепочке.

Шаг 1. Создалась ли заявка на сайте

Если нет, CRM пока вообще ни при чём.

Проблема находится в форме или backend сайта.

Шаг 2. Сайт пытался отправить запрос

Смотрим application logs.

Если попытки нет — проблема в коде интеграции.

Шаг 3. Как ответила CRM

Например:

200/201 — запрос принят;
400 — неверные данные;
401/403 — авторизация или права;
429 — ограничение запросов;
5xx — ошибка внешнего сервиса.

Конкретные коды и формат ошибок нужно сверять с документацией используемой CRM.

Шаг 4. Создалась ли сущность

Иногда запрос формально успешен, но запись появилась не там:

• другая воронка;
• другой ответственный;
• неправильный этап;
• тестовый аккаунт;
• неправильный портал.

Шаг 5. Не сломалась ли следующая операция

Например:

контакт создан
→ создание сделки упало

Тогда в CRM контакт есть, а ожидаемой сделки нет.

Это уже не «CRM не работает», а частично выполненная транзакция интеграции.

Создавать новый контакт на каждую заявку.

База быстро заполняется дублями.

Передавать только имя и телефон.

Теряются источник, страница и смысл обращения.

Доверять данным формы без серверной проверки.

В CRM попадает мусор или неожиданные значения.

Хранить CRM-токен в JavaScript.

Секреты должны оставаться на сервере.

Считать webhook гарантированной однократной доставкой.

Обработчик должен спокойно переносить повторы.

Не сохранять собственный ID заявки в CRM.

Потом трудно сопоставлять две системы.

Не сохранять CRM ID на сайте.

Возникает та же проблема в обратную сторону.

Не продумывать ситуацию, когда CRM недоступна.

Временный сбой превращается в потерянный лид.

Считать первую успешную заявку окончанием разработки.

Самые неприятные ошибки появляются на повторах, дублях и сбоях.

Успешная интеграция — это не та, которая один раз передала тестовую форму.

Она должна нормально работать, когда:

• клиент уже существует;
• форму отправили дважды;
• CRM отвечает медленно;
• API временно недоступен;
• webhook пришёл повторно;
• часть полей отсутствует;
• изменился токен;
• менеджер поменял статус;
• один человек оставил несколько заявок.

Именно в этих ситуациях становится видно, была ли интеграция спроектирована как система или просто как один HTTP-запрос.

Нормальная схема выглядит примерно так:

форма / заказ
      ↓
backend сайта
      ↓
сохранение заявки
      ↓
поиск клиента
      ↓
CRM API
      ↓
contact + lead/deal
      ↓
crm_id сохраняется на сайте
      ↓
webhook / изменение статуса

Когда каждый переход можно проверить отдельно, интеграция становится гораздо проще и в поддержке.