Интеграции amoCRM делают тремя способами: встроенные вебхуки, готовый коннектор из каталога, собственный сервис обмена.
На потоке от 300 заявок в день первые два варианта начинают терять события. Причина — ограничения частоты обращений, таймауты, повторные вебхуки. На выходе — дубли сделок и расхождения с 1С.
Устойчивый обмен с очередью и мониторингом строят за 3–6 недель.
Дальше — где именно рвется обмен на нагрузке и сколько стоит сделать его устойчивым.
Три способа интеграции amoCRM
Первый способ — встроенные вебхуки: amoCRM сообщает о событии, а обрабатывает его ваш код. Второй — готовый коннектор или виджет: связь настраивают без программирования. Третий — собственный сервис на API и вебхуках, который сам решает, что и в каком порядке отправлять.
Если на лендинге 1–2 простые формы, хватает конструктора форм или коннектора. Нестандартная воронка, 1С и поток заявок — задача для собственного сервиса.
Путь к конструктору форм в источниках разный — «Настройки → Интеграции» или «Сделки → Настроить → Размещение формы»; сверьте с меню своего аккаунта.
Для начала выпишите, сколько систем участвует в обмене и сколько заявок в сутки они принимают.
Сравнение способов в таблице
Для 1С подходят API, вебхуки или сторонний коннектор, готового шаблона под каждую конфигурацию нет. Перед выбором проверьте, какие документы и в какую сторону идут и кто ведет справочники.
Регистрация интеграции и токены
Интеграцию регистрирует администратор аккаунта; API-ключи в интерфейсе не выводятся с 1 июля 2020 года. Код авторизации меняют на пару токенов: access живет 24 часа, refresh — три месяца. Access обновляют заранее, по сроку, а не после ошибки 401.
Пару хранят в tokens.txt или в базе вне публичной папки сайта и после каждого обновления перезаписывают оба токена. Если новая пара не записалась, следующее обновление не пройдет и интеграция встанет. Работала сутки и замолчала — первым делом проверьте запись токенов.
Что ломается при всплеске заявок
Допустим, рекламная рассылка привела 40 заявок за минуту, а скрипт отправлял каждую в API прямо из обработчика формы, без паузы. По документации amoCRM лимит — 7 запросов в секунду на интеграцию и 50 на аккаунт. Пачка запросов его превышает, и API отвечает ошибками: часть заявок в CRM не попадает.
Ошибки лимита касаются ваших запросов в amoCRM. На обратной стороне в это же время копятся таймауты и повторные вебхуки — это другая поломка, и лечится она иначе.
Если запросы к API идут прямо из обработчика формы без паузы, на пике часть заявок потеряется. Если 7 запросов в секунду не хватает даже при ровном темпе, лимит поднимают через техподдержку amoCRM.
Отправная точка — пиковое число заявок в минуту за последний месяц: посчитайте его, прежде чем выбирать схему.
Пакеты, таймауты и повторы вебхуков
Большинство методов API отдают до 250 сущностей за запрос, а на создание рекомендовано передавать не больше 50 за раз. Обработчик вебхука, который отвечает медленно, получает то же событие повторно. Поэтому схема такая: принять запрос, сразу ответить, поставить задачу в очередь и только потом обработать.
Подписку создают запросом POST /api/v4/webhooks: в поле destination — адрес обработчика, в settings — только нужные события, например add_lead и status_lead. Лишние события — лишняя нагрузка на обработчик. Конкретные таймауты и число повторов сверяйте с официальной документацией.
Очередь и идемпотентность против дублей сделок
Допустим, вебхук о смене этапа пришел дважды. Скрипт дважды создал сделку и дважды отправил документ в 1С: у менеджера две одинаковые сделки, у бухгалтерии — два документа.
Если событие может прийти повторно, у каждой заявки должен быть ключ идемпотентности — метка, которую сервис хранит у себя. Перед обработкой он проверяет, встречался ли такой ключ, и повтор пропускает. Ключом служит ID заявки с сайта или ID события.
Чего избегать: создавать контакт, не поискав существующий, — иначе у одного человека несколько карточек и ему звонят по очереди. Проверка на сегодня: найдите сделки с одинаковым телефоном за неделю и посчитайте дубли.
Схема очереди с повторами
Псевдокод, комментарий после //:
задача = принять(заявка) // сохранить и сразу ответить источнику
если ключ(задача) обработан: пропустить // повтор не создаст вторую сделку
ждать(пауза_под_лимит) // темп ниже лимита интеграции
ответ = создать_сделку_с_контактом(задача) // один запрос на задачу
если ошибка: увеличить(пауза); вернуть_в_очередь(задача) // нарастающая пауза
если amoCRM недоступна: отложить(задача) // заявка не теряется
иначе: отметить_обработанным(ключ) // только после успешного ответа
Создание сделки с контактом — один вызов POST /api/v4/leads/complex, тело — массив сделок:
[{"name": "Заявка с сайта", "_embedded": {"contacts": [{"first_name": "Анна", "custom_fields_values": [{"field_code": "PHONE", "values": [{"value": "+7…"}]}]}]}}]
Порядок важен: ключ проверяют до запроса, а отмечают обработанным только после успешного ответа, иначе упавший запрос сочтут выполненным. Отложенные задачи забирает тот же воркер, когда amoCRM снова отвечает.
Дедупликация без потери UTM
Контакт ищут по телефону, email или другому полю — так устроены правила сопоставления в Генезисе. Если он найден, новую сделку привязывают к нему.
UTM и номер визита roistat попадают в сделку через сопоставление: в форме или коннекторе каждой переменной (utm_source, utm_campaign и другим) назначают поле сделки в «Полях запроса». Записывают их, даже если контакт найден. Проверка — по логам: какие сущности созданы, какие найдены.
Мониторинг обмена — 5 метрик и алерты
Пять метрик, пороги — ориентир из практики:
- •Ошибка обновления токена — алерт сразу.
- •Доля ответов о превышении лимита — алерт при росте к прошлой неделе.
- •Длина очереди и возраст самой старой задачи — алерт, если задача старше одного цикла обработки.
- •Доля сделок с пустыми обязательными полями — алерт при росте после правки формы или воронки.
- •Доля сделок без UTM — алерт при росте к прошлой неделе.
Проверка одной заявки: лид в «Неразобранном», контакт создан, имя, телефон, кастомные поля и UTM заполнены. Если поле пустое — проверьте ID и тип поля, затем актуальность кода формы на сайте.
Первым заведите алерт на ошибку обновления токена: без него остановку обмена замечают по жалобам менеджеров.
Сколько стоит интеграционный слой
Если заявок меньше 300 в сутки и система одна, хватит коннектора или скрипта. Главный драйвер стоимости — число систем, двусторонний обмен и связка с 1С: каждая точка добавляет сопоставление полей и сценарии ошибок.
Сопоставьте свой объем заявок с одним из сценариев, а смету подрядчика сравнивайте по составу: есть ли очередь, идемпотентность и алерты.
Когда обмен выносят в отдельный сервис
Выносить обмен в отдельный сервис пора, когда совпадают признаки. В обмене несколько систем: сайт, 1С, Метрика, боты Senler. Поток от 300 заявок за сутки. Нужны очередь под лимиты и двусторонний обмен, когда внешняя система не только отправляет данные, но и читает статус сделки.
Поверх сервиса удобно строить сценарии: Sales-Bot распределяет сделку между ответственными сразу после создания, конверсии уходят в Яндекс Метрику через вебхук и API Метрики, личный кабинет клиента показывает статус сделки.
Если без очереди уже появляются дубли, сервис выносят, а не чинят скрипт: заплатка держит поток до следующего всплеска. Начните с того, что назначьте в команде владельца обмена — человека, который отвечает за него целиком, от формы на сайте до 1С. Без владельца алерт приходит в общий чат и там теряется.
Кто поддерживает обмен
Поддержка — это хранение и ротация пары токенов, реакция на алерты, изменения полей и воронок, сверка с 1С. Каждую правку воронки проверяют на тестовой заявке до того, как она уйдет в работу. Число сделок в amoCRM и документов в 1С регулярно сверяют за один и тот же период: так расхождение видно раньше.
Приватная интеграция в обычном аккаунте требует заявления об отказе от технической поддержки amoCRM. Поэтому обмен сопровождает разработчик или интегратор, а не служба поддержки CRM. Это обычная практика: у обмена просто появляется понятный ответственный.
Построим устойчивый обмен между CRM, 1С и сайтом: интеграционные проекты от 300 000 ₽, раздел «CRM на заказ»
Источники
