Клиент и контекст проекта
Заказчик — российская компания с работающим корпоративным сайтом на WordPress. На сайте давно установлена единая форма обратной связи, которая используется на всех страницах и обеспечивает базовый поток заявок. Со временем бизнес клиента вырос и начал использовать в работе менеджеров amoCRM — современную CRM-систему для управления воронкой продаж. Естественным шагом стала задача автоматически отправлять заявки с сайта в amoCRM, чтобы менеджеры не переносили их вручную и не теряли обращения.
Все работы по разработке плагина, настройке авторизации и интеграции с amoCRM API я выполнил лично за 5 рабочих дней. Обезличивание: домен сайта, название юрлица, контактные данные и скриншоты с опознаваемыми элементами интерфейса в публичной версии кейса не приводятся. Я базируюсь в Москве и работаю с заказчиками из любого региона РФ, СНГ и за рубежом — в данном случае все работы были выполнены удалённо.
Проблема
Первое, что попробовал самостоятельно — это создать amoCRM-форму через встроенный конструктор и разместить её на сайте. Это «коробочное» решение, которое amoCRM рекомендует для типовых сайтов, и оно действительно работает — но только в самом простом случае.
Проблема 1. amoCRM-форма вставляется только в единственном экземпляре
При попытке разместить amoCRM-форму на страницах сайта выяснилось: если форма одна на странице — она вставляется и работает без проблем. Это подходящий сценарий для лендингов или простых визиток. Но на сайте клиента есть страницы, где форм обратной связи должно быть от 3 до 6 штук одновременно — например, длинные коммерческие предложения, страницы услуг с несколькими блоками захвата, статьи с призывом к действию в разных секциях. И вот тут всплыл системный баг самого amoCRM.
Проблема 2. Несколько amoCRM-форм на одной странице «слипаются»
При размещении двух и более amoCRM-форм на одной странице все они визуально «слипаются» в одно место — то есть отображаются в одной точке страницы, перекрывая друг друга. Это известный баг amoCRM, связанный с тем, как скрипт их конструктора позиционирует формы на странице через JavaScript. Решение amoCRM не рассчитано на множественное размещение, и «из коробки» эту проблему не обойти — ни настройками самой формы, ни параметрами встраиваемого кода.
Для клиента это означало, что штатный инструмент amoCRM непригоден для его сайта. Визуально формы выглядели сломанными, пользователи не могли их корректно заполнить, заявки терялись. Сайт с шестью формами на странице — это не редкость для нагруженных корпоративных проектов, и решение amoCRM просто не подходит под этот сценарий.
Проблема 3. Сторонний скрипт amoCRM загружает страницу и зависим от внешнего сервиса
Дополнительный минус штатного способа: amoCRM-форма встраивается через внешний JavaScript, который подгружается с серверов amoCRM. Это значит, что при недоступности amoCRM (а это случается) форма на сайте вообще не отображается — пользователь видит пустое место вместо рабочего поля ввода. Плюс каждый такой скрипт увеличивает время загрузки страницы и добавляет точку зависимости от сторонней инфраструктуры.
Решение
Поскольку «коробочное» решение amoCRM не подходило под сценарий клиента, было принято решение написать собственный плагин для WordPress, который берёт на себя две ключевые задачи: авторизацию и автоматическое продление токенов amoCRM (через OAuth 2.0) и перехват события отправки формы с последующей передачей данных по amoCRM API. Такой подход полностью устраняет зависимость от JavaScript-виджета amoCRM и позволяет размещать любое количество форм на странице — они работают независимо и не «слипаются».
Все работы я выполнил лично за 5 рабочих дней по следующему плану.
Этап 1. Анализ amoCRM API и выбор архитектуры
- Изучена официальная документация amoCRM API: REST-эндпоинты для создания сделок и контактов, механизм авторизации через OAuth 2.0, протокол обновления access_token по refresh_token.
- Проанализирован формат передаваемых данных: какие поля обязательны для создания сделки, как связать сделку с контактом, как передавать пользовательские поля (UTM-метки, источник, страница отправки).
- Принято архитектурное решение: плагин берёт на себя только отправку данных, а визуальная часть формы остаётся на стороне WordPress — это устраняет зависимость от JS-виджета amoCRM и позволяет использовать любое количество форм.
Этап 2. Реализация модуля авторизации и продления токенов
- Реализован модуль OAuth 2.0: получение первого access_token и refresh_token через авторизационный код, безопасное хранение токенов в базе данных WordPress.
- Реализовано автоматическое продление access_token по refresh_token — срок жизни access_token у amoCRM ограничен, поэтому без автоматического продления интеграция перестала бы работать через несколько часов.
- Добавлена задача cron, которая периодически проверяет актуальность токена и продлевает его до истечения срока действия — клиенту не нужно ничего делать вручную.
- Реализована обработка ошибок авторизации: при критическом сбое (например, отзыве токена со стороны amoCRM) плагин уведомляет администратора сайта, чтобы тот мог оперативно реактивировать интеграцию.
Этап 3. Перехват события отправки формы
- Реализован перехватчик события отправки формы, который срабатывает до стандартной обработки плагина форм и не нарушает его работу.
- Настроена фильтрация: плагин определяет, какие формы на сайте должны отправлять данные в amoCRM, а какие — нет (не все формы должны создавать сделки, например, форма подписки на рассылку этого не требует).
- Реализована маппинг-таблица: какое поле формы соответствует какому полю сделки в amoCRM (имя → имя контакта, телефон → телефон, услуга → направление сделки и т.д.).
- Добавлена передача UTM-меток и источника заявки: при отправке формы плагин автоматически прицепляет UTM-параметры из cookies и URL страницы, на которой была отправлена форма — это критично для корректной атрибуции в amoCRM.
Этап 4. Отправка данных по amoCRM API
- Реализован метод создания сделки в amoCRM: формирование корректного JSON-payload, отправка POST-запроса к эндпоинту /api/v4/leads, обработка ответа.
- Реализовано создание контакта и привязка его к сделке: если контакт с таким email или телефоном уже существует, плагин связывает новую сделку с существующим контактом, а не создаёт дубль.
- Добавлена передача пользовательских полей: услуга, тип обращения, страница отправки, IP-адрес пользователя — все эти данные попадают в карточку сделки в amoCRM и доступны менеджерам.
- Реализована обработка ошибок API: при временной недоступности amoCRM плагин помещает заявку в очередь и повторяет отправку с экспоненциальной задержкой — ни одна заявка не теряется.
Этап 5. Тестирование и внедрение
- Проведено нагрузочное тестирование: отправка 50 заявок подряд с разных форм и страниц — все корректно создаются в amoCRM, без потерь и дублей.
- Протестирован сценарий с 6 формами на одной странице — все работают независимо, баг «слипания» полностью устранён.
- Протестировано автоматическое продление токенов: искусственно сброшен access_token, плагин корректно получил новый через refresh_token без участия пользователя.
- Проведено обучение администратора сайта: как добавить новую форму и привязать её к amoCRM, как изменить маппинг полей, как отслеживать статус интеграции.
Результаты
Все работы выполнены за 5 рабочих дней. Заявки с сайта клиента теперь автоматически попадают в amoCRM, причём с любой формы сайта — включая страницы с 6 формами одновременно, где штатный инструмент amoCRM принципиально не работал. Менеджеры клиента больше не тратят время на ручной перенос заявок, а каждая заявка содержит полную атрибуцию: UTM-метки, страницу отправки, IP пользователя — то есть всё, что нужно для корректной работы воронки в amoCRM.
| Показатель | Результат |
| Срок выполнения работ | 5 рабочих дней |
| Платформа сайта | WordPress |
| CRM-система | amoCRM |
| Подход к интеграции | кастомный плагин + amoCRM REST API |
| Способ авторизации | OAuth 2.0 с автоматическим продлением токенов |
| Форм на одной странице (максимально) | до 6 штук (без бага слипания) |
| Сторонних скриптов amoCRM на странице | 0 (заменены собственным решением) |
| Заявок, уходящих «в никуда» из-за бага | 0 после внедрения |
| Ручного продления токенов со стороны клиента | не требуется (автоматизировано) |
Дополнительно клиент получил: полностью собственное решение, не зависящее от внешнего JavaScript amoCRM — сайт работает стабильно, даже если amoCRM временно недоступен; автоматическое продление токенов без ручного вмешательства; гибкую систему маппинга полей — при добавлении новых форм на сайт не нужно привлекать разработчика, администратор настраивает привязку полей через интерфейс плагина; очередь отправки заявок с повторными попытками — даже при кратковременных сбоях amoCRM ни одна заявка не теряется.
Технологический стек
WordPress PHP 8.x amoCRM REST API v4 OAuth 2.0 MySQL (хранение токенов) WP-Cron Custom Plugin Hooks & Filters API UTM-tracking Webhook-очередь с retry