Kommo + Apollo.io: синхронизация лидов из outbound-проспектинга в CRM без Zapier

Kommo + Apollo.io интеграция синхронизации лидов строится на прямом API-соединении: webhook от Apollo передаёт контакт в Kommo в момент добавления в последовательность, без Zapier и без ручного переноса. Дедупликация по email и Apollo ID исключает создание дублей даже при параллельной работе нескольких SDR. Обратная связь тоже есть - при закрытии сделки в Kommo статус контакта в Apollo обновляется автоматически.

SDR-команды, которые ведут проспектинг в Apollo.io и сделки в Kommo, теряют от 2 до 6 часов в день на ручной перенос данных. Контакт ответил на письмо - его надо найти в Apollo, скопировать данные, создать сделку в CRM. При работе нескольких человек по пересекающимся базам - ещё и разобраться с дублями. Кастомные интеграции под Kommo решают эту задачу на уровне API, без посредников и без ручных шагов.

Почему Apollo.io не интегрируется с Kommo нативно

По состоянию на Q2 2026, в списке нативных CRM Apollo.io есть HubSpot, Salesforce, Pipedrive и Outreach. Kommo там нет. Это архитектурное решение Apollo: компания фокусируется на ENT-сегменте и популярных западных CRM.

Доступные варианты без кастомной разработки:

• CSV-экспорт/импорт. Работает при объёме до 20-30 контактов в день. Выше - ежедневная ручная рутина.
• Zapier или Albato. Polling-модель: данные из Apollo передаются с задержкой 5-15 минут, зависит от плана. При сбое посредника - данные теряются без уведомления. При объёме 50+ лидов в день стоимость Zapier превышает стоимость кастомного решения за 3-4 месяца.

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

Для команд от 5 SDR с объёмом от 50 контактов в день ни один из перечисленных вариантов не даёт приемлемого результата по скорости и надёжности.

Kommo + Apollo.io интеграция: архитектура синхронизации лидов

Интеграция состоит из двух каналов передачи данных - из Apollo в Kommo и обратно.

Канал 1: Apollo.io -> Kommo

Apollo.io поддерживает webhook-уведомления на ключевые события контакта. Для синхронизации лидов используются три события:

• contact_added_to_sequence - контакт добавлен в outbound-последовательность
• reply_detected - контакт ответил на письмо из последовательности
• contact_stage_changed - изменилась стадия контакта в Apollo

Каждое событие отправляет POST-запрос на middleware с полным payload контакта. Middleware проверяет дублирование, создаёт или обновляет запись в Kommo.

Канал 2: Kommo -> Apollo.io

Webhook Kommo срабатывает при смене статуса сделки. При переходе в «Выиграна» или «Проиграна» middleware отправляет PATCH в Apollo API и обновляет стадию контакта - SDR видит актуальный статус без необходимости переключаться в CRM.

Технические детали

Apollo.io API v1 (документация Apollo) работает по REST, аутентификация через заголовок x-api-key. Ключевые эндпоинты для интеграции:

GET  https://api.apollo.io/v1/contacts/search - поиск контакта по email
POST https://api.apollo.io/v1/contacts        - создание контакта
POST https://api.apollo.io/v1/people/enrich   - обогащение данных о персоне

Kommo API v4 (документация Kommo) работает по OAuth 2.0. Ключевые эндпоинты:

GET  /api/v4/contacts?query={email}  - поиск дубля по email
POST /api/v4/contacts                - создание контакта
POST /api/v4/leads                   - создание сделки
PATCH /api/v4/contacts/{id}          - обновление существующего контакта

Маппинг полей Apollo -> Kommo:

Поле Apollo ID - ключ идемпотентности. Перед созданием записи middleware проверяет: есть ли в Kommo контакт с этим Apollo ID в кастомном поле. Если есть - обновляет, не создаёт дубль. Это работает даже когда два SDR одновременно добавляют один и тот же контакт в разные последовательности.

Как работает синхронизация лидов пошагово

1. SDR добавляет проспект в последовательность Apollo.io
2. Apollo отправляет webhook contact_added_to_sequence на middleware в течение 1-3 секунд
3. Middleware извлекает email из payload, делает GET /api/v4/contacts?query={email} в Kommo
4. Если контакт не найден - создаётся новый контакт (POST /api/v4/contacts) и сделка в целевой воронке (POST /api/v4/leads)
5. Если контакт найден - обновляется существующая запись (PATCH), добавляется заметка «Добавлен в последовательность Apollo: {sequence_name}»
6. Apollo ID записывается в кастомное поле Kommo для всех последующих обновлений

При ответе проспекта на письмо (событие reply_detected):

7. Middleware получает webhook, находит сделку в Kommo по Apollo ID
8. Переводит сделку на следующий этап воронки - например, из «Outbound» в «Квалификация»
9. Добавляет заметку с датой и фактом ответа (или текстом письма, если Apollo передаёт тело)

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

Реальный кейс: SDR-команда из 8 человек

Компания - международный B2B SaaS, команда продаж в Европе. До интеграции: 8 SDR, каждый работает в Apollo со своим списком, лиды в Kommo создаются вручную в конце рабочего дня. Средняя задержка между ответом проспекта и появлением сделки в CRM - 4-6 часов. Менеджеры видели «горячие» контакты с опозданием.

Результаты после запуска кастомной интеграции (первые 30 дней):

• Задержка передачи контакта из Apollo в Kommo - 30-60 секунд
• Дублей при параллельной работе SDR - 0 (дедупликация по email + Apollo ID)
• Ручной перенос данных полностью исключён
• Передано уникальных контактов за месяц - 1 400

Разработка и запуск: 3 недели. Из них - 1 неделя на аудит воронки и маппинг полей, 2 недели на разработку middleware и тестирование. Аналогичная событийная архитектура применяется в интеграции Kommo + ActiveCampaign - там тоже webhook-модель вместо polling для синхронизации контактов.

Для кого подходит

Интеграция актуальна при одновременном выполнении трёх условий:

• Есть выделенная SDR-команда от 3 человек, которая работает в Apollo.io и ведёт outbound-проспектинг по базам
• Kommo - основная CRM для сделок и коммуникации с клиентами
• Объём новых контактов из Apollo превышает 30-50 в день (при меньшем объёме достаточно ручного процесса или ежедневного CSV-экспорта)

Не подходит, если Apollo.io используется только для обогащения данных (People Enrichment API), а не для запуска последовательностей. Такой сценарий требует другой архитектуры - через enrich API, не через event webhooks.

По аналогии с кастомной интеграцией Kommo + ClickUp без Zapier, кастомное решение даёт полный контроль: что именно создаёт запись в CRM, какие поля передаются, что происходит при ошибке сети.

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

Есть ли готовая Kommo Apollo.io интеграция синхронизации лидов без разработки?

По состоянию на Q2 2026 - нет. Apollo.io не поддерживает Kommo в списке нативных CRM-интеграций. Albato и Zapier позволяют настроить базовую передачу данных, но работают по polling-модели с задержкой 5-15 минут. При сбое посредника данные теряются без уведомления. Для команд с объёмом от 30 лидов в день polling-интеграция создаёт больше проблем, чем решает: дубли, пропущенные контакты, непрозрачные ошибки.

Как работает дедупликация при синхронизации Apollo и Kommo?

Middleware проверяет два ключа: email и Apollo ID. При входящем webhook сначала делается запрос GET /api/v4/contacts?query={email} в Kommo. Если найден - контакт обновляется, а не создаётся заново. Apollo ID сохраняется в кастомном поле Kommo и служит ключом для всех последующих обновлений этого контакта. При параллельной работе двух SDR с одним проспектом - оба webhook обрабатываются корректно: первый создаёт запись, второй обновляет её.

Какие события Apollo.io можно использовать для триггеров в Kommo?

Стандартно используются три события: contact_added_to_sequence (добавление в последовательность), reply_detected (ответ на письмо), contact_stage_changed (изменение стадии в Apollo). При необходимости подключаются email_opened, email_clicked и meeting_booked - в зависимости от того, какие действия проспекта должны менять статус сделки в Kommo.

Что делать если Apollo API возвращает ошибку при высокой нагрузке?

Apollo.io API имеет rate limits: на базовом тарифе - около 10 запросов в минуту для эндпоинтов поиска и обогащения. При пиковой нагрузке middleware реализует exponential backoff: первая повторная попытка через 2 секунды, вторая через 4, третья через 8. Если все попытки исчерпаны - событие помещается в очередь для последующей обработки. Данные не теряются, только задерживаются.

Сколько занимает разработка интеграции Kommo + Apollo.io?

В типовом проекте - 2-3 недели. Первая неделя: аудит воронки Kommo, структура последовательностей Apollo, согласование маппинга полей и логики переходов между этапами. Вторая неделя: разработка middleware, настройка webhooks с обеих сторон, тестирование на реальных данных. Третья неделя (при необходимости): нагрузочное тестирование и запуск на боевых данных с мониторингом первых 500-1000 контактов.

Если SDR-команда работает в Apollo.io, а воронка ведётся в Kommo - опишите задачу команде Exceltic.dev: текущий объём контактов в день, размер команды, что не устроило в текущем процессе. Разберём архитектуру синхронизации и оценим объём работ.