Дубли появляются, когда интеграция каждый раз создаёт новую сущность и не умеет искать уже существующую по устойчивому идентификатору.
Короткий ответ
Перед созданием нужно нормализовать телефон и email, выбрать правила поиска, хранить внешний ID и понимать, когда обновлять старую сделку, а когда создавать новую.
Что проверить в первую очередь
Сначала проверьте несколько вещей, которые напрямую влияют на решение:
- Нормализовать телефоны до единого формата.
- Не использовать имя клиента как уникальный ключ.
- Разделить правила дублей для контакта и для сделки.
Практический подход
Если внешняя система иногда отвечает медленно или недоступна, прямой запрос «пользователь ждёт — API отвечает» подходит не всегда. Для важных операций разумнее очередь, журнал событий и повторная обработка.
Типичные ошибки
Ниже — ошибки, которые чаще всего делают решение дороже, сложнее или менее предсказуемым:
- Считать успешный http-ответ гарантией правильного бизнес-результата.
- Не хранить идентификаторы связанных сущностей.
- Делать интеграцию без логов.
- Не продумывать повторную обработку после временной ошибки внешнего сервиса.
Что подготовить перед началом
Для оценки обычно достаточно: документация обоих сервисов, перечень сущностей и полей, примеры запросов, правила обработки дублей, сценарий ошибки и ожидаемый результат.
Если части информации пока нет, это нормально. Лучше обозначить неизвестное сразу, чем строить оценку на предположениях.
Как понять, что результат хороший
Устойчивую интеграцию можно проверить по реальным сценариям: данные не теряются, повторный запрос не создаёт дубли, ошибки видны в логах, а временный сбой внешнего сервиса не ломает весь процесс.
Когда подключать специалиста
Для оценки интеграции обычно нужны документация API, пример сущностей и несколько реальных сценариев. Если документации нет, сначала стоит проверить, какие интерфейсы и вебхуки система действительно предоставляет.
Вывод
Перед созданием нужно нормализовать телефон и email, выбрать правила поиска, хранить внешний ID и понимать, когда обновлять старую сделку, а когда создавать новую. Если ситуация отличается от типовой, решение лучше проверять на текущем проекте, а не подгонять его под универсальный шаблон.
