В документации международного WB API на домене .cn удаление предусмотрено для активной поставки без сборочных заданий. Это узкая операция очистки структуры отгрузок. Её нельзя использовать как замену отмене заказов или считать способом стереть историю уже выполненной работы. Ниже — редакционный план контроля такой операции для интеграции с указанным контуром.

Определите причину удаления

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

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

Защитите проверку от параллельной сборки

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

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

Разберите ответ без потери следов

Для описанного удаления документация указывает успешный ответ 204, а наличие заказов — как причину 409. Не помечайте запись удалённой ещё при нажатии кнопки. Сначала получите и сохраните результат действия, связанный с тем идентификатором, который сотрудник подтвердил.

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

Сохраните рабочую историю

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

Для приёмки реализации проверьте три сценария: действительно пустой объект, объект с заказами и изменение состава между проверкой и действием. Ожидаемый результат — предсказуемая очистка без потери заказов и ложных отметок об успехе. Применимость описания к другим доменам и договорам WB нужно устанавливать отдельно: эта статья не переносит международный контракт API на российский кабинет.