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

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

Что можно автоматизировать: карта задач

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

Остатки: главная точка отказа

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

Типичная схема:

1. 1Склад ведёт учёт по каждой единице и отдаёт количество по каждому артикулу в разрезе состояний.
2. 2Ваша система собирает из этих состояний «доступный к продаже» остаток.
3. 3Интеграция выгружает его на площадки, учитывая их ограничения по частоте запросов.
4. 4После каждого заказа остаток пересчитывается и выгружается снова.

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

Заказы FBS: от получения до отгрузки

Для FBS ценнее всего скорость реакции. Заказ, который лежит необработанным полчаса, съедает запас до среза отгрузки. Автоматизация здесь устроена так.

• Опрос площадки или приём уведомления о новом заказе.
• Создание задания на сборку на складе: артикул, количество, срок, требуемая маркировка.
• Получение этикетки и документов и передача их на печать.
• Подтверждение сборки и отгрузки обратно на площадку.

Срез отгрузки и правила переноса зависят от площадки, проверяйте актуальные требования в кабинете продавца. Подробнее про процесс сборки читайте в статье «Сборка заказов FBS», а про саму схему в материале «Что такое FBS».

Поставки FBO: заявка из вашей системы

С поставками на склад площадки автоматизация даёт меньше выгоды, чем с заказами, потому что частота ниже. Зато выигрыш по качеству данных высокий: если заявка на приёмку на склад фулфилмента создаётся из вашей системы, в ней нет опечаток в артикулах и количествах, а план поставки сразу совпадает с учётом. Через открытый API склада можно создать заявку на приёмку, получить подтверждение и отслеживать статусы приёма. Как правильно считать, сколько везти, смотрите в статье «Сколько товара везти на FBO».

Как устроить интеграцию со складом

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

Мы предоставляем открытый REST API v1.1 и вебхуки. Через них можно:

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

Вебхуки передают события в вашу систему, поэтому вам не нужно постоянно опрашивать склад. Кабинет селлера показывает данные почти в реальном времени (задержка около минуты), демо доступно без регистрации: seller.perfektpak.ru/demo.

Идентификаторы: то, на чём ломается большинство интеграций

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

Что стоит сделать до первого запроса к API:

1. 1Заведите единый справочник: внутренний артикул → артикулы на каждой площадке → штрихкоды.
2. 2Запретите повторное использование штрихкода для разных товаров, даже если площадка это допускает.
3. 3Для маркированных товаров храните отдельно связь «единица — код маркировки». Подробнее мы разбирали это в статье про вывод из оборота «Честный знак».
4. 4Проверяйте справочник при каждой новой карточке: нет ли дубля.

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

Что делать с ошибками и повторами

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

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

Безопасность доступа

Ключи доступа к API площадок и склада дают возможность менять остатки и цены. Относитесь к ним как к паролям.

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

Когда автоматизация не нужна

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

Что проверить у склада до подключения

Если вы выбираете фулфилмент и хотите интеграцию, задайте оператору конкретные вопросы:

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

Ответы «в разработке» и «по запросу» стоит записать и вернуться к ним до подписания договора, а не после запуска.

Пример сценария: один товар, три площадки

Условная ситуация. Селлер торгует аксессуарами для дома, ассортимент 120 артикулов, продаёт на Wildberries, Ozon и Яндекс Маркете. Склад один, остаток общий.

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

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

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

Порядок внедрения за четыре недели

1. 1Неделя 1. Опишите, где у вас источник правды по остаткам, ценам и заказам. Это бумага, а не код.
2. 2Неделя 2. Подключите песочницу склада, получите тестовые остатки и сверьте их с учётом.
3. 3Неделя 3. Запустите автоматическую выгрузку остатков на одну площадку и один небольшой ассортимент. Сверяйте результат ежедневно.
4. 4Неделя 4. Подключите заказы FBS и вебхуки. Расширьте ассортимент и площадки.

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

Расчёт: окупается ли автоматизация

Условный пример. Цифры выдуманы.

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

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

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

Вывод

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

Если вы хотите посмотреть, как это выглядит на практике, откройте демо кабинета, документацию API или условия на страницах FBO, FBS и цены.