Интеграция Tilda и Битрикс24 через n8n: лиды с UTM без дублей ¶

Обновлено: 2026-05-30

Проблема: Tilda отправляет форму в webhook быстро, но Битрикс24 не должен получать новый лид при каждом повторном POST. Иначе менеджеры видят одинаковые заявки, UTM-аналитика расходится, а автоматизация продаж начинает обзванивать одного человека несколько раз.

Решение: надежная интеграция Тильды и Битрикс24 через n8n принимает данные из формы, нормализует телефон, ищет дубли через REST API Битрикс24 и только потом делает crm.lead.add или обновляет найденную сущность. Это не “прокладка webhook → CRM”, а контролируемый слой качества данных.

Страница рассчитана на интегратора: здесь есть готовый workflow JSON, payload для теста, Code Node с регуляркой, таблица архитектуры, production-риски и чек-лист запуска.

Проблема: почему простая передача формы Tilda в Битрикс24 создает дубли ¶

Простая настройка вебхука работает только до первого повторного лида. Пользователь мог дважды нажать кнопку, вернуться с другой рекламной кампании, оставить форму без email или написать телефон в формате 8 925.... Если каждый такой запрос превращается в новый лид, CRM быстро теряет доверие у отдела продаж.

У Битрикс24 есть отдельная логика дублей и разные режимы CRM. Поэтому задача workflow — заранее подготовить поля, проверить phone/email как коммуникации и не смешивать UTM, комментарий, страницу заявки и системные поля в один текстовый блок.

Архитектура workflow для интеграции Tilda и Битрикс24 ¶

Встроенный “просто отправить форму” не показывает, где именно сломался процесс. Ручная схема в n8n удобнее: видно нормализованный телефон, результат поиска дубля, тело запроса к Bitrix24 API и финальный ответ CRM.

Контракт входных данных (JSON Payload) ¶

Зафиксируйте контракт входных данных до публикации формы. Чем стабильнее payload, тем меньше ручных правок в Битрикс24 после запуска рекламы.

{
  "name": "Ирина",
  "phone": "+7 (925) 400-11-22",
  "email": "irina@example.ru",
  "comment": "Хочу получить расчет внедрения CRM",
  "utm_source": "yandex",
  "utm_medium": "cpc",
  "utm_campaign": "bitrix24_integration",
  "utm_content": "lead_form_main",
  "utm_term": "интеграция тильды и битрикс24",
  "formid": "consultation-main",
  "page": "https://example.ru/bitrix24"
}

Обязательный минимум — телефон. Email, комментарий и UTM полезны, но не должны заменять ключ дедупликации. Если телефон не проходит нормализацию, workflow должен остановиться до обращения в CRM.

Нормализация телефона и UTM для Bitrix24 REST (Code Node) ¶

Code Node ниже подготавливает объект fields для REST API: коммуникации оформлены массивами PHONE и EMAIL, UTM передаются в стандартные поля, а дополнительные значения уходят в пользовательские поля.

const src = $json.body ?? $json;
const rawPhone = String(src.phone ?? src.Phone ?? '').trim();
let digits = rawPhone.replace(/\D/g, '');

if (digits.length === 11 && digits.startsWith('8')) {
  digits = `7${digits.slice(1)}`;
}

if (digits.length === 10) {
  digits = `7${digits}`;
}

if (!/^7\d{10}$/.test(digits)) {
  throw new Error(`Invalid phone for Bitrix24 lead: ${rawPhone}`);
}

const email = String(src.email ?? src.Email ?? '').trim().toLowerCase();
const name = String(src.name ?? src.Name ?? 'Новый лид из Tilda').trim();

return [{
  json: {
    dedupe: {
      phone: `+${digits}`,
      email,
      key: `tilda-bitrix24:${digits}:${email || 'no-email'}`
    },
    fields: {
      TITLE: `Tilda: ${name}`,
      NAME: name,
      PHONE: [{ VALUE: `+${digits}`, VALUE_TYPE: 'WORK' }],
      EMAIL: email ? [{ VALUE: email, VALUE_TYPE: 'WORK' }] : [],
      COMMENTS: String(src.comment ?? src.message ?? '').trim(),
      SOURCE_ID: 'WEB',
      UTM_SOURCE: src.utm_source ?? '',
      UTM_MEDIUM: src.utm_medium ?? '',
      UTM_CAMPAIGN: src.utm_campaign ?? '',
      UTM_CONTENT: src.utm_content ?? '',
      UTM_TERM: src.utm_term ?? '',
      UF_CRM_TILDA_FORM_ID: src.formid ?? src.form_id ?? '',
      UF_CRM_LANDING_PAGE: src.page ?? src.referer ?? ''
    },
    received_at: new Date().toISOString()
  }
}];

Для поиска дубля используйте phone/email из dedupe. В Битрикс24 метод поиска дублей по коммуникациям работает с телефоном и email, поэтому важно не отправлять туда сырые значения из формы.

Готовый workflow JSON: скачать и импортировать ¶

Полный JSON находится в архиве сайта и доступен по кнопке в начале статьи. Импортируйте его в n8n, затем замените Bitrix24 webhook URL вида https://YOUR_PORTAL.bitrix24.ru/rest/USER_ID/WEBHOOK_CODE/.

{
  "name": "Nodbot - Tilda to Bitrix24 lead with UTM and dedupe",
  "nodes": [
    { "name": "Webhook input", "type": "n8n-nodes-base.webhook", "purpose": "Принять POST формы Tilda и вернуть короткий ответ" },
    { "name": "Normalize and map Bitrix24 fields", "type": "n8n-nodes-base.code", "purpose": "Нормализовать телефон, email, UTM и собрать Bitrix24 fields" },
    { "name": "Find duplicate in Bitrix24", "type": "n8n-nodes-base.httpRequest", "purpose": "Вызвать crm.duplicate.findbycomm по телефону/email" },
    { "name": "Create or update Bitrix24 lead", "type": "n8n-nodes-base.httpRequest", "purpose": "Создать crm.lead.add или обновить найденный лид" },
    { "name": "Respond to Webhook", "type": "n8n-nodes-base.respondToWebhook", "purpose": "Вернуть Tilda безопасный 200 OK" }
  ],
  "connections": "Webhook input → Normalize → Find duplicate → Create/update lead → Respond"
}

В новых проектах можно заменить создание лида на универсальные методы CRM, но для классического режима с лидами сценарий выше проще объяснить менеджерам и легче отлаживать.

Пошаговая настройка связки Tilda, n8n и Битрикс24 ¶

1. В Tilda включите отправку формы в webhook и убедитесь, что передаются телефон, email, комментарий, UTM и formid.
2. В n8n импортируйте workflow JSON и замените путь webhook на production URL.
3. В Битрикс24 создайте входящий webhook с правами на CRM и сохраните его URL в credentials или ENV.
4. Проверьте ID пользовательских полей для form_id и landing page; не пишите их только в комментарий.
5. Настройте ветку: если дубль найден — update/comment, если не найден — create lead.
6. Отправьте один payload дважды и убедитесь, что повтор не создал второй лид.

Тесты перед production и проверка Bitrix24 API ¶

Проверяйте не только успешный HTTP-ответ. В executions должны быть понятны три вещи: нормализованный телефон, найденный дубль и результат записи в Битрикс24. Для production отдельно проверьте ответы 400, 401, 403 и 429.

curl -X POST "https://YOUR-N8N-DOMAIN/webhook/tilda-form-to-bitrix24-lead" \
  -H "Content-Type: application/json" \
  --data @tilda-form-to-bitrix24-lead-payload.json

Минимальный набор тестов: повторный payload, телефон в формате 8..., заявка без email, UTM с кириллицей и пустой комментарий. Все эти случаи должны давать предсказуемый результат.

Production-риски при работе с REST API Битрикс24 ¶

• Webhook Битрикс24 лежит прямо в ноде. Утечка URL даёт доступ к CRM-операциям. Храните его в credentials или ENV.
• Дубль ищется после создания лида. Тогда CRM уже загрязнена. Поиск должен идти до create.
• UTM потерялись в комментарии. Маркетинг не сможет построить нормальный отчёт по источникам.
• Лимиты REST API. Массовый импорт лидов через тот же workflow без backoff может упереться в ограничения.
• Разные режимы CRM. В некоторых порталах лиды отключены; тогда нужно создавать сделку/контакт, а не crm.lead.add.
• Нет владельца workflow. При смене формы никто не знает, какие поля можно переименовывать безопасно.

Полезные ссылки и смежные workflow ¶

Официальные документы для внедрения: поиск дублей в Bitrix24 REST, раздел Leads в Bitrix24 CRM и Webhook для форм Tilda.

Смотрите также внутри Nodbot:

• Установка n8n — базовая подготовка сервера.
• n8n в Docker Compose — self-hosted запуск для production.
• Битрикс24 в n8n — общая страница интеграции.
• Tilda → amoCRM — соседний сценарий для другой CRM.
• Retry и DLQ для HTTP Request — защита от временных ошибок API.

Критерии готовности ¶

1. Повторная отправка формы не создаёт второй лид без бизнес-правила.
2. Телефон нормализуется одинаково для +7, 8, пробелов и скобок.
3. UTM, form_id и landing page записываются в отдельные поля.
4. Ошибки REST API уходят в alert или DLQ.
5. Webhook URL не хранится в публичном тексте workflow.
6. У workflow есть владелец, описание и тестовый payload.