Интеграция с API маркетплейсов: что подключают в первую очередь

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

Зачем подключать API маркетплейса, а не работать через личный кабинет

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

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

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

Остатки и цены - с чего начинается любая интеграция с маркетплейсами

Первое, что я настраиваю клиентам - синхронизацию остатков и цен между учётной системой продавца и карточками на площадке. Логика простая: если на сайте или в 1С осталось 2 штуки, а на Wildberries висит остаток 20, площадка продолжает принимать заказы, которые нечем закрыть. Итог - отмены, штрафы за срыв поставки и просевший рейтинг карточки.

Обратная синхронизация цен работает так же: акция на сайте или изменение прайса у поставщика должны долетать до маркетплейса без ручного пересчёта на каждой площадке отдельно. На практике завожу отдельный сервис-посредник (либо задачу в n8n, либо очередь в бэкенде), который раз в 15-30 минут забирает остатки из источника правды - обычно это 1С или база интернет-магазина - и отправляет обновления по API на все подключённые площадки. Частоту синхронизации подбираю под оборачиваемость: для товаров с высоким спросом интервал короче, для медленных позиций хватает нескольких раз в день.

FBO и FBS: остатки считаются по-разному

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

Заказы, статусы и вебхуки: обработка в реальном времени

Второй блок - приём заказов и отслеживание статусов. У большинства площадок это устроено через вебхуки (площадка сама стучится на ваш эндпоинт при новом заказе или смене статуса) либо через периодический опрос списка заказов. Второй вариант надёжнее с точки зрения проекта: если вебхук один раз не долетел, заказ просто потеряется, а опрос по расписанию подхватит всё, что изменилось.

Дальше заказ нужно куда-то положить - в CRM, в 1С, в админку продавца. И почти всегда клиенты просят уведомление о новом заказе не на почту, а в мессенджер, тут ставлю простого бота на aiogram, который присылает в рабочий чат номер заказа, состав и сумму сразу после того, как обработчик на бэкенде забрал данные по API. Отдельно слежу за статусами отмен и возвратов - это тот вид событий, который чаще всего забывают синхронизировать, а потом склад числится не в фазе с тем, что видит площадка.

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

Логистика FBS и доставка: что отдают через API

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

Здесь удобно опираться на готовый бэкенд, а не собирать логику из отдельных скриптов на коленке: слишком много статусов и веток (отмена до сборки, отмена после отгрузки, частичная отмена позиций), чтобы держать это в голове. Если задача упирается в отдельный бэкенд на Laravel с очередями и логикой повторных попыток при сбое API площадки, обычно так и поступаю - разовый скрипт для такого объёма веток быстро превращается в источник багов.

Возвраты через FBS обычно требуют отдельной обработки: площадка присылает заявку на возврат, нужно подтвердить приёмку и провести её в учётной системе, иначе товар зависает и не попадает обратно в остатки. У продавцов, которые совмещают FBS и продажи через свой сайт, эта логика обычно завязана на тот же бэкенд, что и обработка возвратов с сайта - дублировать её отдельно под каждый канал смысла нет.

Финансовые отчёты, комиссии и сверка с 1С

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

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

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

Сколько стоит и как долго делается интеграция API маркетплейса

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

Какой вариант выбрать - n8n или собственный бэкенд - зависит от объёма заказов и количества площадок. Для одного-двух каналов и нескольких сотен заказов в месяц n8n обычно достаточно, но готовых узлов под Ozon, Wildberries и Яндекс Маркет в нём нет: в официальном перечне встроенных app-нод их не значится, запросы собираются универсальной нодой HTTP Request, которая умеет обращаться к любому сервису с REST API. Сборка такого сценария всё равно быстрее, чем разработка бэкенда с нуля. Когда каналов становится больше трёх или в процесс включается сверка с 1С и возвратами, чаще перехожу на отдельный бэкенд - в n8n такую логику становится тяжело поддерживать и отлаживать.

Вот с чем реально работаю по этой теме и какие на это расценки:

Из этих задач n8n-связку собираю быстрее всего - за несколько дней, потому что там нет своей базы и очередей, только цепочка HTTP-запросов к API площадок. Бэкенд на Laravel с очередями, повторными попытками и сверкой с 1С занимает заметно больше - обычно от трёх-четырёх недель, и львиная доля времени уходит не на сам обмен данными, а на обработку краевых случаев в статусах заказов и возвратов.

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

С какого API маркетплейса начать, если продаю на нескольких площадках сразу?

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

Нужен ли отдельный сервер для интеграции с API маркетплейса?

Для обработчика, который раз в 15-30 минут забирает остатки и заказы по расписанию, хватает обычного хостинга с PHP и MySQL - такой скрипт не требует постоянно работающего процесса. Отдельный сервер понадобится, если нужна обработка вебхуков в реальном времени через очередь задач - тогда это уже VPS с постоянно запущенным воркером, который придётся администрировать и оплачивать отдельно от хостинга сайта.

Как часто нужно синхронизировать остатки, чтобы не уходить в минус?

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

Можно ли подключить API маркетплейса самостоятельно, без разработчика?

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