Уведомления из Битрикс24 в Telegram через входящий вебхук

Уведомления из Битрикс24 в Telegram беру на вооружение почти в каждом проекте, где менеджеры теряют заявки в общей ленте CRM. Тут не нужен маркетплейс интеграций, хватает исходящего вебхука на событие, входящего вебхука для REST-запроса за деталями и бота в Telegram, который получает готовое сообщение. Ниже схема, которую я собираю клиентам на практике: от создания вебхука до бота, присылающего карточку сделки в чат отдела продаж через пару секунд после звонка или письма.

Как работает связка вебхуков между Битрикс24 и Telegram

Битрикс24 умеет сообщать о событиях наружу через исходящий вебхук: при создании лида, изменении стадии сделки или новом звонке портал делает POST-запрос на указанный вами адрес. Проблема в том, что в этом запросе приходит только код события и ID сущности, без названия сделки, суммы и ответственного менеджера. Чтобы собрать нормальное сообщение для Telegram, нужно вторым шагом сходить в Битрикс24 за деталями, и вот тут пригождается входящий вебхук: он даёт URL, через который любой скрипт может вызвать методы REST API вроде crm.deal.get.

Схема получается в три шага. Событие в CRM триггерит исходящий вебхук на ваш обработчик. Обработчик через входящий вебхук запрашивает у Битрикс24 полную карточку объекта. Готовый текст отправляется в Telegram через Bot API методом sendMessage. Обработчиком может быть нода в n8n, скрипт на Flask или бот на aiogram, разница только в том, где живёт эта логика.

Настраиваю исходящий вебхук в Битрикс24

В облачном Битрикс24 иду в раздел «Разработчикам», выбираю «Другое» и создаю исходящий вебхук. В коробочной версии тот же функционал находится в модуле «Вебхуки» административной панели. При создании указываю:

• событие, на которое реагирую: ONCRMDEALADD для новой сделки, ONCRMLEADADD для лида, ONCRMDEALUPDATE для смены стадии;
• URL обработчика, куда Битрикс24 будет слать POST-запрос: адрес ноды n8n или эндпоинт своего сервера;
• область действия (для сделок и лидов достаточно scope crm).

Важный момент: адрес обработчика обязан работать по HTTPS с валидным сертификатом, иначе Битрикс24 просто не примет вебхук при сохранении. Для теста создаю тестовую сделку и смотрю в логах обработчика, дошёл ли запрос и какие поля реально пришли, обычно это ID, тип события и таймстамп, не больше.

Забираю данные по сделке через входящий вебхук

Входящий вебхук настраивается там же, в «Разработчикам» → «Другое» → «Входящий вебхук». Выбираю права crm (чтение сделок, лидов, пользователей) и получаю URL вида https://ваш-портал.bitrix24.ru/rest/1/xxxxxxxxxxxxxxxx/. По этому адресу можно вызывать любой метод REST API простым GET или POST запросом, без OAuth и обновления токенов, что для внутренней автоматизации обычно достаточно.

Получив ID сделки из исходящего вебхука, забираю карточку и данные ответственного:

import requests

WEBHOOK = "https://ваш-портал.bitrix24.ru/rest/1/xxxxxxxxxxxxxxxx"

def get_deal(deal_id: int) -> dict:
    resp = requests.get(f"{WEBHOOK}/crm.deal.get", params={"id": deal_id})
    deal = resp.json()["result"]

    manager = requests.get(
        f"{WEBHOOK}/user.get", params={"ID": deal["ASSIGNED_BY_ID"]}
    ).json()["result"][0]

    return {
        "title": deal["TITLE"],
        "sum": deal["OPPORTUNITY"],
        "currency": deal["CURRENCY_ID"],
        "manager": f'{manager["NAME"]} {manager["LAST_NAME"]}',
    }

Такой подход даёт гибкость: можно так же подтянуть телефон клиента через crm.contact.get или историю звонков через telephony.externalcall.searchcrmentities, если нужно уведомлять не только о сделках, но и о пропущенных вызовах.

Отправляю сообщение в Telegram-бота

Бота создаю через @BotFather, получаю токен и добавляю бота в нужную группу или канал отдела продаж. У супергрупп chat_id начинается с ‑100, обычная проверка через getUpdates после любого сообщения в чат покажет правильное значение. Дальше отправка укладывается в один запрос:

import requests

BOT_TOKEN = "123456:AA..."
CHAT_ID = "-1001234567890"

def notify(deal: dict):
    text = (
        f"Новая сделка: {deal['title']}n"
        f"Сумма: {deal['sum']} {deal['currency']}n"
        f"Менеджер: {deal['manager']}"
    )
    requests.post(
        f"https://api.telegram.org/bot{BOT_TOKEN}/sendMessage",
        json={"chat_id": CHAT_ID, "text": text, "parse_mode": "HTML"},
    )

Один нюанс, о который спотыкаются почти все: Битрикс24 ждёт ответ от обработчика около 5 секунд, и если он не получит его вовремя, повторит запрос через какое-то время, из-за чего уведомление прилетает в Telegram дважды. Поэтому тяжёлую логику (запись в базу, повторные попытки) лучше выносить в очередь, а обработчику сразу отдавать 200 OK.

n8n или свой обработчик: что выбираю в проектах

Сценарий в n8n

Для клиентов, где нужна одна-две интеграции без сложных условий, собираю сценарий в n8n за час-два: нода Webhook принимает вызов от исходящего вебхука Битрикс24, нода HTTP Request дергает crm.deal.get через входящий вебхук, нода Telegram отправляет готовый текст. Плюс в том, что вся логика видна на холсте, и правки вносит даже человек без опыта в Python. Минус в том, что n8n нужно где-то хостить: либо своя облачная подписка, либо сервер под self-hosted версию, и при сложной ветвящейся логике сценарий превращается в кашу из десятков нод.

Обработчик на Python (Flask или FastAPI с aiogram)

Когда уведомления нужно фильтровать по сумме сделки, распределять по разным чатам в зависимости от отдела или сохранять историю в свою базу для отчётов, пишу отдельный сервис на FastAPI, а отправку в Telegram оформляю через aiogram, благо у него уже есть все методы Bot API и удобная работа с клавиатурами, если позже понадобятся кнопки под уведомлением («взять в работу», «перезвонить позже»). Такой сервис проще тестировать юнит-тестами и проще версионировать в git, чем экспортированный JSON сценария n8n. Если нужна именно такая маршрутизация уведомлений по нескольким отделам, обычно беру разработку Telegram-бота с интеграцией в CRM отдельным блоком работ.

Типичные ошибки при настройке уведомлений

• chat_id для группы указан без префикса ‑100, из-за чего бот пишет в личку вместо чата или получает ошибку chat not found;
• бота добавили в группу, но не дали право писать сообщения (в настройках группы отключена отправка от ботов);
• исходящий вебхук подписан сразу на все события ONCRMDEALUPDATE без фильтра по стадии, и чат заваливает уведомлениями на каждое микроизменение сделки;
• обработчик отвечает Битрикс24 дольше 5 секунд из-за синхронного похода в базу или внешний API, что приводит к повторным запросам и дублям сообщений;
• токен бота или URL входящего вебхука лежит прямо в коде репозитория, а не в переменных окружения.

Отдельно про хранение данных клиентов: если обработчик параллельно сохраняет телефоны и имена из карточек Битрикс24 для отчётов, база должна стоять на сервере в России, а не в стороннем облачном таблице за рубежом, это требование 152-ФЗ по локализации персональных данных, и на аудитах я его всегда проверяю в первую очередь.

Частые вопросы

Нужен ли отдельный сервер для приёма вебхука от Битрикс24?

Если собираете сценарий в n8n, достаточно облачной подписки n8n или self-hosted версии на недорогом VPS. Для своего сервиса на Flask или FastAPI тоже хватает небольшого VPS с HTTPS, тяжёлых мощностей эта задача не требует.

Можно ли слать уведомления в личные сообщения, а не в общую группу?

Да, для этого получателю нужно один раз написать боту любое сообщение (Telegram не разрешает ботам писать первыми), после чего его chat_id можно использовать в sendMessage наравне с chat_id группы.

Сколько стоит настройка уведомлений из Битрикс24 в Telegram?

Простая связка через n8n на одно-два события у меня стоит от 25 000 ₽, кастомный бот с фильтрами по отделам и своей базой уведомлений от 30 000 ₽. Точная оценка зависит от количества событий и логики фильтрации, для этого делаю отдельную консультацию от 3 000 ₽.

Что делать, если Битрикс24 не вызывает исходящий вебхук?

Первым делом проверяю, что обработчик отвечает по HTTPS с действительным сертификатом, не самоподписанным, и что событие в настройках вебхука совпадает с реальным (например ONCRMDEALUPDATE срабатывает не на любое изменение, а конкретно на смену стадии). Дальше смотрю логи веб-сервера: если запрос вообще не приходит, дело в блокировке на файрволе или неверном адресе обработчика.