Интеграция с API маркетплейсов связывает ваш склад, учётную систему и личные кабинеты на Ozon, Wildberries и Яндекс Маркете. Программа сама забирает новые заказы, отправляет на площадки остатки и цены и возвращает статусы отгрузок. Менеджеры перестают переносить данные вручную, а продавец реже ловит отмены из-за товара, которого уже нет на складе.
Ниже разберём, какие данные передают через API, чем отличается обмен по схемам FBS и FBO, как устроен проект интеграции и на каких местах он обычно спотыкается.
Зачем подключаться к API, если есть личный кабинет
Личный кабинет продавца удобен, пока товаров мало и площадка одна. Когда позиций сотни, а площадок две или три, ручная работа превращается в отдельную должность: выгрузить заказы, сверить остатки, поменять цены в трёх кабинетах, загрузить файлы с карточками.
Ручной обмен даёт типичные потери:
• Товар продали на одной площадке, а на другой он ещё числится в наличии. Покупатель оформляет заказ, вы его отменяете, площадка снижает рейтинг магазина.
• Цену поменяли в учётной системе, но забыли в одном из кабинетов.
• Заказы попадают в учёт с опозданием, и склад собирает их в последний момент.
• Данные о продажах и комиссиях приходится сводить в таблицах по выгрузкам.
API (программный интерфейс площадки) убирает эти шаги. Ваша система обменивается данными с маркетплейсом напрямую, по расписанию или по событию.
Какие данные передают через API маркетплейсов
У каждой площадки свой набор методов, но задачи у продавцов похожие.
Остатки
Самый важный поток. Система берёт остаток из учёта (1С, складской программы, своей базы), учитывает резервы и отправляет на каждую площадку. Здесь же задают правила: например, держать неприкосновенный запас или показывать на площадке не весь остаток склада.
Заказы и статусы
Система забирает новые заказы, создаёт их в учёте, передаёт на сборку, а затем отправляет на площадку статусы: собран, передан в доставку, отменён. Для схемы FBS сюда же входит печать этикеток и формирование поставок.
Цены и акции
Цены рассчитывают в одном месте и рассылают на площадки. Часто добавляют правила: минимальная цена, наценка от закупки, участие в акциях площадки по заданным условиям.
Карточки товаров
Создание и обновление карточек через API требует сопоставить ваши характеристики со справочниками площадки. Это самая трудоёмкая часть, поэтому её часто выносят в отдельный этап.
Финансы и аналитика
Отчёты о продажах, комиссиях, возвратах и выплатах можно забирать автоматически и сводить в учёте или в аналитической системе.
FBS, FBO и другие схемы: что меняется в интеграции
Схема работы с площадкой определяет, какие данные вам нужны.
• FBS: товар хранится у вас, вы собираете заказ и передаёте его маркетплейсу. Здесь критичны остатки, быстрый приём заказов, этикетки и статусы сборки.
• FBO: товар лежит на складе маркетплейса, площадка сама собирает и доставляет. Интеграция нужна для планирования поставок, учёта остатков на складах площадки и финансовых отчётов.
• Доставка силами продавца (у площадок называется по-разному): вы храните и сами везёте заказ покупателю. Добавляются статусы доставки и обмен с курьерской службой.
Многие продавцы совмещают схемы. Тогда интеграция должна разделять остатки: что лежит у вас, а что уже отгружено на склад площадки.
Как устроен проект интеграции
1. Описание процессов
Аналитик фиксирует, кто сейчас что делает: где ведут остатки, кто меняет цены, как заказ доходит до склада. Отдельно выписывают исключения: возвраты, частичные отмены, комплекты, товары с серийными номерами.
2. Выбор архитектуры
Есть три распространённых варианта:
• Модуль внутри учётной системы, например доработка 1С, которая обращается к API площадок.
• Отдельный сервис интеграции между учётом и маркетплейсами. Его проще развивать, если площадок несколько или учётная система не одна.
• Готовый коннектор или сервис-агрегатор с настройкой под ваши правила.
Выбор зависит от объёма заказов, числа площадок и того, насколько ваши правила отличаются от типовых. Для нестандартного ценообразования и сложных складов чаще делают свой сервис.
3. Сопоставление справочников
Ваши артикулы, склады, статусы и характеристики сопоставляют с идентификаторами площадки. Ошибки на этом шаге потом выглядят как «пропавшие» остатки и заказы.
4. Разработка и тестирование
Разработчики подключают методы API, настраивают расписание и обработку ошибок. Тестируют на реальных данных с ограниченным набором товаров: сначала остатки, потом заказы, потом цены.
5. Запуск и мониторинг
После запуска нужен журнал обмена и уведомления о сбоях. Если площадка не приняла остатки или заказ не загрузился, ответственный сотрудник должен узнать об этом сразу, а не от покупателя.
Типичные ошибки и как их избежать
• Не учитывают лимиты запросов. У каждой площадки есть ограничения на число обращений к API, и при большом каталоге обмен «упирается» в них. Решение: передавать остатки пакетами и только изменившиеся позиции.
• Забывают про резервы. Остаток на складе и остаток, который можно продать, отличаются на величину собранных, но не отгруженных заказов.
• Нет обработки изменений API. Площадки выпускают новые версии методов и отключают старые. Кто-то должен следить за объявлениями в документации и обновлять интеграцию.
• Ключи доступа лежат у одного сотрудника. Ключи API создают в кабинете продавца; их стоит хранить в защищённом месте и выпускать с минимально нужными правами.
• Нет ручного режима. На случай сбоя нужен понятный порядок: кто и как обновляет остатки вручную, пока обмен не восстановлен.
Официальная документация площадок открыта: например, Ozon Seller API и API Wildberries. Начинать проект стоит с неё: она показывает, какие операции площадка разрешает автоматизировать.
Частые вопросы
Можно ли подключить сразу несколько маркетплейсов?
Да. Обычно делают единый модуль обмена, где у каждой площадки свой адаптер. Остатки и цены рассчитываются в одном месте, а адаптеры переводят данные в формат конкретной площадки.
Обязательно ли дорабатывать 1С?
Нет. Если учёт ведётся в 1С, интеграцию можно встроить в неё или сделать отдельный сервис, который читает данные 1С. Отдельный сервис удобнее, когда площадок несколько или нужна своя логика цен.
Как часто обновлять остатки?
Чем чаще меняются остатки и чем больше у вас каналов продаж, тем короче интервал. Частоту выбирают с учётом лимитов API площадки и передают только изменившиеся позиции.
Что делать, если площадка поменяла API?
Площадки заранее публикуют изменения и сроки отключения старых методов. За этим следит подрядчик на сопровождении или ваш разработчик, а обновление закладывают в план работ.
Подходит ли готовый коннектор?
Для типовой схемы с одной учётной системой и стандартными правилами часто подходит. Если нужны свои правила цен, сложные склады или связь с несколькими системами, готовое решение придётся сильно настраивать, и свой сервис может оказаться проще.
Что ещё почитать
• Техническое задание на разработку ПО: что включить и как не ошибиться
• Кейс «Твой бокс»: автоматизация работы продавца на Авито
• Разработка Telegram-бота для бизнеса: этапы и что нужно от заказчика
Мы разрабатываем сервисы и интеграции под процессы продавца: обмен с площадками, учётными системами и внутренними инструментами. Похожую задачу мы решали для продавца на Авито, где объединили автоответы, массовые публикации и данные по объявлениям в одном кабинете. Подробнее о том, как мы работаем, на странице веб-разработки. Чтобы обсудить вашу интеграцию, оставьте заявку.