1. Главная
  2. Разработка
  3. amoCRM · Web SDK

amoCRM · Web SDK

Разработка виджетов amoCRM под процесс вашей команды

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

  • amoCRM · официальный партнёр
  • Битрикс24 · бизнес-партнёр
  • Код и доступы передаваем

Сначала выбор пути

Разработка — третий вариант, а не первый

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

01 / Штатно

Настройка платформы

Поля, права, роботы, бизнес-процесс или стандартный webhook закрывают сценарий без нового продукта.

02 / Готово

Партнёрское решение

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

03 / На заказ

Собственная разработка

Нужна, если процесс, интерфейс, объём, безопасность или контроль ошибок не укладываются в готовые варианты.

Типовые запросы

Сценарии заказного виджета

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

01

Калькулятор и КП

Расчёт по правилам компании, скидки, валидация, товары, генерация документа и сохранение версии.

02

Форма в карточке

Обязательные данные, зависимые поля, проверка прав, подпись, печать или PDF без отдельной таблицы.

03

Внешний сервис

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

04

Маршрутизация

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

05

Свой раздел

Пункт меню, страница настроек, реестр операций, массовое действие или панель контроля.

06

Тиражный продукт

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

Проектные решения

Из чего складывается устойчивый виджет amoCRM

Детали ниже определяют эксплуатацию выбранного формата и проверяются до оценки реализации.

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

Секреты внешнего API не размещаем в браузерном коде виджета. Frontend передаёт контекст и команду собственному backend, а тот проверяет пользователя, обращается к внешней системе и пишет журнал. Так можно отозвать доступ и расследовать спорную операцию без публикации ключа каждому пользователю CRM.

До установки проверяем соседние расширения и автоматизации. Два виджета могут реагировать на одно действие, менять одинаковое поле или добавлять конфликтующие стили. Уникальный базовый класс и использование документированных Web SDK callbacks уменьшают риск, но регрессия в реальном аккаунте всё равно обязательна.

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

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

Время открытия карточки измеряем вместе с установленным виджетом. Тяжёлые справочники загружаем по требованию, а не при каждом входе в сделку. Если внешний сервис недоступен, основная работа в amoCRM остаётся возможной.

Архитектура

Данные проходят через контролируемый маршрут

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

Источник
Интерфейс amoCRM

Событие, пользовательское действие или плановая выборка.

Контроль
Backend виджета

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

Результат
Внешний API

Подтверждение операции, сохранённая связь объектов и сверяемый итог.

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

Результат проекта

Передаём не только код, но и управляемую систему

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

01

Прототип действия

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

02

Архив Web SDK

manifest.json, локализации, уникальные стили, script.js, шаблоны и разрешённые locations.

03

Серверная часть

OAuth, API amoCRM, интеграция с внешним сервисом, очередь и хранение состояния при необходимости.

04

Права и данные

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

05

Регрессия

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

06

Поддерживаемость

Исходники, репозиторий, сборка, журнал изменений и процедура обновления после изменений amoCRM.

Специфика задачи

Когда виджет не нужен

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

01 / Настройка

Есть штатная функция

Поле, Digital Pipeline, Salesbot или права закрывают задачу без отдельного кода и сервера.

02 / Готовое решение

Есть подходящий виджет

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

03 / Разработка

Нужна своя логика

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

Источники и границы. Возможности платформ сверены 2 октября 2026 года: Web SDK amoCRM · Механика виджета. Конкретные методы, тарифы, редакции и требования публикации повторно проверяем перед проектом.

Надёжность

Проверяем отказ до того, как он станет инцидентом

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

Duplicate

Повтор события

Тот же ID не создаёт вторую сделку, заказ, документ или платёж.

Timeout

Нет ответа

Операция остаётся в контролируемом состоянии и повторяется по правилам.

Partial

Частичный результат

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

Recovery

Восстановление

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

Порядок работы

От контрольного примера до сопровождения

Для локальной задачи этапы компактные. Для критичной интеграции каждый этап имеет отдельный результат и принимающего сотрудника.

01

Обследование

Текущий процесс, системы, данные, ограничения и цена ошибки.

02

Проектирование

Вариант решения, карта данных, события, права и критерии приёмки.

03

Разработка

Контуры, код, конфигурация, журнал и тестовые данные.

04

Пилот

Обычный путь, исключения, роли, нагрузка и соседние процессы.

05

Эксплуатация

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

Форматы работы

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

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

Проектная разработка

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

оценка после обследования
  • требования и архитектура
  • итерации и демонстрации
  • тестирование отказов
  • передача кода и документации
Оценить проект

Пакет часов

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

от 15 000 ₽
  • диагностика одного сбоя
  • локальный webhook или поле
  • проверка готового модуля
  • небольшая правка документации
Проверить границы задачи

Короткие ответы

Вопросы до старта

Точная оценка появляется после проверки систем и одного реального сценария. Ниже — границы, которые полезно знать заранее.

Виджет работает без backend?

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

Можно доработать существующий виджет?

Если доступны исходники и право на изменение — да. Сначала проверяем архитектуру, используемые locations, версию API, зависимости и возможность безопасной сборки.

Размещаете виджет в amoМаркет?

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

Кто владеет сервером и кодом?

Для заказной разработки рекомендуем репозиторий и инфраструктуру на аккаунтах заказчика либо прозрачную схему передачи. Конкретный вариант фиксируем до старта.

Связанные направления

Выберите компонент, который соответствует задаче

Страницы кластера разделены по поисковому и проектному намерению, но в реальной архитектуре компоненты часто работают вместе.

Следующий шаг

Покажите одну операцию, которая сейчас выполняется вручную или теряется

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

  • Не просим готовое техническое задание для первого разговора
  • Отдельно обозначаем неизвестные и внешние зависимости
  • Не продаём разработку, если задача решается надёжнее без неё

Описать задачу

Проект с проверяемой приёмкойСпроектируем «Разработка виджетов amoCRM под процесс вашей команды» с тестами и передачей результата

Зафиксируем операцию, данные, ошибки и критерии готовности до оценки разработки. Реализацию оформим проектом, а мониторинг и развитие — ежемесячным сопровождением.

Отправка формы ни к чему не обязывает. Сначала уточним границы задачи.