Почему Bitrix24 REST молча пропускает запись свойства товара и как это ловить

Если интеграция передаёт свойство товара в Bitrix24 через REST строкой, метод catalog.product.update отвечает HTTP 200 с полным объектом товара — и ничего не записывает. Ошибки в ответе нет. Ниже — симптом, причина, проверка на живой системе, правильный формат запроса и контрольное чтение, без которого такую интеграцию нельзя считать рабочей.

Симптом: ответ 200, значение прежнее

Интеграция обновляет артикул, остаток или любое пользовательское свойство товара в каталоге Bitrix24. Запрос уходит в catalog.product.update, ответ — HTTP 200, в теле result.product со всеми полями. Мониторинг зелёный, журнал без ошибок. Открываем карточку товара — в свойстве прежнее значение.

Так может работать месяцами. Сайт или 1С считают, что данные ушли, Bitrix24 считает, что запрос обработан, и ни одна из сторон не видит расхождения: остальные поля того же запроса — название, цена, активность — записываются нормально, поэтому выборочная проверка «что-то обновилось» проходит. Обнаруживается это обычно не из логов, а от людей: менеджер замечает, что артикул в CRM не совпадает с учётной системой.

Причина: свойство товара в REST — объект, а не строка

В методах каталога Bitrix24 пользовательское свойство товара propertyN — это объект вида {"value": …, "valueId": …}; для множественного свойства — массив таких объектов. Так написано в документации метода. Чего документация не говорит: если передать вместо объекта строку, пустую строку или null, Bitrix24 не вернёт ошибку. Он пропустит это поле, запишет остальные и отчитается об успехе.

Для интеграции это худший из возможных вариантов. Формат «почти правильный», в ручном тесте всё выглядит нормально, а значение тихо не доходит.

Что показала проверка на живой системе

Мы не стали полагаться на предположения и 1 октября 2026 года воспроизвели поведение на коробочной версии Bitrix24: создали в каталоге неактивный тестовый товар, записали строковое свойство несколькими способами и после каждой записи перечитали товар методом catalog.product.get. Товар после проверки удалён, реальные данные не затрагивались. Все ответы — HTTP 200, поле error отсутствует.

Два вывода из таблицы. Первый: пропускается не только «неправильная» строка, но и пустая строка и null — очистить свойство строкой тоже не получится. Второй: valueId хранить у себя не нужно — Bitrix24 выдаёт новый при каждой записи, даже если значение не изменилось, а чужой идентификатор игнорирует.

Как писать правильно

Было — не пишет:

{"id": 7045, "fields": {"property61": "ABC-123"}}

Стало — пишет:

{"id": 7045, "fields": {"property61": {"value": "ABC-123"}}}

Множественное свойство — массив объектов:

{"id": 7045, "fields": {"property62": [{"value": "A"}, {"value": "B"}]}}

Для form-data правило то же: fields[property61][value]=ABC-123 записывает, fields[property61]=ABC-123 — нет.

Откуда берётся строка на практике. Чаще всего — из универсального маппинга «поле 1С → поле Bitrix24», где все значения собираются одинаково, как скаляры; свойства товара в нём ничем не отличаются от названия или артикула, и объект вокруг значения никто не строит. Второй источник — перенос кода с методов CRM, где пользовательские поля UF_* действительно принимают строку. Каталог устроен иначе, и этот перенос ломает запись без единого сообщения.

Контрольное чтение после записи

Правильный формат закрывает конкретную ошибку, но не класс ошибок. Код 200 для записи свойств означает только «запрос принят». Поэтому после каждой записи интеграция должна перечитать то, что записала:

catalog.product.get {"id": 7045, "select": ["id", "property61"]}

и сравнить result.product.property61.value с отправленным значением. Не совпало — запись в журнал уровня error и алерт, а не тихий успех. Это один дополнительный запрос, который превращает «мы отправили» в «мы проверили».

То же правило мы применяем к любой записи в учётную систему через API — 1С, Bitrix24, SAP: ответ об успехе подтверждается чтением.

Что это значит для руководителя

Если у компании есть интеграция сайта или 1С с Bitrix24, такая ошибка может месяцами не обновлять артикулы, цены или остатки, и ни один монитор этого не покажет — всё «зелёное». Один вопрос подрядчику закрывает риск: «после записи вы перечитываете данные и сверяете?» Если ответ «нет» или «не знаю» — это стоит включить в ближайшее обслуживание интеграции. Если ответ «да» — попросите показать, как выглядит алерт.

Документация метода: catalog.product.update.