Повтор запроса в API МоегоСклада: проверьте syncId до создания дубля

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

Этот разбор нужен владельцу учётного процесса и разработчику интеграции. Цель проверки: связать исходную операцию, повтор запроса и один фактический объект в учёте.

Сначала проверьте поддержку syncId

Документация МойСклад JSON API 1.2 описывает поле syncId для защиты от дублирования при повторном создании после сбоя. Правило относится к сущностям, у которых это поле есть среди атрибутов.

Клиент генерирует syncId и передаёт его в теле запроса создания. При повторной отправке того же запроса с тем же значением API возвращает ранее созданную сущность вместо создания ещё одной с идентичными полями.

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

Что сохранить до первого запроса

Рекомендуем формировать запись операции до отправки, а не только после успешного ответа. В ней нужны исходный идентификатор операции вашей системы, тип создаваемой сущности, выбранный syncId и тело запроса без секретов. После ответа добавьте фактический идентификатор объекта МоегоСклада.

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

Как принять повтор после таймаута

Разберите с интегратором одну реальную операцию, по которой уже есть журнал. Предлагаем такой порядок:

1. Найдите исходный запрос создания и сохранённый до него syncId.
2. Установите, был ли повтор и сохранил ли он то же тело и значение поля.
3. Сопоставьте возвращённый объект с исходной операцией по идентификатору и содержанию.
4. Проверьте в учёте, нет ли второго объекта, который создала другая попытка или другая система.
5. Зафиксируйте итог: один объект подтверждён либо конкретное расхождение требует разбора.

Не используйте рабочий учёт для произвольного эксперимента с дублирующим созданием. Сначала проверьте журнал существующего сбоя; если нужен воспроизводимый тест, согласуйте с разработчиком отдельные тестовые данные и условия.

Где заканчивается это правило

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

Обнаруженный дубль тоже требует отдельного решения. До удаления проверьте связи и последствия для учёта с ответственным сотрудником. Не назначайте новое значение поля только ради того, чтобы повтор «прошёл».

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