Интеграция сайта с CRM перестала передавать данные: где искать сбой

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

Зафиксируйте конкретный пример

Фразы «иногда не работает» недостаточно. Подготовьте:

• время события;
• идентификатор заявки или заказа;
• исходные данные без лишних персональных сведений;
• ожидаемый результат;
• фактическое состояние в CRM;
• последние изменения на сайте и во внешней системе.

Если ошибки возникают только у определенного типа обращения, сравните успешный и неуспешный набор полей.

Проверьте создание исходного события

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

• frontend показал успех до ответа сервера;
• сервер отклонил данные;
• событие не было поставлено в очередь;
• фоновая задача остановлена;
• одно из условий маршрутизации изменилось;
• обработчик вызывается только для части форм.

Надежнее сначала сохранять исходную операцию локально, а затем передавать ее во внешние сервисы.

Проверьте очередь и фоновые задачи

Если интеграция работает асинхронно, сайт отвечает пользователю до завершения обмена. Тогда проверяем:

• запущен ли worker;
• растет ли очередь;
• есть ли задания в состоянии failed;
• не зависла ли одна операция;
• работает ли планировщик;
• выполняются ли повторные попытки.

Очередь без контроля способна накапливать ошибки несколько дней, пока сотрудники не заметят расхождение вручную.

Авторизация и доступ к API

Токен может истечь, потерять права или быть отозван после смены сотрудника. Проверяем не только наличие секрета, но и фактический ответ API.

Типовые ситуации:

• 401 — неверная или истекшая авторизация;
• 403 — токен распознан, но не хватает прав;
• 404 — изменился endpoint или идентификатор сущности;
• 429 — превышен лимит запросов;
• 5xx — временная ошибка внешнего сервиса.

Секреты не должны попадать в публичные логи или текст уведомлений.

Схема данных и обязательные поля

CRM может начать требовать поле, которого раньше не было, либо изменить допустимые значения. Проверяем соответствие:

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

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

Webhooks и обратный обмен

Входящий webhook может не дойти из-за смены URL, SSL, защитного фильтра или неверной подписи. Endpoint должен быстро подтвердить прием и передать тяжелую обработку в очередь.

Проверяем:

1. 1Доступен ли URL из внешней сети.
2. 2Соответствует ли метод запроса.
3. 3Проверяется ли подпись.
4. 4Не истек ли сертификат.
5. 5Что возвращает endpoint.
6. 6Можно ли безопасно повторить событие.

Повторные попытки без дублей

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

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

Логи, которые действительно помогают

Для каждой операции полезно сохранять:

• внутренний идентификатор;
• направление обмена;
• время попытки;
• endpoint без секретных параметров;
• HTTP-код;
• безопасный код ошибки;
• номер попытки;
• итоговый внешний идентификатор.

Логи должны позволять ответить, где находится конкретная заявка, не раскрывая содержимое пользовательских данных всем сотрудникам.

Проверка после исправления

Одной успешной записи недостаточно. Проверяются обычные данные, минимальный набор полей, повторное событие, временная ошибка и пограничные значения. Затем сверяется количество операций на обеих сторонах.

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

Так команда замечает отклонение до того, как менеджеры начинают искать пропавшие заявки вручную.

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

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

Можно ли восстановить интеграцию без документации?

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

Почему часть заявок передается, а часть нет?

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

Нужно ли повторять все ошибочные операции автоматически?

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

Как узнать, сколько данных потеряно?

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