Контракт данных с CRM: что согласовать до интеграции

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

Для обращения отдельно определите связь контакта и сделки. Один человек может задать два разных вопроса; один запрос может несколько раз передаваться по сети. Правило «совпал телефон — удалить» путает эти ситуации. Бизнес-правило принадлежит владельцу процесса, техническая команда переводит его в проверяемый контракт.

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

Учебный пример: «выбранная услуга» на сайте становится кодом направления в CRM, а не произвольным названием, которое менеджер должен угадывать. Контакт и свободное сообщение не следует автоматически дублировать в параметры аналитики. Передавайте только необходимые поля и согласуйте доступ, хранение и удаление для своего проекта.

HTTP 200 не всегда означает успех всей операции. Например, официальная документация Bitrix24 требует анализировать тело ответа; batch может быть принят, когда отдельные команды завершились ошибкой. Для конкретной интеграции проверяют нужный результат и его идентификатор, а не только статус транспорта.

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

AWS Builders’ Library описывает безопасный повтор через идентификатор намерения: тот же запрос с тем же ключом не должен создавать новый побочный эффект. Это контракт обеих сторон, а не универсальная функция любой CRM. Проверьте, поддерживает ли конечный API такой механизм и как долго сохраняет результат.

Если операция выполнена, а ответ потерян, интеграции может понадобиться сверка по внешнему идентификатору. Хэш телефона не заменяет идентификатор обращения. Память процесса, ограниченный кэш и устойчивое хранилище дают разные гарантии; после перезапуска или истечения срока повтор может снова стать новой записью. Эти пределы должны быть в задании.

Bitrix24 публикует ограничения интенсивности и ресурсоёмкости REST-вызовов. Возможности облачной и коробочной версии отличаются, а тариф и API проверяют для конкретного аккаунта. Увеличение количества параллельных запросов не является универсальным ускорением.

Разделите временный сбой, отсутствие доступа, неправильные данные и исчерпание лимита. У каждого случая должен быть понятный следующий шаг: отложенный повтор, исправление поля, обновление доступа или ручная сверка. Согласуйте, кто видит остановку обмена и кто имеет право повторно обработать запись. Логи не должны раскрывать ключи доступа.

Проверьте один корректный запрос до рабочего списка менеджера, затем повтор, ошибку данных, недоступность системы и восстановление после перезапуска. Сохраните идентификаторы и ожидаемые состояния без лишних личных данных. Для пакетной передачи добавьте частичный успех: исправные элементы не должны бесконечно пересоздаваться из-за одного проблемного.

В кейсе «Ру Пром» опубликованы CRM, интеграция с 1С и Telegram-бот. Это подтверждает заявленный объём проекта, но детали API, схема хранения и гарантия повторов там не раскрыты: их нельзя переносить на новый проект как готовое обещание. Для оценки нужны ваша рабочая система, реальные статусы и допустимые тестовые данные.