Интеграция сайта с Wildberries: товары, цены, остатки и аналитика
Что важно знать
- До кода определите владельца каждого поля: где главные название, цена, остаток и статус.
- Используйте только официальный WB API, доступные категории методов и выданные права.
- Токены и секреты хранят на сервере, разделяют по окружениям и выдают с минимальными полномочиями.
- Интеграция обязана учитывать лимиты, повторы, идемпотентность, очереди и журнал ошибок.
- Персональные данные и маркетинговая база не являются задачей товарной синхронизации.
- Запускайте потоки поэтапно и сверяйте бизнес-результат, а не только статус HTTP.
Сначала процесс, затем список методов API
Формулировка «связать сайт с WB» слишком широка. Выпишите реальные процессы: создать карточку из PIM, обновить остаток после продажи, сверить цену, получить отчёт, отследить поставку или собрать операционную аналитику. Для каждого процесса укажите направление, частоту, допустимую задержку и действие при ошибке. Только после этого выбирают методы API.
Официальная документация Wildberries делит API на категории: товары, заказы разных моделей, поставки, продвижение, тарифы, аналитика, отчёты, общение и документы. Доступность методов, лимиты и форматы меняются. Не проектируйте на основании старого примера из библиотеки; сохраните ссылку на актуальную спецификацию и дату проверки в техническом решении.
Не вся ручная операция должна стать интеграцией. Редкое рискованное изменение может безопаснее оставаться подтверждаемым человеком. Автоматизируйте повторяемые потоки с ясным владельцем, а исключения выводите в рабочую очередь. Цель — сократить ошибки и время, а не максимизировать число API-вызовов.
- Что запускает обмен: событие, расписание или команда.
- Какой результат считается успешным для бизнеса.
- Сколько может длиться задержка.
- Кто и где разбирает исключение.
Источник истины для каталога, цены и остатка
Если менеджер редактирует цену в ERP, на сайте и в кабинете WB, конфликт неизбежен. Назначьте master-систему для каждого типа данных. PIM может владеть описанием и медиа, ERP — себестоимостью и физическим остатком, pricing-сервис — правилами цены, а каналы — только специфическими атрибутами. Интеграционный слой распространяет изменения и записывает подтверждение.
Остаток особенно чувствителен. Физический запас может быть разделён между собственным складом, резервами сайта и моделями исполнения WB. Нельзя просто передавать одно число во все каналы. Формула доступного количества учитывает оплаченные, но не собранные заказы, страховой буфер, задержку обмена и правила конкретного склада.
Цена также имеет контекст: базовая, акция, канал, регион, комплект, минимальная маржа. Система должна проверять порог и отклонять аномалию до публикации. История изменений отвечает на вопрос, кто или какой алгоритм отправил значение. Без неё расследование ошибочной цены превращается в догадки.
Единый источник истины не обязательно одна программа. Это однозначное правило владения полем и разрешения конфликта.
Надёжная техническая архитектура
Сайт, ERP и WB лучше не связывать цепочкой синхронных запросов. Между ними размещают серверный сервис или интеграционную платформу. Она принимает внутреннее событие, ставит задачу в очередь, преобразует формат, вызывает разрешённый метод, проверяет ответ и сохраняет журнал. Временная недоступность внешней системы тогда не блокирует основной интерфейс.
Лимиты запросов учитываются на уровне очереди. При ответе о превышении лимита задача ждёт, а не повторяется в цикле. Для временных ошибок применяют ограниченные повторы с увеличением интервала; для ошибки данных создают исключение человеку. Идемпотентность защищает от двойного создания или повторного применения операции, когда ответ потерялся.
Нужна периодическая сверка. Даже успешный ответ не гарантирует, что все системы навсегда согласованы: могла измениться схема, задача застрять или пользователь отредактировать значение вручную. Контрольный процесс сравнивает ключевые поля и формирует отчёт расхождений, не перезаписывая их бездумно.
- Очередь и контролируемые повторы.
- Адаптер на актуальную схему WB API.
- Журнал запросов без утечки секретов.
- Dead-letter очередь для неразобранных ошибок.
- Периодическая сверка данных.
Безопасность токенов и доступов
Токен WB API нельзя включать во фронтенд, мобильную сборку, публичный репозиторий или таблицу с общей ссылкой. Запросы выполняет сервер, а секрет хранится в защищённом хранилище переменных. Для разработки, теста и продакшена нужны разные учётные данные. Логи маскируют заголовки и чувствительные поля.
Разделяйте токены по интеграциям и выдавайте только нужные категории доступа. Тогда компрометация аналитического процесса не даст возможность менять цены. Ведите владельца секрета, дату создания, срок пересмотра и процедуру срочного отзыва. Доступ сотрудников к кабинету продавца тоже должен соответствовать ролям и регулярно проверяться.
Валидация нужна с обеих сторон: тип, диапазон цены, известный артикул, допустимый склад, размер пакета и свежесть события. Ответ внешнего API рассматривают как недоверенный ввод для внутренних систем. Персональные данные не добавляют в технические журналы без необходимости и основания.
При подозрении на утечку сначала отзовите токен и ограничьте поток, затем расследуйте. Документированный сценарий реагирования экономит критические минуты.
Как запускать интеграцию без остановки продаж
Разделите проект на потоки. Первый безопасный этап — чтение справочников и отчётов без изменения внешних данных. Второй — выгрузка одного типа информации для ограниченного набора SKU. Третий — остатки и цены с порогами и ручным подтверждением аномалий. Сложные операции подключают после стабильной сверки.
Создайте тестовую матрицу: обычный товар, вариант, отсутствующий артикул, нулевой остаток, временная ошибка, превышение лимита, задержанный ответ и дубликат события. Проверяйте не только код ответа, но и карточку, кабинет, внутренний журнал и уведомление сотрудника. Тестовый SKU должен быть однозначно помечен и не попадать в реальную продажу случайно.
На переключении применяйте параллельный режим: новая система рассчитывает результат, но некоторое время не публикует его автоматически. Команда сравнивает с текущим процессом. Затем включают небольшой процент или группу товаров, наблюдают и расширяют охват. План отката обязан возвращать к известному безопасному состоянию.
- Инвентаризация текущего процесса и данных.
- Read-only прототип и проверка доступов.
- Один поток и ограниченная группа SKU.
- Параллельная сверка и контролируемое включение.
- Документация, обучение и план отката.
Мониторинг, который видит коммерческую ошибку
Технический мониторинг отслеживает частоту ошибок, время очереди, количество повторов и срок последней успешной синхронизации. Но бизнесу важнее аномалии: товары с нулём на одном канале и запасом на другом, цена ниже порога, застрявшие заказы, резкое число изменений или расхождение отчёта.
Уведомление должно содержать действие: затронутый процесс, товары, время, безопасный статус и ответственную роль. Сотни одинаковых сообщений при сбое скрывают проблему. Группируйте события, задавайте уровни критичности и создавайте рабочую задачу. После инцидента фиксируйте причину и предотвращающую проверку.
Раз в квартал пересматривайте документацию WB API, права, устаревшие методы, лимиты и объём данных. Перед крупной акцией проведите нагрузочный и операционный тест. Интеграция — живой продукт: её надёжность поддерживается наблюдаемостью и владельцем, а не заканчивается в день первого успешного запроса.
Полезный SLA формулируется как «актуальный остаток поступает в канал не позднее X минут», а не только как доступность сервера.
Частые вопросы
Можно ли интегрировать сайт с WB без официального API?
Для устойчивой автоматизации следует использовать официальные методы и разрешённые выгрузки. Парсинг кабинета или обход ограничений нестабилен, может нарушать правила и создаёт риск безопасности.
Можно ли сделать двустороннюю синхронизацию остатков?
Технически возможны разные потоки, но сначала нужен единый источник физического остатка и правила резервов. «Последняя запись победила» опасна: она может вернуть устаревшее значение.
Как часто обновлять остатки?
Частота зависит от скорости продаж, доступных методов и лимитов API. Для ходовых товаров используют событийный обмен и контрольную сверку, соблюдая актуальные ограничения WB.
Даёт ли WB API контакты покупателей для CRM?
Интеграцию нельзя рассматривать как способ получить маркетинговую базу. Используйте данные только в разрешённых операционных целях, соблюдайте права и формируйте собственные контакты через свой сайт и согласия.
Найдём три точки роста в вашей воронке
Без готового ТЗ: разберём текущий путь клиента, ограничения и приоритет следующего шага.
Спроектировать интеграцию с WB