HTTP 200 от API ещё не означает, что бизнес-данные записаны правильно

Короткий ответ: код HTTP 200 сам по себе не подтверждает, что нужные поля CRM приняли ожидаемые значения. Разберите тело ответа, затем прочитайте объект повторно и сравните результат с тем, который интеграция должна была сохранить.

Что означает успешный ответ

У API есть несколько уровней результата. Сначала проверяют сетевой ответ и его статус. Затем — структуру JSON: обычная ошибка Битрикс24 содержит error и error_description. В пакетном вызове отдельные подзапросы могут завершиться ошибкой даже при HTTP 200 для всего пакета. Наконец, успешный ответ метода показывает результат обработки запроса, но для критичного бизнес-поля полезно отдельно подтвердить сохранённое значение.

Например, после crm.item.update метод возвращает объект result.item. Официальные сценарии Битрикс24 также используют crm.item.get для проверки значения поля после изменения. Формат и допустимые значения зависят от конкретного поля и метода, поэтому сравнивать нужно нормализованное ожидаемое состояние, а не только исходный текст запроса.

Цикл записи и проверки

1. Зафиксируйте ожидание. Запишите ID объекта, тип сущности и значения критичных полей до вызова. Отделите бизнес-ключи от технических полей, которые Битрикс24 вправе преобразовать.
2. Выполните запись один раз. Передайте валидированный payload и сохраните код метода, статус и безопасные идентификаторы операции. Секрет вебхука в журнал не записывайте.
3. Разберите ответ метода. Проверьте error, error_description и структуру result. Для batch отдельно проверьте ошибки каждого подзапроса.
4. Перечитайте объект. Вызовите применимый метод чтения, например crm.item.get с теми же entityTypeId и id.
5. Сравните критичные поля. Если значение отличается или объект недоступен, оставьте операцию в состоянии «требует разбора». Повторную запись делайте только после проверки, не создала ли первая попытка нужный результат.

Типовая ошибка

Система помечает задачу завершённой сразу после получения HTTP 200 и не проверяет поле, ради которого делался вызов. В результате следующая стадия процесса опирается на устаревшее или иначе нормализованное значение.

Вывод

Для интеграции важен достигнутый результат: нужный объект существует и его критичные поля прочитаны в ожидаемом состоянии. Код HTTP и успешный вызов — только части этой проверки.

Источники

• Битрикс24: как распознать ошибку REST
  Описаны ошибки в теле ответа и подзапросах batch.
• Битрикс24: crm.item.update
  Структура результата записи и ошибки.
• Битрикс24: crm.item.get
  Повторное чтение объекта CRM.
• Битрикс24: проверка сохранённой даты оплаты
  Практический пример read-back критичного поля.

Связанный маршрут

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