API 1С ломается не в коде, а на стыке бизнес-логики и обмена

API 1С ломается не в коде, а на стыке бизнес-логики и обмена

Если интеграция с 1С «вроде работает», а потом появляются дубли, пустые поля и странные статусы — проблема почти всегда в договорённостях. Перед стартом зафиксируйте:
• какой объект является источником правды;
• кто создаёт заказ и кто меняет его статус;
• какие поля обязательны, а какие можно не передавать.

Дальше проверьте сам API на уровне формы данных. 1С плохо переносит хаос в названиях и типах: одна и та же дата в разных форматах, строка вместо числа, пустой массив вместо null — и обмен начинает падать не там, где вы ждёте. Отдельно тестируйте:
• повторную отправку одного и того же запроса;
• частичный ответ с ошибкой по одному полю;
• обмен, который прерывается на середине.

Ещё один частый провал — отсутствие идемпотентности. Если заказ уже создан, повторный запрос не должен плодить дубль. Для этого нужен внешний идентификатор и понятная логика поиска записи в 1С перед созданием новой.

Если интеграцию с 1С делать как набор «сейчас передадим, а потом разберёмся», она быстро превращается в источник ручных правок. Сначала согласуйте правила обмена, потом формат данных, и только после этого подключайте автоматизацию.