DaData в форме Тильда: подсказки адреса и проверка телефона

Подключаю DaData в форме Tilda почти на каждом проекте, где есть доставка или платная заявка: люди путают дом и корпус, ошибаются в индексе, вводят несуществующий номер телефона просто потому что торопятся заполнить форму. DaData в форме Тильда решает две задачи сразу: показывает подсказки при вводе адреса и проверяет телефон на валидность и тип (мобильный или стационарный) до того, как заявка попадёт в CRM. Ниже рабочая схема подключения с кодом, реальными лимитами API и ошибками, на которые я натыкался на практике.

Зачем подсказки адреса и проверка телефона в форме Tilda

Форма на Tilda в базовой сборке отдаёт то, что человек вписал руками, без всякой проверки. Для лендинга с формой обратной связи это не страшно, для магазина с доставкой через СДЭК или курьерскую службу критично, потому что от адреса зависит расчёт зоны доставки и стоимости.

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

DaData закрывает обе проблемы. Suggestions API отдаёт варианты адреса по мере ввода и нормализует его до структурированного вида: индекс, регион, улица, дом. Clean API проверяет телефон, приводит его к формату +7XXXXXXXXXX и определяет тип номера и качество данных.

API-ключ DaData и лимиты, которые стоит учитывать

Регистрация в личном кабинете на dadata.ru даёт два ключа: API-ключ, который можно использовать прямо в браузере, и секретный ключ, который нельзя светить в клиентском коде ни при каких условиях.

Бесплатный тариф даёт 10 000 запросов в сутки суммарно на подсказки и очистку. Для среднего лендинга или магазина с посещаемостью до нескольких сотен человек в день этого хватает с запасом. Если трафик выше, стоит сразу заложить debounce на поле ввода, то есть не дёргать API на каждое нажатие клавиши, а ждать паузу 300-400 мс после того как человек перестал печатать. Без этого лимит суточных запросов на одном активном лендинге съедается за первую же неделю.

Подсказки адреса: виджет DaData Suggestions в форме Tilda

В Tilda поле адреса добавляется как обычное текстовое поле формы T123 с заданным id, а дальше через блок «Ещё» и вставку кода на странице подключается скрипт виджета.

<input id="address" type="text" placeholder="Введите адрес доставки">

<script src="https://cdn.jsdelivr.net/npm/suggestions-jquery@22.6.0/dist/js/jquery.suggestions.min.js"></script>
<script>
  $('#address').suggestions({
    token: "ВАШ_API_КЛЮЧ",
    type: "ADDRESS",
    onSelect: function(suggestion) {
      console.log(suggestion.value, suggestion.data.postal_code);
    }
  });
</script>

Параметр type можно менять на PARTY для подсказок по юрлицам, если форма собирает данные B2B-клиентов, или на FIO для автоподсказки имени и фамилии. Если поле адреса просто снижает число опечаток и не завязано на дальнейший расчёт доставки, клиентского виджета достаточно, секретный ключ здесь не нужен вообще.

Куда вставлять код в Tilda

Если подсказки нужны на одной форме, код вставляется прямо в блок через настройки T123, в раздел с HTML-кодом под конкретным полем. Если форма с адресом стоит на нескольких страницах, скрипт логичнее подключить один раз через «Настройки сайта» -> «Ещё» -> «Вставка кода в head», чтобы не дублировать его на каждой странице. Tilda уже подгружает jQuery, поэтому конфликтов с виджетом обычно не возникает, но на страницах с кастомным Zero Block стоит проверить порядок загрузки скриптов в консоли браузера.

Проверка телефона: DaData Clean API и почему это не делается в браузере

Для очистки телефона DaData требует заголовок с секретным ключом. Если вызывать /clean/phone прямо из браузера, ключ виден в исходном коде страницы и в вкладке Network любому, кто откроет devtools, а значит квоту можно исчерпать чужими руками или использовать ключ для спама.

Практическая схема: форма Tilda отправляет данные на вебхук, вебхук уходит в n8n или на свой серверный обработчик, там выполняется запрос к Clean API, и уже по результату лид либо уходит в CRM, либо помечается на ручную проверку.

curl -X POST https://cleaner.dadata.ru/api/v1/clean/phone \
  -H "Content-Type: application/json" \
  -H "Authorization: Token ВАШ_API_КЛЮЧ" \
  -H "X-Secret: ВАШ_СЕКРЕТНЫЙ_КЛЮЧ" \
  -d '["+7 916 123-45-67"]'

В ответе приходят поля phone (номер в нормализованном виде), type («Мобильный», «Стационарный», «Прямой мобильный», «Колл-центр» или «Неизвестный» - именно такими русскими значениями, не MOBILE/FIX), valid и qc, код качества, где 0 значит номер прошёл проверку без замечаний, а остальные значения указывают на конкретную проблему: неполный номер, лишние цифры, недопустимый код региона. По этому полю удобно сразу фильтровать заведомо нерабочие заявки.

Серверная валидация формы целиком: пример на n8n

Схема, которую я обычно собираю: Webhook-нода принимает отправку формы Tilda, следом HTTP Request-нода вызывает Clean API DaData, дальше IF-нода проверяет valid и type, и только после этого лид уходит в Bitrix24 или amoCRM. Если номер не прошёл проверку, заявка не теряется, а падает в отдельный список для звонка вручную, и параллельно менеджеру летит уведомление в Telegram через бота на aiogram, чтобы он не ждал следующей выгрузки из CRM.

Похожую логику предвалидации я делаю и в других стеках: например, в интернет-магазине на WooCommerce с эквайрингом T‑Bank телефон и адрес тоже проверяются до того, как клиент попадёт на страницу оплаты, просто источник данных там другой. Принцип один: чем раньше отсеивается мусор в контактных данных, тем меньше ручной работы у менеджера потом.

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

Частые ошибки при подключении DaData к форме Tilda

• Секретный ключ вставлен в код, который виден в исходнике страницы, его может забрать кто угодно и исчерпать суточный лимит.
• Виджет подключается раньше jQuery, скрипт падает с ошибкой в консоли, и поле выглядит как обычный инпут без подсказок.
• Тип поля указан ADDRESS, хотя форма собирает данные юрлица, для B2B нужен тип PARTY, иначе подсказки нерелевантны.
• Нет debounce на инпуте, каждое нажатие клавиши превращается в отдельный запрос, суточный лимит тарифа съедается за пару дней активного трафика.
• Проверка телефона встроена в саму форму как блокирующая: человек не может отправить заявку, пока DaData не ответит. При недоступности API форма перестаёт отправляться вообще, поэтому проверку лучше делать постфактум, уже после сабмита, а не до него.

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

Сколько стоит подключение DaData к форме на Tilda?

Сама DaData бесплатна в пределах лимита 10 000 запросов в сутки, платить нужно только если трафик выше этого порога. Настройка виджета подсказок адреса как доработка формы стоит от 3 000 ₽, а полноценная интеграция с вебхуком, серверной проверкой телефона и передачей заявки в CRM обходится от 40 000 ₽, потому что это уже комплексная работа с несколькими сервисами.

Можно ли подключить DaData на Tilda без программиста?

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

Что делать, если DaData не находит адрес?

Обычно причина в неполном запросе без указания региона или в том, что адрес действительно новый и ещё не попал в базу ФИАС, на которой строится DaData. В таком случае поле стоит оставлять доступным для ручного ввода без блокировки отправки формы, подсказка это помощь, а не обязательное условие для заказа.

Безопасно ли передавать телефоны клиентов через DaData?

DaData обрабатывает запрос и возвращает результат проверки, не сохраняя контакты клиентов для показа третьим лицам в рамках обычного использования API. При этом саму базу телефонов и адресов клиентов нужно хранить на серверах в России, чтобы соблюдать требования 152-ФЗ о локализации персональных данных, а не выгружать в иностранные облачные таблицы.