Частное приложение Ozon подходит для интеграции под конкретного продавца без размещения решения в публичном магазине приложений. Владелец магазина определяет разрешённые операции, а разработчик получает доступ к настройкам приложения. Это позволяет разделить управление магазином и техническую работу. Ниже разобрана процедура из официального руководства Ozon for dev от 29 октября 2025 года, проверенного при подготовке материала 27 октября 2026 года.

Согласуйте задачу до создания приложения

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

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

Проверьте, кому и к какому приложению выдали разрешение

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

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

Принимайте OAuth-подключение по рабочему результату

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

Не переносите автоматически на OAuth процедуру замены обычного API-ключа. Срок действия новых ключей Seller API описывает отдельный механизм. Разработчик должен документировать именно используемый способ авторизации: где хранится конфигурация, как обновляется доступ и что происходит при отзыве. Детали текущей реализации сверяются с документацией приложения, а не с общими советами про любые токены.

Завершите передачей сопровождения

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

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