Синхронизация WooCommerce с API поставщика для цен остатков и каталога

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

В таких проектах я настраиваю синхронизацию WooCommerce с API поставщика. Задача не сводится к одному запросу и импорту JSON. Нужно определить правила данных, сопоставление товаров, частоту обновлений, обработку ошибок и безопасное поведение магазина при недоступности внешней системы.

Сначала определяем источник истины

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

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

Товар нужно сопоставлять по стабильному идентификатору

Название товара плохо подходит для связи двух систем. Оно меняется, может содержать разные пробелы и иногда повторяется. Лучше использовать стабильный внешний ID, SKU или другой уникальный ключ поставщика.

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

Вариации требуют отдельной логики

Если товар имеет объём, цвет, упаковку или другую вариативность, внешний каталог часто хранит каждую комбинацию как отдельную позицию. В WooCommerce при этом есть родительский товар и дочерние вариации.

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

Цены нельзя обновлять без бизнес правил

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

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

Остатки лучше обрабатывать отдельно от полного каталога

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

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

API лимиты нужно учитывать до запуска

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

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

Сбой поставщика не должен ломать магазин

Внешний API иногда отвечает медленно или временно недоступен. В этот момент нельзя обнулять остатки только потому, что запрос не вернул данные.

Я разделяю отсутствие товара в корректном ответе и техническую ошибку получения данных. При сетевом сбое сохраняются последние подтверждённые значения, а ошибка записывается в журнал для повторной обработки.

Логи должны отвечать на конкретные вопросы

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

Для проблемной позиции важно видеть внешний ID и причину, но не секретные токены и лишние персональные данные. Это позволяет быстро понять, проблема в API, структуре ответа или конкретном товаре.

Что можно синхронизировать

• названия и артикулы товаров
• обычные и акционные цены
• остатки и статус наличия
• категории и атрибуты
• вариации
• изображения
• описания и технические характеристики
• внешние идентификаторы

Набор полей зависит от API поставщика и от того, какие данные действительно нужно передавать на сайт.

Когда нужен webhook

Если поставщик умеет отправлять webhook при изменении товара или остатка, часть данных можно обновлять почти сразу. Это эффективнее постоянного опроса всего каталога.

Но webhook тоже нужно проверять и обрабатывать идемпотентно. Повторная доставка одного события не должна дважды выполнять необратимое действие.

Как проходит разработка

Сначала я изучаю документацию API и несколько реальных ответов. Затем сопоставляю поля поставщика со структурой WooCommerce и фиксирую правила обновления.

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

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

Что нужно для оценки задачи

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

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

Практический результат

Хорошая интеграция уменьшает ручную работу и одновременно делает данные магазина предсказуемее. Менеджер не переносит остатки вручную, покупатель видит более актуальную информацию, а ошибки можно найти по журналу и повторить только проблемную операцию.

Если нужно связать магазин с конкретным поставщиком, можно описать задачу A.S Groups. Посмотрю API, структуру WooCommerce и предложу схему синхронизации без лишней нагрузки на сайт.