Интеграция с маркетплейсами по API: заказы, остатки, статусы доставки

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

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

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

Что такое интеграция с маркетплейсами по API и кому она нужна?

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

Интеграция особенно нужна трём типам компаний:

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

Какие данные передаются: заказы, остатки, статусы

Интеграция — это не один поток, а несколько, и у каждого своя частота и цена ошибки:

Главное правило: заказы и остатки — критичные потоки, цены и отчёты — вспомогательные. Проектировать интеграцию начинают с первых двух.

Чем отличается интеграция для FBS, FBO и DBS?

Схема работы с площадкой определяет, какие данные нужны складу и насколько жёсткие у него сроки.

Для FBS и DBS интеграция — вопрос выживания: условия площадок меняются часто, и от скорости обмена зависит, уложится ли склад в срок. Пример таких изменений — новые правила Ozon для доставки до сортцентра.

Как устроена надёжная архитектура интеграции

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

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

Интеграция ценна не тем, что передаёт данные, а тем, что замечает, когда они перестали передаваться.

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

Где чаще всего ломается синхронизация?

• Лимиты запросов. У каждой площадки есть ограничения на число вызовов в секунду или минуту. Полная выгрузка остатков по тысячам позиций без очереди быстро упирается в отказ.
• Статус меняется между опросами. Если система опрашивает только «новые» заказы, а заказ за это время уже перешёл в «отменён», он может выпасть из учёта. Нужна выборка по периоду изменений, а не только по статусу.
• Истёкшие ключи. Токены живут ограниченный срок или отзываются при смене сотрудника. Срок действия стоит отслеживать заранее.
• Изменения API. Площадки выпускают новые версии методов и отключают старые. Без подписки на новости для разработчиков интеграция ломается внезапно.
• Комплекты и размеры. Один артикул площадки может соответствовать набору позиций на складе — без таблицы соответствия остатки считаются неверно.
• Резервы. Остаток для маркетплейса должен учитывать уже собранные, но не отгруженные заказы, иначе один товар продадут дважды.

Готовый коннектор или собственная разработка?

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

Как внедрить интеграцию по шагам

1. Опишите текущие процессы: откуда приходят заказы, кто и когда меняет статусы, где ведутся остатки.
2. Приведите в порядок справочник товаров: штрихкоды, артикулы площадок, комплекты.
3. Определите потоки и их приоритет: заказы и остатки — первыми.
4. Получите ключи API с минимально нужными правами для каждой площадки и каждого клиента.
5. Запустите обмен на тестовом наборе товаров и сравните данные с кабинетом вручную.
6. Переведите на интеграцию одну площадку, оставив ручной контроль на 1–2 недели.
7. Настройте мониторинг и ежедневную сверку, затем подключайте следующие площадки.

Чек-лист перед запуском

• Таблица соответствия артикулов площадок и номенклатуры склада заполнена.
• Остатки для площадок учитывают резервы и собранные заказы.
• Есть очередь запросов с повторами и учётом лимитов.
• Заказы забираются по периоду изменений, а не только по статусу «новый».
• Сроки действия ключей отслеживаются, ключи хранятся защищённо.
• Настроены оповещения о сбоях и ежедневная сверка.
• Назначен ответственный за обновления API площадок.

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

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

Что можно автоматизировать через API маркетплейса?

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

Как часто нужно обновлять остатки на маркетплейсах?

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

Нужна ли интеграция для работы по схеме FBO?

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

Что выбрать: готовый коннектор или собственную разработку?

Готовый коннектор подходит, если процессы типовые, площадок одна-две, а заказов — сотни в день. Собственный интеграционный слой оправдан при нескольких клиентах на одном складе, своей WMS или TMS, нестандартной комплектации и больших объёмах, когда ошибки синхронизации стоят дороже разработки.

Сколько занимает внедрение интеграции?

Подключение готового коннектора — от нескольких дней. Собственная интеграция с одной площадкой по заказам и остаткам обычно занимает несколько недель, включая тестирование на реальных данных. Каждая новая площадка и каждая дополнительная система (1С, WMS, TMS) добавляют время.