Интеграция amoCRM: свой сервер или коннектор

Связать amoCRM с чем-то ещё можно тремя способами: штатными средствами самой CRM, готовым виджетом или коннектором из каталога и собственной интеграцией на вашем сервере. Второй способ живёт в двух формах, и их стоит различать: виджет в вашем аккаунте и подключение, которое работает на стороне чужого сервиса.

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

Третий способ для одного аккаунта оформляется как приватная интеграция: список аккаунтов у неё ограничен одним, и модерацию площадки она не проходит. Доступ к API тот же, что у любого коннектора. Разница в маршруте данных: они ходят между вашим сервером и CRM, без третьей стороны посередине. Дальше речь про облачную amoCRM и про один аккаунт.

Что уходит наружу, когда вы ставите готовый виджет

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

Что уходит на практике, видно в сетевых запросах. В аккаунте, который я разбирал, так вели себя все три установленных виджета. Один отправлял на сервер разработчика имя, почту и телефон сотрудника, открывшего CRM. Второй отправлял содержимое карточек, с которыми работал. Третий отправлял историю сделки. Это штатная работа таких продуктов, а не чья-то небрежность: их логика выполняется на сервере вендора, иначе она не выполнится вообще. Свой виджет проверяется так же, через сетевые запросы браузера.

Подключение на чужой стороне отказывает молча

У конструктора сайтов, у телефонии, у сервиса рассылок есть готовая связка с amoCRM, и работает она с их стороны. В списке интеграций вашего аккаунта её нет, через API её не перечислить, и узнать штатными средствами, работает ли она сейчас, нельзя.

Чем это кончается, видно на конкретном случае. У интернет-магазина заказы уходили в amoCRM подключением на стороне конструктора сайтов. В конце января оно перестало работать. Не частично, не с ошибками: заказы просто перестали доезжать. Так продолжалось больше двух недель, почти три сотни заказов не попали в CRM. Сигнала при этом не было никакого: у подключения на чужой стороне нет журнала и нет счётчика, который начал бы отличаться от нормы. Померить его живость можно было только так: выгрузить два списка заказов и увидеть, что второй короче. Так и заметили, на сверке, уже сильно позже.

Вторая половина той же связки устроена иначе. События из CRM приходят на сервер заказчика, и каждое входящее ложится в таблицу: что пришло и когда, какое правило сработало, какое действие выполнено, что упало с ошибкой. Оговорка, без которой вывод будет неверным: журнал сам себя не читает. Если к нему не приделать проверку живости и уведомление, своя связка промолчит ровно так же.

Что обычно просят сделать

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

Разница обнаруживается внутри задачи: сколько правил отбора можно завести, сколько источников учесть, какие условия сложить. Поэтому ответ на вопрос «закрывает ли готовый виджет мой сценарий» почти никогда не звучит как «такой задачи в каталоге нет». Он звучит как «есть, но не в том объёме».

Менять CRM ни один из пунктов не требует: меняется то, где работает логика и куда попадают данные по дороге. Набор таких модулей с общей серверной частью я собирал девять календарных дней. Живёт он на самом дешёвом арендованном сервере рядом с другими сервисами компании и наружу ходит по двум адресам: аккаунт amoCRM и Telegram для уведомлений.

Если задача в другом, задавать учётной системе вопросы словами, это другой инструмент: доступ ИИ к учётной системе через MCP.

Как интеграция заводится в аккаунте

Своя интеграция начинается с записи в самой CRM, ещё до первой строки кода. Администратор аккаунта создаёт интеграцию в разделе интеграций и получает три вещи: идентификатор интеграции, секретный ключ и код авторизации. Ими сервер обменивается с CRM, чтобы получить доступ; там же заранее указывается адрес для ответа. Код авторизации живёт двадцать минут, и это типичное место обрыва.

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

Во что обходится каждый путь

Цифра из практики. В аккаунте, который я разбирал, три платных виджета стоили около шестидесяти восьми тысяч российских рублей в год. Один из тарифов считался за каждые тридцать пользователей, то есть счёт рос вместе со штатом. Внутри подписки обнаружилась вторая подписка: часть настроек в базовом тарифе была закрыта и открывалась за отдельную годовую доплату.

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

Для компании с большим отделом продаж и несколькими нестандартными сценариями своё окупается. Для компании, где в CRM три человека и нужен один типовой виджет, оно не окупится никогда, и честный ответ здесь: оставайтесь на подписке. Посередине решает один вопрос: есть ли среди ваших сценариев хоть один, который каталог не закрывает совсем. Подписка на саму amoCRM остаётся в любом случае, от 599 российских рублей за пользователя в месяц при оплате от полугода на сентябрь 2026.

Где у любой интеграции проходит граница

Ограничения платформы своя интеграция не отменяет, она переносит их на вашу сторону. По ним и задают вопросы исполнителю. Приёмник событий, он же вебхук, обязан ответить за две секунды, иначе доставка повторяется, а после сотни неудач подписку отключают: отсюда требование принять, положить в очередь, ответить, работать уже потом. Доступ действует сутки, а право на обновление (ключ обновления, в документации refresh token) живёт три месяца и обменивается однократно. В моей практике связка чаще всего отваливается именно здесь.

Переписка в чатах сделки лежит в отдельном API и подписывается секретом вашего канала, который нельзя выносить в браузер. События, примечания, задачи, звонки и поля достаются обычным API, сообщения клиента так просто не забрать: это стоит знать до того, как кто-то пообещает автоматическую оценку переписок. Где проходят границы доступа к клиентской базе, разобрано отдельно: как подключить ИИ к CRM без утечки базы.

Честно и про своё. В проекте, который я делал, приватная интеграция так и не заняла пункт в левом меню: меню платформа строит на своей стороне, вход пришлось делать через карточку интеграции. Такие места узнают от исполнителя до старта.

Что должно остаться у вас после работы

У виджета из каталога есть то, чего у приватной интеграции нет: модерация площадки. Чем её заменяет своя схема, видно по тому, что остаётся у вас после сдачи.

Код лежит в вашем репозитории. На сервер вы можете зайти сами, доступы заведены на вашу компанию. Интеграция создана в вашем аккаунте, и её ключи вы отзываете одной кнопкой. В базе лежат входящие события и журнал ошибок, рядом работает проверка живости, которая пишет ответственному, когда связка замолчала. И есть описание: какие события слушаем, какие поля трогаем, чего не трогаем никогда.

База с входящими событиями содержит персональные данные ваших клиентов, и теперь за неё отвечаете вы: обновления, резервная копия, срок хранения событий. Это пункт сметы и пункт договора, а не довод против своего сервера.

Последний пункт списка выглядит формальностью, пока не понадобится. Правила вроде «из финального этапа сделки не вытаскиваем» или «в отказной этап автоматически не переводим, потому что вход в него сбрасывает признак оплаты» должны жить в коде и в документе. Если они живут в голове разработчика, следующий инженер узнает о них из последствий.

Как принимать такую работу

Ошибка здесь массовая: одна неверная строка правит сразу все карточки. Делает всё это исполнитель, ваше дело потребовать и посмотреть результат.

Проба до массовой правки. Берётся по одной записи на каждый случай, снимаются счётчики примечаний, задач и тегов, операция выполняется, через минуту идёт сверка. Появились у сделки новые задачи и примечания, значит на этот этап навешена автоматика, о которой никто не вспомнил. Живой пример: в одной воронке стояли два автоматических перевода по расписанию, один раз в сутки двигал дальше весь этап отгрузки, другой раз в месяц закрывал всю доставку как успешную. Из-за них несколько сотен заказов числились успешными, пока на складе они ещё ждали отправки.

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

Повтор и подлинность. Одно и то же событие приходит дважды, это штатное поведение после неудачной доставки, и второй объект создаваться не должен. Отдельно спросите, чем закрыт адрес приёмника: подписи у обычных событий CRM документация не описывает.

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

Доступы исполнителя и откат. Он тоже третья сторона с доступом к вашей базе: отдельные учётные записи, отзыв после сдачи, выдача заново на время поддержки. У массовой операции должен быть режим, который вернёт всё как было.

Про приёмку связки с формой на сайте есть отдельный разбор: как принимать интеграцию формы сайта с CRM.

С чего начать, если решили делать своё

Заполненный бланк выше уже половина технического задания. С ним можно идти к любому исполнителю и получать сопоставимые оценки.

Такие интеграции я собираю на сервере заказчика: код, база и доступы остаются у него. На то, что прописано в спецификации, действует гарантия два месяца. Дальше остаётся поддержка: чужие API меняются, у площадок появляются новые ограничения, у компании появляются новые сценарии. Сопровождение и доработки идут отдельным счётом по часам. Состав работ и условия собраны на странице AI automation и CRM-интеграции.