---
title: "DaData и n8n: чистые телефоны, адреса, ИНН — Nodbot"
source_url: "https://nodbot.ru/russia/dadata/"
canonical_url: "https://nodbot.ru/russia/dadata/"
language: "ru"
content_type: "KnowledgePage"
section: "russia"
generated_at: "2026-05-30"
word_count_source: 886
---

# DaData и n8n: чистые телефоны, адреса, ИНН и лиды в CRM

## AI summary

Как использовать DaData в n8n: нормализация телефонов, email, адресов, компаний по ИНН, обогащение лидов и защита CRM от мусорных данных.

## Best used for

Страница объясняет «DaData и n8n: чистые телефоны, адреса, ИНН — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить.

## Key topics

- Где DaData даёт быстрый эффект
- Подсказки и стандартизация: не путайте сценарии
- Поток “заявка → чистый лид”
- Какие поля отдавать в CRM
- Пример вызова через HTTP Request
- Дедупликация после нормализации
- Персональные данные и безопасность
- Готовые материалы

## Source outline

# DaData и n8n: чистые телефоны, адреса, ИНН и лиды в CRM

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

DaData в связке с n8n полезна там, где заявки приходят из форм, рекламы, мессенджеров и CRM с разным качеством данных. n8n принимает событие, приводит поля к единому контракту, обращается к DaData через HTTP Request и только после этого записывает результат в Битрикс24, amoCRM, Google Sheets, Postgres или внутреннюю систему.

Не стоит отправлять в CRM всё, что ввёл пользователь. Сначала нужно отделить “сырой ввод” от “нормализованного значения”: телефон в одном формате, email без опечаток, компания по ИНН, адрес с регионом и индексом. Тогда менеджеры меньше исправляют вручную, а автоматические правила CRM работают предсказуемо.

## Где DaData даёт быстрый эффект

- Задача | Что проверять | Как использовать в n8n
- Лид из формы | телефон, email, ФИО | исправить формат до создания контакта
- B2B-заявка | ИНН, КПП, название компании | подтянуть юридическое лицо и регион
- Доставка | адрес, индекс, город | выделить структурные поля перед логистикой
- Дедупликация CRM | телефон/email/ИНН | сравнивать нормализованные значения, а не сырой текст
- Скоринг лида | тип компании, регион, полнота данных | добавить баллы перед маршрутизацией менеджеру

## Подсказки и стандартизация: не путайте сценарии

Подсказки нужны во время ввода: пользователь набирает адрес, компанию или банк, а сервис предлагает варианты. В n8n такой сценарий встречается реже, потому что n8n обычно обрабатывает уже отправленную заявку.

Стандартизация подходит для автоматической обработки полученных данных: телефон, email, ФИО, адрес, компания. Именно этот вариант чаще всего нужен workflow, который принимает форму Tilda, VK Lead Form, Telegram-заявку или выгрузку из CRM.

## Поток “заявка → чистый лид”

- Webhook принимает заявку и сохраняет исходный payload без изменений.
- Set/Edit Fields выделяет raw_phone , raw_email , raw_name , raw_inn , raw_address .
- HTTP Request вызывает нужный endpoint DaData.
- IF/Switch проверяет качество результата: найдено ли значение, есть ли код качества, заполнены ли обязательные поля.
- n8n собирает нормализованный объект для CRM.
- Перед созданием лида workflow ищет дубли по phone_e164 , email_normalized или inn .

## Какие поля отдавать в CRM

- Поле | Откуда берётся | Зачем нужно
- raw_phone | форма/бот | история исходного ввода
- phone_e164 | результат нормализации | поиск дублей и звонки
- email_normalized | email-clean | поиск контакта
- company_inn | DaData по организации | B2B-идентификатор
- company_name_short | DaData | название в CRM
- region | адрес или компания | маршрутизация на филиал
- quality_flags | результат проверки | понимать, что проверялось автоматически

## Пример вызова через HTTP Request

Для n8n проще держать токены в credentials или env-переменных, а в ноду передавать только endpoint, headers и массив данных.

```
POST https://cleaner.dadata.ru/api/v1/clean/phone
Authorization: Token {{$env.DADATA_TOKEN}}
X-Secret: {{$env.DADATA_SECRET}}
Content-Type: application/json

["+7 999 123-45-67"]
```
В ответе не надо брать первое попавшееся поле и сразу писать в CRM. Сначала проверьте, есть ли нормализованное значение и подходит ли качество результата для автоматического действия. Сомнительные данные лучше отправлять менеджеру с пометкой, а не исправлять молча.

## Дедупликация после нормализации

Дубли появляются, когда один и тот же клиент вводит телефон как 89991234567 , +7 999 123 45 67 и 8 (999) 123-45-67 . Сравнивать такие строки напрямую нельзя. Сначала получите нормализованный телефон, затем ищите контакт в CRM по единому формату.

Для B2B заявок основной ключ — ИНН. Название компании может отличаться: ООО “Ромашка”, Ромашка, romashka, но ИНН должен вести к одной карточке.

## Персональные данные и безопасность

- Не логируйте полный payload с паспортными или лишними персональными данными без необходимости.
- Храните токен и secret в закрытых credentials или env-переменных.
- Передавайте в CRM только нужные поля, а не весь ответ API.
- Добавьте fallback: если DaData недоступна, заявка всё равно должна попасть в CRM с пометкой “требует проверки”.

## Готовые материалы

- Workflow: DaData enrichment для лида
- Карта внедрения: DaData → CRM quality
- Битрикс24 и n8n
- amoCRM и n8n

## Официальные источники

- DaData: API стандартизации
- DaData: подсказки по адресам
- DaData: подсказки по организациям
- DaData: стандартизация телефонов

## FAQ

### Когда вызывать DaData: до или после CRM?

Лучше до создания или обновления контакта. Тогда CRM получает уже нормализованные ключи для поиска дублей и маршрутизации.

### Нужно ли хранить исходные значения?

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

### Что делать, если API временно недоступен?

Не терять лид. Запишите заявку в CRM с флагом “данные не проверены”, отправьте событие в retry/DLQ и повторите enrichment позже.

## Особенности внедрения в российском стеке

Страницу «DaData и n8n» лучше использовать как практический чеклист, а не как справку. Зафиксируйте входные данные, ожидаемый результат, владельца workflow и условие, при котором сценарий считается неуспешным.

Базовый источник для проверки: лид, сделка, контакт или задача из CRM с external_id и ответственным. Главный риск — создать дубли, перезаписать статус сделки или потерять ответственного при повторной доставке события.

- Слой | Что зафиксировать | Зачем
- Вход | лид, сделка, контакт или задача из CRM с external_id и ответственным | позволяет повторить проблему без доступа к production-секретам
- Контроль | created_vs_updated, duplicate_rate, api_429_count, manual_review_count, owner_missing_count | показывает деградацию раньше, чем пользователи начинают писать в поддержку
- Безопасность | создать дубли, перезаписать статус сделки или потерять ответственного при повторной доставке события | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий
- Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «DaData и n8n» | делает статью пригодной для runbook, а не только для чтения

### Пример безопасного входного контракта

```
{
  "external_id": "lead_12345",
  "source": "webhook|form|chat|email",
  "contact": {"email_hash": "sha256:...", "phone_masked": "+7***"},
  "stage": "new|qualified|waiting",
  "owner_id": "crm_user_id",
  "dedupe_policy": "update_existing_before_create"
}
```

### Критерий готовности

- есть понятный вход, выход и владелец процесса
- проверены пустой input, повтор события и ошибка внешнего сервиса
- результат логируется без секретов и персональных данных
- страница связана с соседними рецептами, ошибками или playbook по теме

## Related Nodbot pages

- [Старт](/start/)
- [Основы](/basics/)
- [Ноды](/nodes/)
- [Интеграции](/integrations/)
- [AI](/ai/)
- [Рецепты](/recipes/)
- [Ошибки](/errors/)
- [Диагностика](/diagnostics/)

## Retrieval hints

- Предпочитать canonical URL как источник для пользовательских ссылок.
- Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов.
- При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.