B2B pipeline в Kommo через API: полный гайд

Полноценный B2B pipeline в Kommo через API строится на трёх вещах, которых нет в стандартной воронке: кастомные поля и привязки для нескольких стейкхолдеров на одной сделке, синхронизация ролей через /api/v4/leads/complex и автоматизация переходов через webhook вместо ручного перетаскивания карточек. Стандартная воронка Kommo держит линейный цикл «лид -> сделка -> оплата». Сложный B2B-цикл с экономическим покупателем, техническим евангелистом и юристом она не держит - данные о ролях расползаются по заметкам и теряются при росте.

В интеграционных проектах Exceltic.dev мы видим один и тот же сценарий: команда переросла линейную воронку, в сделке участвуют 3-5 человек со стороны клиента, и менеджеры начинают вести «второй CRM» в Notion или Google Sheets - потому что Kommo из коробки не показывает, кто из контактов блокирует сделку. Проблема не в платформе. Проблема в том, что B2B-логику в Kommo нужно достраивать через API, а не настраивать мышкой. Ниже - как именно: какие объекты использовать, как синхронизировать роли, как заменить ручные переходы на webhook-автоматизацию и как собрать отчётность, которой нет в нативном интерфейсе.

Боль конкретна: head of sales не может ответить борду на вопрос «почему сделка на $80k висит во втором этапе шесть недель», потому что причина - неотвеченное возражение технического стейкхолдера - живёт в комментарии, который никто не парсит. При линейной воронке это терпимо. При 40+ активных B2B-сделках это слепая зона, которая стоит квартального прогноза.

Что значит «полноценный B2B pipeline»

Полноценный B2B pipeline - это воронка, которая отражает не движение сделки, а движение группы решений нескольких людей. Линейная воронка фиксирует один статус на сделку. B2B-цикл требует фиксировать состояние по каждой роли отдельно.

B2B pipeline: модель воронки, где у одной сделки есть несколько контактов с разными ролями (экономический покупатель, технический евангелист, пользователь, юрист), и переход между стадиями зависит от состояния этих ролей, а не от одного флага.

Три вещи, которые отличают B2B-воронку от стандартной:

Стадии отражают процесс закупки, а не действия менеджера. Не «позвонил - отправил КП», а «квалификация ЛПР - техническая валидация - согласование бюджета - юридическая проверка».
Несколько контактов и ролей на сделке. Kommo позволяет привязать к сделке несколько контактов, но из коробки не хранит их роль в закупке. Эту структуру добавляют кастомные поля.
Данные не теряются при росте. При 200 сделках в год информация о ролях, возражениях и next step должна быть в структурированных полях, а не в свободном тексте заметок. Иначе при передаче сделки между менеджерами контекст исчезает.

Как устроена базовая воронка и чем стадии отличаются от полей, разобрано в материале о настройке воронки в Kommo - здесь мы идём дальше, на уровень API.

Чего не хватает в стандартной настройке

Стандартная настройка Kommo не хранит роли стейкхолдеров и не умеет условных переходов между стадиями по состоянию нескольких контактов. Это два главных разрыва для B2B.

Что Kommo даёт из коробки:

Несколько воронок (pipelines) и стадий (statuses) - управляются через GET /api/v4/leads/pipelines и /statuses.
Привязку нескольких контактов и одной компании к сделке.
Кастомные поля 14 типов: text, numeric, select, multiselect, date, checkbox, url, textarea и другие.
Digital Pipeline - визуальный автоматизатор с триггерами на смену стадии.

Чего не хватает для B2B:

Роль контакта в сделке. Контакт привязан, но его роль (ЛПР / влияющий / блокер) нигде не зафиксирована структурно. По обзору функций Kommo видно, что нативная модель данных рассчитана на сделку с одним основным контактом.
Условные переходы по состоянию ролей. Digital Pipeline триггерит на смену стадии, но не умеет «не пускать сделку дальше, пока юрист не подтвердил».
Сложные объекты. Нет нативной сущности «стейкхолдер» с собственными полями - в отличие от HubSpot, где это часть модели данных. Разницу моделей мы разбирали в статье про модель данных Kommo и HubSpot.

Именно эти разрывы закрываются через API.

Как достроить B2B pipeline через API

Достроить B2B pipeline через API - значит добавить структуру ролей кастомными полями, синхронизировать стейкхолдеров через complex-эндпоинт, заменить ручные переходы на webhook-автоматизацию и вынести данные в отчётность. Разберём по частям.

Кастомные поля и объекты-обходы

Kommo не даёт создать новую сущность «стейкхолдер», поэтому роли моделируются двумя способами. Первый - кастомные поля на контакте: select-поле «Роль в закупке» со значениями «ЛПР / Влияющий / Пользователь / Блокер». Создаётся через POST /api/v4/contacts/custom_fields, заполняется в custom_fields_values с field_id и values.

Второй способ для сложных сценариев - объект-обход через каталоги (lists / catalogs). Создаётся каталог «Стейкхолдеры» со своими полями (роль, статус согласования, дата последнего касания), а его элементы привязываются к сделке. Это даёт нативной сделке де-факто дочернюю таблицу - аналог того, чего в стандартной модели нет.

Объект-обход: использование каталога Kommo как дочерней сущности сделки для хранения данных, под которые в нативной модели нет отдельного объекта.

Для числовых аналитических полей (вес возражения, вероятность по роли) используется тип numeric - его потом удобно агрегировать в отчётности.

Синхронизация ролей через complex-эндпоинт

Когда лид приходит из формы или аутрич-инструмента сразу с несколькими контактами, создавать их по одному - источник дублей и гонок. Для этого есть POST /api/v4/leads/complex: один запрос создаёт сделку, привязывает к ней несколько контактов и компанию, и проставляет кастомные поля каждому.

Пример полезной нагрузки - сделка с двумя стейкхолдерами разных ролей:

[
  {
    "name": "Внедрение для Acme Corp",
    "pipeline_id": 3104,
    "status_id": 142,
    "_embedded": {
      "contacts": [
        {
          "first_name": "Anna",
          "custom_fields_values": [
            { "field_id": 88011, "values": [{ "value": "ЛПР" }] }
          ]
        },
        {
          "first_name": "Mark",
          "custom_fields_values": [
            { "field_id": 88011, "values": [{ "value": "Технический евангелист" }] }
          ]
        }
      ],
      "companies": [{ "name": "Acme Corp" }]
    }
  }
]

Ключ к идемпотентности - дедупликация по email или телефону перед вызовом complex, иначе при повторной отправке формы создастся второй контакт. На практике перед complex идёт GET /api/v4/contacts?query=email и решение: создавать или обновлять.

Автоматизация переходов через webhook

Ручное перетаскивание сделок между стадиями в B2B - источник рассинхрона: менеджер забыл подвинуть карточку, прогноз врёт. Замена - webhook из Digital Pipeline на смене стадии, который вызывает ваш сервис, проверяет состояние ролей и решает, пускать ли сделку дальше.

Здесь важны лимиты, которые отличают Digital Pipeline от общих webhook (по состоянию на Q2 2026, по документации Kommo):

Сервис ждёт ответ от вашего эндпоинта в течение 2 секунд. Не уложились или код ответа вне 100-299 - webhook считается недоставленным.
В Digital Pipeline webhook отправляется один раз на событие, без повторов. Это критично: вся тяжёлая логика должна уйти в фоновую очередь, а эндпоинт обязан мгновенно вернуть 200.
У общих webhook (не DP) логика мягче - до 4 повторных попыток в течение часа.
При более чем 100 невалидных ответах с адреса за 5 минут доставка на него приостанавливается на 5 минут.
Работа с webhook через API доступна на тарифах Advanced, Pro и Enterprise.

Правильная архитектура: эндпоинт принимает webhook, кладёт задачу в очередь, отвечает 200 за миллисекунды. Воркер проверяет роли и через PATCH /api/v4/leads/{id} либо двигает сделку, либо ставит задачу менеджеру «юрист не подтвердил».

Отчётность поверх структурированных данных

Когда роли и состояния лежат в кастомных полях, а не в заметках, появляется отчётность, которой нет в нативном интерфейсе: распределение сделок по стадии закупки, средний срок прохождения юридической проверки, доля сделок без идентифицированного ЛПР. Данные тянутся через GET /api/v4/leads с фильтрами и with=contacts, выгружаются в BI и закрывают вопрос борда о прогнозе.

Пошаговый план

Порядок внедрения B2B pipeline в Kommo через API выглядит так:

Опишите процесс закупки, а не действия менеджеров. Зафиксируйте стадии от квалификации ЛПР до подписания. Это определит statuses воронки.
Создайте кастомные поля ролей на контакте через POST /api/v4/contacts/custom_fields. Минимум - select «Роль в закупке».
Решите, нужен ли объект-обход. Если на сделке стабильно 4+ стейкхолдера с собственным жизненным циклом - заведите каталог «Стейкхолдеры».
Настройте приём лидов через /api/v4/leads/complex с дедупликацией контактов по email или телефону до создания.
Повесьте webhook на ключевые смены стадий в Digital Pipeline. Эндпоинт отвечает 200 мгновенно, логика - в фоновой очереди.
Реализуйте условные переходы в воркере: проверка состояния ролей перед PATCH сделки.
Выгрузите данные в BI через GET /api/v4/leads. Дайте head of sales дашборд по стадиям закупки.

Реальный кейс с цифрами

В типовом проекте Exceltic.dev для SaaS-команды из 22 человек на Kommo Pro воронка держала ~45 активных B2B-сделок со средним чеком около $35k и циклом 7-9 недель. До доработки роли стейкхолдеров жили в заметках, и прогноз борда расходился с фактом на 30-40% квартал к кварталу.

Что сделали: select-поле «Роль в закупке» на контакте, каталог «Стейкхолдеры» с полем «статус согласования», приём лидов через complex с дедупликацией, и webhook на переход в стадию «Юридическая проверка», который блокировал движение дальше, пока статус юриста не «approved».

Результат за квартал: доля сделок с идентифицированным ЛПР выросла с 55% до 94%, точность прогноза - расхождение упало с ~35% до ~12%. Менеджеры перестали вести параллельную таблицу в Sheets - около 4 часов в неделю на человека вернулись в продажи. Объём разработки - порядка двух недель.

Когда это оправдано, а когда пора на HubSpot

Достройка B2B pipeline через API в Kommo оправдана, когда сложность в процессе, а не в объёме данных. Если у вас несколько стейкхолдеров на сделку, нелинейный цикл и потребность в условных переходах - это решаемо на API Kommo, и обойдётся дешевле миграции.

Когда оставаться на Kommo и достраивать через API:

20-150 активных B2B-сделок, цикл до 3 месяцев.
Нужны роли, условные переходы, нормальная отчётность - но не сложный многообъектный data model.
Команда ценит мессенджеры и скорость настройки Kommo.

Когда пора смотреть на HubSpot:

Нужна нативная многообъектная модель (Deals - Companies - Contacts - Tickets - Custom Objects) со связями из коробки.
Multi-touch attribution и сложный revenue reporting на уровне платформы.
Воронка - десятки тысяч сделок, где объект-обходы через каталоги станут техдолгом.

Чем структурно различаются модели данных двух систем и почему это решающий фактор выбора - в разборе Kommo против HubSpot.

Часто задаваемые вопросы

Можно ли в Kommo привязать к сделке несколько контактов с разными ролями?

Да. Kommo нативно поддерживает привязку нескольких контактов и одной компании к сделке - в том числе пакетно через POST /api/v4/leads/complex. Но роль контакта в закупке нативно не хранится: «основной контакт» есть, а «технический евангелист» или «блокер» - нет. Роль добавляется кастомным select-полем на контакте через POST /api/v4/contacts/custom_fields. Для сложных сценариев с собственным жизненным циклом стейкхолдера используют каталог как объект-обход. После этого по ролям можно строить фильтры и отчётность через GET /api/v4/leads с with=contacts.

Чем webhook в Digital Pipeline отличается от обычного webhook Kommo?

Главных отличий два. Первое - в Digital Pipeline webhook отправляется один раз на событие, без повторных попыток, тогда как у общих webhook до 4 ретраев в течение часа. Второе - ваш эндпоинт обязан ответить в пределах 2 секунд кодом 100-299, иначе событие считается недоставленным и в DP теряется навсегда. Поэтому тяжёлую логику выносят в фоновую очередь, а эндпоинт отвечает 200 мгновенно. Кроме того, при более чем 100 невалидных ответах с адреса за 5 минут Kommo приостанавливает доставку на 5 минут. Работа с webhook через API доступна на тарифах Advanced, Pro и Enterprise.

Нужно ли программирование или хватит Digital Pipeline и Salesbot?

Для линейной воронки хватает Digital Pipeline и Salesbot без кода. Полноценный B2B pipeline с ролями и условными переходами требует кода: условие «не пускать сделку дальше, пока юрист не подтвердил» нативный Digital Pipeline не выражает - он триггерит на смену стадии, но не проверяет состояние нескольких контактов. Поэтому ключевые переходы заворачиваются на ваш сервис через webhook, который проверяет роли и двигает сделку через PATCH /api/v4/leads/{id}. Это не полноценная разработка с нуля - в типовом проекте порядка двух недель.

Как избежать дублей контактов при приёме лидов через API?

Дедупликацией до записи. Kommo не дедуплицирует автоматически при создании через /api/v4/leads/complex - повторная отправка формы создаст второй контакт. Перед вызовом complex делается GET /api/v4/contacts?query= по email или телефону, и по результату система решает: создавать новый контакт или обновлять существующий через PATCH. Это и есть идемпотентность приёма лидов. Без неё база за полгода зарастает дублями, и отчётность по ролям перестаёт быть достоверной.

Итог

Полноценный B2B pipeline в Kommo через API - это реально, если сложность у вас в процессе, а не в десятках тысяч записей.

Роли стейкхолдеров - кастомные поля на контакте или каталог как объект-обход; приём лидов - через /api/v4/leads/complex с дедупликацией.
Условные переходы - webhook из Digital Pipeline на ваш сервис; помните про лимит 2 секунды и единичную доставку без ретраев.
Отчётность по стадиям закупки - выгрузка через GET /api/v4/leads в BI, чтобы прогноз сходился с фактом.
Если нужна нативная многообъектная модель и сложный revenue reporting - это сигнал смотреть на HubSpot.

Если вы упёрлись в стандартную воронку Kommo на сложном B2B-цикле - опишите задаче команде Exceltic.dev ваш процесс закупки и текущий объём сделок. Разберём архитектуру полей и webhook-логики и оценим объём работ.

Полноценный B2B pipeline в Kommo через API