Kommo + Calendly: встреча автоматически в сделку

Чтобы встреча из Calendly появилась в карточке сделки Kommo, достаточно настроить webhook на стороне Calendly и небольшой сервис-обработчик. При бронировании Calendly отправляет событие invitee.created с email, именем приглашённого, датой, временем и ссылкой на встречу. Сервис ищет контакт в Kommo по email, находит связанную сделку и создаёт задачу или примечание с полными деталями. При отмене приходит invitee.canceled - сервис снимает или закрывает задачу.

Нативный виджет Calendly в Kommo умеет одно: создать новый лид во входящих при первом бронировании. Это работает для входящего трафика. Но когда менеджер сам отправляет ссылку Calendly существующему клиенту - виджет об этом не знает. Встреча состоялась, контакт открыт, сделка движется по воронке - и никакого следа в CRM. Коллега смотрит на карточку и не понимает, был ли разговор.

Эта статья разбирает, как именно работает кастомная интеграция через Calendly Webhook API и Kommo REST API: какие поля приходят, как искать сделку и что писать в карточку.

Где заканчивается нативный виджет

Нативная интеграция Calendly в Kommo работает через Digital Pipeline: при новом бронировании создаётся входящий лид с задачей-встречей. По состоянию на Q2 2026 это единственный сценарий, который покрывает виджет.

Три ситуации, которые виджет не обрабатывает:

• Менеджер берёт ссылку Calendly из своего профиля и отправляет её контакту, который уже есть в CRM. Бронирование происходит, но привязки к существующей сделке нет.
• Клиент отменяет встречу. В карточке сделки об этом ничего нет - менеджер узнаёт только если проверяет почту.
• Встреча переносится. Calendly сначала отправляет invitee.canceled со флагом rescheduled: true, затем invitee.created с новым временем. Виджет создаёт дублирующий лид вместо обновления существующей задачи.

Кроме того, виджет требует платный план Kommo и платный план Calendly - бесплатные аккаунты не поддерживаются. Это дополнительное ограничение для небольших команд.

Webhook - это HTTP-запрос, который Calendly отправляет на ваш сервер в момент события: бронирования, отмены или переноса.

Что реализуется через кастомную интеграцию

Кастомная интеграция закрывает все сценарии, которые нативный виджет не покрывает. Логика строится на двух событиях Calendly и двух операциях Kommo API.

Webhook invitee.created -> поиск контакта -> задача в сделке

Когда кто-то бронирует встречу через Calendly, платформа отправляет POST-запрос на ваш сервер. Тело запроса содержит:

{
  "event": "invitee.created",
  "payload": {
    "email": "[email protected]",
    "name": "Ivan Petrov",
    "event_type": {
      "name": "30 Minute Meeting"
    },
    "calendar_event": {
      "start_time": "2026-07-10T14:00:00Z",
      "end_time": "2026-07-10T14:30:00Z"
    },
    "event": {
      "uri": "https://api.calendly.com/scheduled_events/ABCDEF123456",
      "location": {
        "type": "zoom",
        "join_url": "https://zoom.us/j/123456789"
      }
    },
    "questions_and_answers": []
  }
}

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

Сервис-обработчик делает следующее:

1. Извлекает payload.email из тела запроса.
2. Ищет контакт в Kommo через GET /api/v4/contacts?query={email}.
3. Если контакт найден - находит его открытые сделки через GET /api/v4/leads?contact_id={id}.
4. В сделке создаёт примечание через POST /api/v4/leads/{id}/notes с типом common и текстом: дата, время, ссылка на встречу, имя участника.
5. Опционально создаёт задачу через POST /api/v4/tasks с полями entity_id, entity_type: leads, task_type_id: 2 (встреча), complete_till равным времени начала встречи.
6. Если контакт не найден - создаёт входящий лид, как делает нативный виджет.

Полная документация Kommo API для задач и примечаний - на developers.kommo.com.

Отмена встречи - webhook invitee.canceled

При отмене Calendly отправляет invitee.canceled. Поле payload.canceled содержит причину отмены, поле payload.rescheduled указывает, является ли это переносом (true) или реальной отменой (false).

Сервис-обработчик:

• При rescheduled: false - добавляет примечание в сделку: «Встреча отменена. Причина: {payload.canceled.reason}». Задачу помечает как выполненную или удаляет.
• При rescheduled: true - ждёт следующего invitee.created с обновлёнными данными и обновляет задачу.

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

Пошаговая схема интеграции

Вот как выглядит процесс от бронирования до записи в Kommo.

Шаг 1 - Регистрация webhook в Calendly

Через Calendly API (или в настройках аккаунта) регистрируется webhook subscription на два события: invitee.created и invitee.canceled. Указывается URL вашего сервиса-обработчика. Calendly поддерживает проверку подлинности через подпись запроса - это важно подключить сразу, чтобы исключить поддельные запросы.

Шаг 2 - Сервис получает событие и парсит payload

Сервер принимает POST, проверяет подпись, извлекает event, payload.email, payload.name, payload.calendar_event.start_time, payload.event.location.join_url.

Шаг 3 - Поиск контакта в Kommo

Запрос к Kommo API: GET /api/v4/contacts?query={email}. Если возвращается один или несколько контактов - берём первый совпадающий по email.

Шаг 4 - Поиск активной сделки

По contact_id получаем список сделок: GET /api/v4/leads?contact_id={id}&filter[statuses][]=0 (статус 0 = активные). Если несколько - берём последнюю по дате изменения.

Шаг 5 - Создание записи в сделке

В сделку пишется примечание с датой, временем, ссылкой на встречу (Zoom, Google Meet или телефон - в зависимости от location.type). Параллельно создаётся задача с типом «Встреча» и дедлайном равным start_time.

Шаг 6 - Обработка отмены

При invitee.canceled сервис находит задачу по совпадению complete_till и entity_id, закрывает её или добавляет примечание об отмене.

Шаг 7 - Идемпотентность

Чтобы при повторной доставке webhook не создавались дублирующие задачи, сервис хранит event.uri из payload как уникальный идентификатор и проверяет его перед созданием.

Реальный кейс

Один из проектов Exceltic.dev - команда B2B-продаж из 8 менеджеров, которые работали с Kommo и активно использовали Calendly для назначения демо. Проблема выглядела так: менеджер отправлял ссылку через LinkedIn, клиент бронировал слот - и встреча исчезала из поля зрения CRM. Руководитель отдела продаж не мог понять из воронки, были ли запланированы демо по конкретным сделкам или нет.

На этапе ревью воронки выяснилось: около 30% запланированных демо не отражались в Kommo. Менеджеры вели заметки в голове или в личном календаре.

После интеграции через Calendly webhook + Kommo API:

• Каждая встреча автоматически появляется как задача в соответствующей сделке в течение нескольких секунд после бронирования.
• Отмены фиксируются примечанием - руководитель видит, когда и почему встреча не состоялась.
• Время на ручное занесение встреч в CRM сократилось до нуля.
• Видимость воронки для head of sales выросла: теперь понятно, по каким сделкам есть запланированный контакт, а по каким - нет.

Внедрение заняло около двух недель: неделя на разработку сервиса-обработчика и тестирование, неделя на стабилизацию и edge cases (переносы, несколько активных сделок у одного контакта).

Для кого это решение

Интеграция через webhook актуальна для команд, у которых одновременно выполняются три условия. Во-первых, менеджеры активно используют Calendly и отправляют ссылки существующим клиентам из CRM - а не только встраивают виджет на сайт для входящих. Во-вторых, важна прозрачность воронки: руководитель или team lead должен видеть, на каком этапе каждой сделки запланирован следующий контакт. В-третьих, команда уже столкнулась с ситуацией, когда встречи теряются или отмены не фиксируются.

Если вы строите кастомные интеграции для Kommo или хотите понять, что вообще умеет платформа на уровне API, посмотрите обзор Kommo CRM - там разобрана модель данных и ограничения нативных инструментов.

Типичный профиль: B2B-команда от 5 менеджеров, цикл сделки от 2 недель, Calendly используется для демо и онбординга. Zapier или Make не подходят из-за latency (задержка до нескольких минут) и ограничений по кастомной логике поиска контактов.

Термин: Idempotency key - уникальный идентификатор операции, который позволяет повторно обработать webhook без создания дублей. В данной интеграции роль такого ключа играет event.uri из Calendly payload.

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

Что если у одного контакта в Kommo несколько открытых сделок?

Это один из edge cases, который нужно явно обрабатывать в логике сервиса. Простой вариант - создавать задачу в самой последней по дате изменения сделке и одновременно писать примечание во все активные сделки контакта. Более сложный вариант - при регистрации на встречу Calendly позволяет задавать кастомные вопросы (поле questions_and_answers в payload). Можно добавить поле «ID сделки» и использовать его для прямой привязки. Это требует договорённости с менеджерами, но устраняет неопределённость полностью.

Нужен ли платный план Calendly для webhook?

Да. Webhook subscriptions в Calendly доступны только на платных планах - Standard и выше. На бесплатном плане Calendly webhooks недоступны. Это нужно учитывать при планировании интеграции: если команда использует бесплатный Calendly, сначала потребуется апгрейд.

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

При переносе Calendly отправляет два события подряд: invitee.canceled с payload.rescheduled: true и затем invitee.created с новыми данными. Сервис должен при получении invitee.canceled с флагом rescheduled: true не закрывать задачу, а пометить её как «ожидает обновления». При следующем invitee.created - обновить complete_till и текст задачи. Уникальный идентификатор встречи (event.uri) меняется при переносе, поэтому привязку нужно хранить по паре contact_id + старый event.uri.

Можно ли использовать Zapier вместо кастомного сервиса?

Технически Zapier умеет слушать Calendly webhook и делать запросы в Kommo. На практике возникают два ограничения. Первое - latency: Zapier обрабатывает события не в реальном времени, а с задержкой до нескольких минут на старших планах и дольше на базовых. Второе - логика поиска: поиск контакта по email, получение его сделок, выбор нужной по критериям и создание задачи с идемпотентностью - это многошаговая логика, которую сложно и дорого реализовать в Zapier без кастомного кода. Для простых сценариев (только входящие, один контакт - одна сделка) Zapier может быть достаточным. Для production B2B-команды с историческими контактами - нет.

Как понять, что интеграция работает корректно?

Минимальный набор проверок после запуска: забронировать тестовую встречу через Calendly и убедиться, что в сделке появилась задача с правильным временем и ссылкой. Отменить встречу - проверить, что в карточке появилось примечание об отмене. Перенести встречу - убедиться, что задача обновилась, а не создалась дополнительная. Настройте алертинг на случай, если сервис получил webhook, но не смог найти контакт - это полезная метрика для выявления пробелов в базе CRM.

Если у вас менеджеры используют Calendly для работы с существующими клиентами и встречи не попадают в Kommo - это типовая задача. Опишите ваш стек (как настроена воронка, сколько менеджеров, какие типы встреч) команде Exceltic.dev. Разберём архитектуру и оценим объём работ.

Посмотрите также, как мы настраивали воронку Kommo - понимание структуры pipeline помогает правильно решить, в какую сделку и на каком этапе должна попадать встреча. А если вас интересует синхронизация данных Kommo с внешними таблицами, посмотрите на интеграцию Kommo и Google Sheets - похожая логика поиска и обновления записей.