Битрикс24 интеграция с Тильдой: как передавать заявки без потерь

Битрикс24 интеграция с Тильдой у большинства студий держится на одном чекбоксе в настройках сайта: подключить CRM-коннектор и забыть про него. Для лендинга с одной формой этого хватает с запасом. Но как только в проекте появляется несколько форм, промокоды, доставка через СДЭК или лимит на количество открытых лидов в тарифе Битрикс24, часть заявок начинает пропадать или дублироваться, и клиент узнаёт об этом от менеджера, а не от системы. Ниже разбираю оба сценария: типовой коннектор и ручную настройку через вебхуки, когда типового варианта уже не хватает.

Как обычно передают заявки: коннектор Тильды и Битрикс24

Нативная интеграция подключается в настройках сайта: раздел «Настройки сайта» - вкладка CRM - Битрикс24. Тильда просит авторизоваться в вашем портале и выдаёт доступ приложению «Тильда» в списке разработанных приложений Битрикс24. После привязки формы на странице отмечаются галочкой «Отправлять в CRM», и при отправке создаётся лид или сделка.

На практике у этого способа три ограничения. Коннектор передаёт базовый набор полей: имя, телефон, email и текст комментария, собранный из остальных полей формы одной строкой. Для интернет-магазина на Tilda товарные позиции с ценами и количеством в заказе он передаёт общей суммой, без построчной раскладки, которую можно было бы отфильтровать в сделке. И самое частое: скрытые поля формы (UTM-метки, ID промокода, номер заказа из корзины) долетают до Битрикс24 не всегда, если не включена галочка «Разрешить скрытые поля» в настройках самой формы, а искать причину пропажи данных приходится постфактум, когда отдел продаж уже жалуется на пустые карточки.

Битрикс24 интеграция с Тильдой через вебхуки: пошаговая настройка

Когда нужны кастомные поля, товарные позиции или логика вроде «заявку с суммой больше 50 000 ₽ ставить на конкретного менеджера», коннектор не подходит и я перехожу на вебхуки.

• В Битрикс24 создаю входящий вебхук: раздел «Разработчикам» - «Другое» - «Входящий вебхук», выдаю права на модуль CRM (crm).
• В форме Тильды в блоке «Настройки формы» - «Уведомления» указываю адрес своего обработчика как webhook-получателя. Тильда отправляет POST-запрос с данными формы при каждой отправке.
• На сервере обработчик принимает запрос, приводит телефон к единому формату, сверяет обязательные поля и вызывает метод crm.lead.add или crm.deal.add через REST API Битрикс24.
• Ответ от Битрикс24 логирую в отдельную таблицу или файл, чтобы при сбое видеть, какая заявка не дошла, а не узнавать об этом от клиента.

Простой обработчик на PHP выглядит так (crm.lead.add в документации помечен DEPRECATED, замена crm.item.add с entityTypeId 1 и полями в camelCase, старый вызов пока доступен):

<?php
$data = $_POST;
$webhook = 'https://ваш-портал.bitrix24.ru/rest/1/xxxxxxxx/crm.lead.add.json';

$fields = [
    'TITLE' => 'Заявка с Tilda: ' . ($data['name'] ?? ''),
    'NAME' => $data['name'] ?? '',
    'PHONE' => [['VALUE' => $data['phone'] ?? '', 'VALUE_TYPE' => 'WORK']],
    'EMAIL' => [['VALUE' => $data['email'] ?? '', 'VALUE_TYPE' => 'WORK']],
    'UF_CRM_UTM_SOURCE' => $data['utm_source'] ?? '',
    'UF_CRM_UTM_CAMPAIGN' => $data['utm_campaign'] ?? '',
];

$ch = curl_init($webhook);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode(['fields' => $fields]));
curl_setopt($ch, CURLOPT_HTTPHEADER, ['Content-Type: application/json']);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($ch);

file_put_contents('leads.log', date('c') . ' ' . $response . PHP_EOL, FILE_APPEND);

Важный момент: Тильда ждёт ответ от вебхука около 5 секунд, и если сервер отвечает дольше, форма на сайте покажет клиенту ошибку отправки, хотя данные могли уже уйти. Поэтому тяжёлую логику (проверку дублей, отправку уведомлений менеджеру) я выношу в отдельный процесс, а обработчику webhook оставляю только приём и запись данных.

Передача UTM-меток, промокодов и допполей без потерь

UTM-метки и любые нестандартные значения долетают до Битрикс24, только если в форме включены скрытые поля и в CRM заранее созданы пользовательские поля сделки или лида с префиксом UF_CRM_. Метод crm.lead.add молча игнорирует ключи, для которых такого поля нет в системе, без ошибки в ответе, поэтому проверять их нужно вручную через админку Битрикс24, а не полагаться на код ответа API.

С промокодами похожая история: если на Тильде стоит собственная логика ограничения промокодов, например код не действует на категорию «Распродажа», значение промокода нужно прокидывать в CRM отдельным полем, а не текстом внутри комментария, иначе отдел продаж не сможет отфильтровать такие заявки в списке сделок. У меня в библиотеке есть готовый скрипт ограничения промокодов по категориям для Тильды: он применяет скидку только к разрешённым товарам, а сам промокод остаётся штатным полем корзины Tilda и уходит в заявку как обычно.

Способы подключения Tilda к Битрикс24: что выбрать

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

Почему заявки теряются и дублируются на практике

Чаще всего причины сводятся к нескольким повторяющимся ситуациям.

Лимит тарифа Битрикс24

На тарифе с ограничением по числу открытых лидов новые заявки при превышении лимита API возвращает ошибкой, а коннектор Тильды эту ошибку никак не показывает и не повторяет отправку.

Разный формат телефона

Тильда может отправлять номер в формате +7, а старые контакты в Битрикс24 сохранены с 8 в начале. Дедупликация по телефону в CRM их не распознаёт как один и тот же номер, и на каждую повторную заявку создаётся новый лид вместо обновления существующего.

Таймаут вебхука

Если обработчик на сервере долго обращается к базе данных или сторонним сервисам перед ответом Тильде, форма показывает клиенту ошибку отправки, хотя лид уже создан. Клиент отправляет заявку повторно, и в CRM появляется дубль.

Автоматизация поверх интеграции: n8n и доработки форм

Когда заявки идут не в одну CRM, а параллельно в Битрикс24 и, например, в Telegram-канал отдела продаж, вебхук на голом сервере превращается в отдельный сервис, который нужно поддерживать. В таких случаях я собираю сценарий в n8n: триггер принимает POST от Тильды, дальше идёт нормализация телефона, проверка на дубль по CRM, создание сделки в Битрикс24 и уведомление в мессенджер, а при ошибке на любом шаге сценарий делает повторную попытку через несколько минут вместо того, чтобы просто потерять данные.

Этот же принцип работает и для доработок самой формы на Тильде: маска телефона, обязательные скрытые поля, валидация промокода на стороне клиента до отправки. Такие правки собираются кастомным JS-кодом в самом блоке формы, без переноса сайта на другую платформу.

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

Чем плохой нативный коннектор Тильды с Битрикс24?

Он передаёт только базовые поля и не сообщает об ошибке, если заявка не дошла из-за лимита тарифа или пустого обязательного поля. Для формы «имя плюс телефон» его достаточно, для магазина с товарами и промокодами уже нет.

Как передать UTM-метки из Тильды в Битрикс24?

Включить скрытые поля в настройках формы, заранее создать пользовательские поля UF_CRM_ в Битрикс24 под каждую метку и убедиться, что вебхук или коннектор реально их подхватывает, проверив карточку созданного лида, а не только код ответа API.

Почему заявки дублируются в Битрикс24?

Чаще всего из-за разного формата телефона (с 8 и с +7), из-за которого дедупликация CRM не видит совпадения, либо из-за таймаута обработчика, когда клиент отправляет форму повторно после видимой ошибки.

Сколько стоит настройка интеграции Битрикс24 и Тильды?

Простая доработка формы или полей стоит от 3 000 ₽. Комплексная интеграция с CRM, эквайрингом и СДЭК, включая вебхуки и обработку дублей, от 40 000 ₽ в зависимости от количества полей и сценариев.