API Wildberries и Ozon: как подключить каталог и заказы к своему приложению

Ты продаёшь на Wildberries и Ozon и каждое утро открываешь два личных кабинета подряд: проверяешь остатки, сверяешь цены, смотришь новые заказы. Потом переписываешь важные цифры в Excel или блокнот, чтобы не перепутать одну площадку с другой. Рано или поздно приходит мысль: а нельзя ли собрать всё в одном месте — своём дашборде, боте в Telegram, скрипте, который сам присылает уведомление о новом заказе или падении остатка ниже критичного уровня? Можно. Для этого у обеих площадок есть API — способ, которым твоя собственная программа обращается напрямую к тем же данным, что видны в личном кабинете, и обрабатывает их так, как удобно именно тебе.

Здесь важно сразу развести два разных сценария. Один — построить интернет-магазин с нуля: свой сайт, своя корзина, своя оплата. Этот путь разобран в статье «Как создать интернет-магазин с ИИ». Другой сценарий — тот, о котором эта статья: у тебя уже есть готовый личный кабинет продавца на Wildberries или Ozon, готовый каталог, готовая логистика площадки. Твоё приложение не заменяет кабинет и не встаёт вместо него — оно достраивается поверх, забирает данные через API и показывает их в удобном тебе виде, снимая часть рутины, которую иначе пришлось бы делать руками.

Зачем продавцу своё приложение поверх кабинета маркетплейса

Личный кабинет продавца создан так, чтобы охватить всех: тысячи разных селлеров, разные категории товаров, разные объёмы. Универсальность имеет цену — интерфейс редко подстраивается под конкретную задачу конкретного продавца. Если тебе нужно видеть остатки сразу по двум площадкам на одном экране, сравнивать динамику цен день к дню или получать сообщение в Telegram в момент, когда товар заканчивается, — стандартный кабинет для этого не предназначен. Он показывает то, что есть, но не то, что тебе конкретно нужно и как тебе нужно.

API закрывает именно этот разрыв. Через него можно:

• собрать один дашборд с остатками и заказами сразу с двух площадок, без переключения вкладок;
• настроить уведомление в свой Telegram-бот, когда пришёл новый заказ или остаток товара упал ниже порога;
• сверять цены между Wildberries и Ozon автоматически, вместо ручной таблицы;
• выгружать статистику продаж в удобном для себя формате — например, в собственный отчёт, а не в стандартную выгрузку кабинета;
• синхронизировать остатки между площадками, чтобы не продать один и тот же товар дважды, если склад общий.

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

Что такое API Wildberries и Ozon простыми словами

API расшифровывается как Application Programming Interface — программный интерфейс приложения. Если совсем просто: это набор правил, по которым одна программа может попросить другую сделать что-то и получить ответ, без участия человека за экраном. Подробно принцип запроса-ответа, JSON и HTTP-методов разобран в статье «Что такое API» — если тема совсем новая, начни оттуда.

У Wildberries и Ozon API устроен по общему для всей индустрии принципу: твоя программа отправляет HTTP-запрос на определённый адрес, добавляет токен доступа в заголовок запроса, а площадка возвращает ответ в формате JSON — структурированный текст, который легко разобрать программой. Через такие запросы можно получить список товаров, текущие остатки на складах, статусы заказов, историю продаж, а некоторые запросы позволяют не только читать данные, но и менять их — например, обновлять цену или отправлять карточку товара.

Разница между API маркетплейса и обычным сайтом кабинета в том, для кого они сделаны. Сайт создан для человека — с кнопками, формами и визуальным интерфейсом. API создан для программ — он не показывает ничего глазами, а только принимает и отдаёт данные по строгим правилам. Твоё приложение и есть тот самый «человек», которому вместо сайта показывают сырые данные, а красивый экран ты рисуешь уже сам.

Как получить токен доступа

Токен — это длинная случайная строка, которая заменяет логин и пароль при обращении программы к сервису. Без токена API не станет с тобой разговаривать: он не понимает, кто ты и есть ли у тебя право смотреть эти данные.

Где искать раздел API в личном кабинете

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

Общий сценарий получения токена почти всегда выглядит так:

1. Заходишь в личный кабинет продавца под своей учётной записью.
2. Находишь раздел, отвечающий за доступ к API или интеграции.
3. Создаёшь новый токен и выбираешь, к каким разделам данных он получит доступ.
4. Копируешь готовый токен — обычно площадка показывает его только один раз, сразу после создания.
5. Сохраняешь токен в защищённом месте — не в переписке, не в открытом текстовом файле на рабочем столе.

Права доступа — выдавай только нужное

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

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

Проверь токен одним простым запросом

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

Меняй токен, если он где-то засветился

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

Чем отличаются API Wildberries и Ozon

Общий принцип у площадок один: HTTP-запросы с токеном в заголовке и ответ в формате JSON. Но в деталях они расходятся, и это нормально — у каждой площадки своя история развития API, своя команда разработчиков и своя документация.

Документация. У Wildberries и Ozon отдельные порталы документации для продавцов-разработчиков, со своей структурой разделов, своими примерами запросов и своим стилем изложения. Прежде чем писать хоть один запрос, стоит открыть актуальную документацию нужной площадки и свериться с ней напрямую — не с чужой статьёй или устаревшим форумным постом, а с официальным источником, который обновляется вместе с самим API.

Структура ответов. Формат JSON общий для обеих площадок, но конкретные названия полей, вложенность данных и логика группировки различаются. Ответ на запрос об остатках у Wildberries и у Ozon будет выглядеть по-разному даже для одинаковой по смыслу информации — те же данные, но упакованные каждой площадкой по-своему.

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

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

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

Коротко в одной таблице — что стоит держать в голове при переключении между площадками:

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

Как это выглядит технически: путь одного запроса

Если разложить весь процесс на шаги, картина простая и одинаковая что для Wildberries, что для Ozon, что для любого другого API с токен-аутентификацией.

flowchart TB
    A["Личный кабинет продавца"] --> B["Раздел API-ключей"]
    B --> C["Токен с нужными правами"]
    C --> D["Запрос от твоего приложения"]
    D --> E["Ответ от API площадки в JSON"]
    E --> F["Обработка и показ в своём дашборде"]

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

Что реально можно автоматизировать

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

Остатки на складах

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

Цены

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

Статусы заказов

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

Статистика продаж

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

Синхронизация между площадками

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

Несколько кабинетов под одним приложением

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

Во всех этих сценариях приложение не принимает решения за тебя — оно снимает с тебя рутину сбора и сведения данных, а решения по ценам, остаткам и заказам всё равно остаются твоими.

Как протестировать первый запрос, не рискуя боевыми данными

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

Практический порядок такой:

1. Сначала — запрос на чтение небольшого объёма данных, например список из нескольких товаров, и внимательная проверка того, что пришло в ответе.
2. Логирование ответа целиком, хотя бы во время отладки, — так проще увидеть, действительно ли данные соответствуют тому, что ты видишь в личном кабинете глазами.
3. Только после того как чтение стабильно работает и понятно, как устроен ответ, — переход к более сложным запросам, если задача действительно требует не только читать, но и изменять данные, например обновлять цену.
4. Для запросов, которые что-то меняют, — обязательная проверка на одном-двух товарах вручную, прежде чем запускать логику на весь каталог сразу.

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

Где хранить токен безопасно

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

Правильный подход — переменные окружения и файл .env, который никогда не попадает в публичный код. Подробно о том, как устроено такое хранение, что делать, если токен всё-таки утёк, и почему нельзя коммитить секреты в Git, разобрано в статье «Хранение секретов и токенов». Если ты собираешь приложение с помощью Claude Code, тот же принцип: попроси хранить токен в .env, а не вписывать его прямо в код запроса.

Типичные ошибки новичка

Упереться в лимит запросов

У любого API есть ограничение на количество запросов за единицу времени — это защищает инфраструктуру площадки от перегрузки. Если приложение опрашивает API слишком часто, ты рано или поздно увидишь ошибку о превышении лимита. Это не поломка, а нормальная защитная реакция сервиса. Что означает такая ошибка и как с ней работать — разобрано в статье «Ошибка API rate limit exceeded»: коротко, решение почти всегда сводится к тому, чтобы запрашивать данные не чаще, чем реально нужно, и не долбить API в цикле без пауз.

Перепутать песочницу и боевой токен

У части API-платформ есть тестовый режим — «песочница», sandbox — с отдельным набором токенов и тестовыми данными, не связанными с реальным кабинетом. Он существует именно для того, чтобы можно было проверить код, не рискуя настоящими заказами и ценами. Ошибка новичка — перепутать тестовый токен с боевым или наоборот, и получить либо пустые данные там, где ждал реальные, либо, что хуже, случайно применить тестовый скрипт к боевым данным. Перед первым запуском стоит явно проверить в документации площадки, какой токен ты используешь и что именно он затрагивает.

Доверять устаревшей документации

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

Хранить токен там, где его увидят посторонние

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

Как попросить Claude Code написать первый запрос

Если ты проходишь курс и пишешь код промптами, а не руками, для первого запроса к API маркетплейса не нужно разбираться в синтаксисе самому — нужно точно сформулировать задачу. Хороший промт для Claude Code обычно включает:

• какую площадку и какой раздел API ты хочешь использовать (например, «остатки товаров через Wildberries API»);
• ссылку на актуальную официальную документацию нужного раздела, если она у тебя открыта;
• где взять токен — попроси читать его из переменной окружения, а не вписывать в код;
• что сделать с полученными данными — вывести в консоль, сохранить в файл, показать в интерфейсе;
• как обработать ошибку, если запрос не прошёл — например, вывести понятное сообщение вместо падения всего скрипта.

Пример формулировки: «Напиши функцию, которая делает GET-запрос к разделу остатков Wildberries API, документация здесь [ссылка]. Токен бери из переменной окружения WB_API_TOKEN. Если запрос вернул ошибку, выведи понятное сообщение вместо необработанного исключения. Результат выведи в консоль в виде таблицы: артикул, название, остаток».

Такой промт даёт ИИ-ассистенту всё необходимое: источник правды по формату запроса (документация), безопасный способ передать токен и понятное поведение при ошибке. Дальше, когда первый запрос заработает, точно так же формулируешь следующий шаг — обработку ответа, сохранение данных, отображение в интерфейсе.

Нужен ли для этого программист

До появления ИИ-ассистентов, которые пишут код по текстовой задаче, интеграция с API маркетплейса почти всегда означала найм разработчика — либо в штат, либо на разовый проект. Для небольшого продавца это выглядело несоразмерно: платить за месяц работы программиста ради дашборда с остатками, которым будешь пользоваться сам каждый день.

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

Частые вопросы

Нужно ли уметь программировать, чтобы подключить своё приложение к API Wildberries или Ozon?

Писать код руками — нет, если ты работаешь с ИИ-ассистентом вроде Claude Code, который пишет запросы по твоим текстовым задачам. Но полезно понимать общий принцип: что такое токен, запрос, ответ и JSON — тогда проще формулировать задачи точно и быстрее разбираться, если что-то работает не так, как ожидалось.

Платный ли доступ к API Wildberries и Ozon?

Условия доступа к API у обеих площадок могут меняться со временем и зависят от статуса продавца. Актуальные условия смотри непосредственно в личном кабинете продавца или в официальной документации конкретной площадки — устаревшие сведения из сторонних статей здесь легко ввести в заблуждение.

Ozon требует какой-то дополнительный идентификатор, кроме токена, — это нормально?

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

Безопасно ли давать ИИ-ассистенту доступ к моему токену продавца?

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

Можно ли одним приложением работать сразу с Wildberries и Ozon?

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

С чего начать, если раньше никогда не работал с API маркетплейсов?

Начни с чтения официальной документации нужной площадки и статьи «Что такое API», если базовые понятия пока не устоялись. Дальше — получи токен с минимально необходимыми правами и попроси ИИ-ассистента написать самый простой запрос, который просто читает данные и выводит их в консоль. Только после того как этот шаг заработает и понятен, имеет смысл усложнять — добавлять обработку ошибок, сохранение данных и отображение в собственном интерфейсе.

Можно ли доверить приложению автоматическое изменение цен без проверки человеком?

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

Заключение

API Wildberries и Ozon не заменяют личный кабинет продавца — они открывают к тем же данным ещё один вход, программный, через который можно построить своё приложение поверх готовой площадки: дашборд с остатками, уведомления о заказах, сведение цен в одну таблицу. Начинается всё с токена, выданного с ограниченными правами, и одного простого запроса на чтение, который ничего не ломает. Дальше — по одному шагу за раз, сверяясь с официальной документацией каждой площадки и держа токен там, где ему положено быть — в защищённой переменной окружения, а не в тексте кода. Личный кабинет продавца при этом никуда не девается — он остаётся источником истины, а твоё приложение лишь снимает часть рутины, которую иначе пришлось бы делать руками каждый день.