Ozon Delivery API для бизнеса: как проверить путь заказа от создания до отмены
Как подготовить интеграцию Ozon Доставки для бизнеса: частное приложение, создание заказа, этикетка и сверка статусов без ручного переноса данных.
Содержание статьи
Ozon Delivery API позволяет передавать заказы интернет-магазина в Ozon Доставку для бизнеса и получать данные обратно. В объявлении от 20 августа 2026 года компания описала создание заказов, получение этикеток, расчёт доставки и отслеживание статусов. Практическая задача интеграции — провести один заказ через весь процесс и не потерять связь между магазином, доставкой и складом.
Что подключается и где начать
Ozon указал путь настройки: в личном кабинете Доставки открыть «Управление частными приложениями» и создать приложение с необходимыми интеграциями. Речь идёт о Delivery API для бизнеса. Не следует автоматически переносить сюда методы Seller API или настройки других вариантов доставки: назначение и доступы нужно проверять в документации выбранного продукта.
Объявление подтверждает возможности, но не содержит полную техническую спецификацию. Имена методов, формат авторизации, ограничения запросов и обработку ошибок разработчик должен брать из действующей документации, а не восстанавливать по описанию новости.
Составьте карту одного заказа
До разработки определите, где возникает заказ, кто подтверждает его готовность и какая система хранит исходный состав. Для каждого этапа задайте событие и ответственного: создание, получение этикетки, передача в логистику, изменение статуса и отмена. Это проектирование вашего процесса, а не перечень обязательных статусов Ozon.
Сохраните связь внутреннего номера магазина с идентификатором, который вернёт доставка. Она потребуется для поиска расхождений и общения с поддержкой. Номер нельзя заменять временем запроса: повторная отправка после сбоя должна оставаться распознаваемой как работа с тем же заказом.
Что проверить до массового включения
Проведите разрешённый условиями сервиса тест на небольшом объёме. Проверьте, что состав и адрес переданы без потерь, этикетка относится к нужному отправлению, а статус обновляется у того заказа, который видит сотрудник магазина. Отдельно изучите поведение при неполном ответе и временной недоступности связи.
Не считайте любой тайм-аут доказательством, что заказ не создан. Прежде чем повторять операцию, определите предусмотренный документацией способ проверки результата. Такой подход помогает избежать двух отправлений по одной покупке, но конкретная реализация зависит от возможностей API.
Как принять отмену и контролировать обмен
Отмена в магазине и подтверждение отмены логистической системой — разные события. В тестовом сценарии сотрудник должен видеть, принято ли изменение второй системой, или ещё требуется действие. Доступность отмены на конкретном этапе нельзя предполагать без проверки правил сервиса.
После запуска следите за очередью ошибок, отсутствующими этикетками и заказами без обновления статуса. Назначьте человека, который разбирает исключения, пока автоматизация работает с обычными заказами. Критерий готовности — прослеживаемый путь заказа и понятное восстановление после сбоя. Если нужен готовый коннектор для продавца маркетплейса, отдельно рассмотрите подключение через ApiShip: это другой вариант интеграции.
Материал отражает сведения на указанную дату. Правила и условия работы площадок могут измениться. Редакционные принципы