Песочница Seller API Ozon позволяет проверить сценарии доставки в отдельной среде. В инструкции от 19 октября 2026 года площадка описывает работу с остатками, заказами, отменами и отправлениями. Это полезный контур для проверки интеграции, но успешный тест нужно оценивать в пределах поддерживаемых сценариев: он не означает, что проверены все функции магазина и любой метод Seller API.

Сначала определите, какую доставку тестируете

В текущем описании Sandbox предназначен для Ozon Доставки для продавцов. Изменения в нём не видны покупателям; доступ указан как бесплатный и не ограниченный по времени. При этом для использования соответствующих методов в рабочей среде требуется подключить Ozon Доставку. Возможность выполнить тест не заменяет такое подключение.

Не смешивайте его с Delivery API для бизнеса или с песочницей Ozon ОРД. У этих продуктов разные задачи. Перед началом разработчик и заказчик должны одинаково понимать, какую систему внедряют, какие реальные операции она впоследствии будет выполнять и где проходит граница испытания.

Разделите приложения, секреты и адреса среды

Ozon описывает получение доступа через приложение и OAuth 2.0 Client Credentials Flow. Для теста используется специальный секрет Sandbox; идентификатор приложения общий. Частное приложение получает доступ к песочнице сразу, а коммерческому нужен статус «Проверено» или выше. Само наличие учётной записи разработчика ещё не доказывает готовность нужного приложения.

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

Проверяйте связанный сценарий, а не один ответ

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

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

Отдельно оформите переход в рабочий контур

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

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