Ozon Seller API: какие данные даёт, лимиты и что автоматизировать первым

Магазин вырос до сотни SKU, и вечер уходит на то, чтобы скачать три отчёта, свести их в таблицу и вручную поправить остатки FBS. Кто-то из знакомых продавцов говорит: «Подключи API, и всё будет само». Звучит как волшебная кнопка, но на деле это просто другой вход в тот же магазин — для программ, а не для людей.

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

Seller API простыми словами

Кабинет Ozon Seller — это экран для человека: кнопки, таблицы, фильтры. API — тот же магазин без экрана. Программа отправляет запрос вида «дай отправления FBS за вчера» и получает ответ в машинном формате, который дальше можно положить в таблицу, учётную систему или базу данных.

Чтобы программа могла обращаться к магазину, в кабинете создают API-ключ, а к нему прилагается Client-Id — номер вашего кабинета. Пара «Client-Id плюс ключ» работает как пропуск: у кого она есть, тот действует от имени магазина в пределах прав, выданных ключу.

Сам продавец с API напрямую обычно не работает. Через него к магазину подключаются учётные системы, сервисы аналитики, скрипты в таблицах и собственные программы. Но понимать, что там внутри, стоит любому, кто выдаёт кому-то ключ или платит за интеграцию.

Какие данные можно читать и что можно менять

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

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

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

Расхождение в 37 рублей, которое стоит 74 000

Представьте: скрипт выгрузил через API операции за месяц, их 2 000, и собрал отчёт, где прибыль магазина — 240 000 ₽. Для проверки вы взяли одну продажу и пересчитали её вручную по отчёту в кабинете. Разница — 37 ₽. На фоне 240 000 ₽ это выглядит как округление.

Но формула в скрипте одна на все строки. Если она, например, берёт цену до скидки вместо цены продажи или не видит обратную логистику, ошибка повторится в каждой операции: 37 × 2 000 = 74 000 ₽. Это почти треть прибыли в отчёте, и на такой базе вы будете решать, куда вкладывать деньги.

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

Сверка до автоматизации: исходник, итог и одна операция

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

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

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

Чего в Seller API нет

Рекламы. Статистика трафаретов, продвижения и управление кампаниями живут в отдельном Performance API со своим доступом. Если вы хотите видеть ДРР рядом с продажами, придётся подключать оба и склеивать данные по SKU.

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

Ваших расходов вне площадки. Закупку, доставку до склада, упаковку, зарплату и налог API не знает. Готовой «чистой прибыли» в нём нет и быть не может — есть сырьё, из которого её собирают.

Лимиты, страницы и отчёты по запросу

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

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

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

Что автоматизировать первым: от боли, а не от возможностей

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

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

Кто будет писать и поддерживать интеграцию

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

Посчитайте на своих цифрах. Допустим, остатки FBS вы обновляете вручную дважды в день по 20 минут — это 20 часов в месяц. Если ваш час стоит 800 ₽, ручная работа обходится в 16 000 ₽ в месяц. Разработчик берёт условные 2 000 ₽ в час, делает интеграцию за 16 часов — 32 000 ₽ — и тратит 2 часа в месяц на поддержку, ещё 4 000 ₽.

Экономия — 16 000 − 4 000 = 12 000 ₽ в месяц, вложения окупаются за 32 000 / 12 000 ≈ 2,7 месяца. Если бы ручная работа занимала пять часов в месяц, та же интеграция не окупилась бы никогда, и честнее было бы оставить таблицу.

Отдельно договоритесь, кто чинит интеграцию, когда Ozon выпускает новую версию метода и отключает старую. Такое происходит регулярно и с предупреждением, но предупреждение надо кому-то читать.

Задание разработчику пишите от результата, а не от методов: «каждые 15 минут передавать в Ozon остаток со склада учёта по списку артикулов, при ошибке писать в лог и присылать сообщение». Методы он подберёт сам, а ваша часть — правила: что считать доступным остатком, что делать при сбое, кто получает уведомление.

Как понять, что интеграция тихо сломалась

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

Минимальный лог — дата и время запроса, метод, код ответа и число полученных записей. Добавьте на дашборд или в таблицу строку «данные обновлены в …», и вы с первого взгляда заметите, что обновление остановилось.

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

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

FAQ

Что такое Ozon Seller API и зачем он продавцу?

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

Сколько стоит доступ к Ozon Seller API?

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

Можно ли работать с API Ozon без программиста?

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

Чем Seller API отличается от Performance API?

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

Почему данные из API не совпадают с кабинетом?

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