Интеграция интернет-магазина с Яндекс Маркетом

Каталог относится к кабинету с businessId; операции конкретного магазина могут требовать campaignId. Эти идентификаторы и модель продаж фиксируем в настройках обмена. Список магазинов и доступные идентификаторы получаем через GET v2/campaigns.

Для авторизации используется Api-Key-токен с доступами к нужным группам методов. Проверяем права чтения и изменения отдельно для товаров, цен и заказов; секрет храним на сервере интеграции. Ключ в публичную заявку присылать не нужно.

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

Связываем внутренний товар и вариант магазина с SKU продавца на Маркете (offerId) в контексте кабинета. Название товара не служит ключом. Неизвестные связи отправляем на разбор, а изменения каталога начинаем с контрольной выборки.

Добавление и изменение товаров доступно для всех моделей через POST v2/businesses/{businessId}/offer-mappings/update. Проверяем категорию, характеристики и результат обработки: ответ может содержать ошибки и предупреждения по товарам. Создание карточек и подготовку контента согласуем отдельным объёмом.

Выбираем владельца прайса и правила канала Маркета. POST v2/businesses/{businessId}/offer-prices/updates задаёт цены для всех магазинов. Отдельные цены через POST v2/campaigns/{campaignId}/offer-prices/updates доступны, когда настройка onlyDefaultPrice кабинета равна false.

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

Если в кабинете нет групп складов, используется updateStocksOnPartnerWarehouses (POST v3): SKU, partnerWarehouseId, количество и момент актуальности. При наличии групп складов — updateStocks (PUT v2); передача для одного склада группы обновляет её остальные склады автоматически.

Оба метода передачи предназначены для FBS, Экспресс и DBS. Для FBY Маркет сам учитывает товар своего склада: данные читаем для сверки, не заменяем их количеством магазина. Инструкция различает получение остатков и их передачу.

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

POST v1/businesses/{businessId}/orders возвращает заказы кабинета для всех моделей с фильтрами и постраничной выдачей. Используем его для загрузки и сверки состояния; связь с внутренним заказом храним по кабинету, магазину и внешнему заказу.

Изменение статуса через updateOrderStatus (PUT v2) доступно для FBS, Экспресс, DBS и LaaS. FBY в список этого метода не входит. Для FBS согласуем подготовку и отгрузку, для DBS — собственную доставку и разрешённые переходы. В FBY заказы поступают в учёт без задания на сборку у продавца.

API-уведомления подключаются отдельно: Маркет отправляет POST notification на HTTPS-адрес интеграции. Можно выбрать события заказов и возвратов на уровне кабинета или магазина. Уведомления о заказах на уровне кабинета приходят и для FBY.

Проверочный PING требует ответа за 1 секунду, обычное уведомление — за 10 секунд. При технической ошибке Маркет повторяет запрос и задерживает другие уведомления до подходящего ответа. Приём и обработку проектируем с журналом, устойчивым хранением и сверкой через API; повтор не должен создавать второй заказ или резерв.

Вымышленный технический пример, не клиентский кейс и не запрос к Partner API. У магазина две модели: FBS со своего склада и FBY со склада Маркета. Пришло уведомление о FBS-заказе YM-DEMO-204: две лампы LAMP-02. Система сохранила один внутренний заказ и один резерв на 2 штуки, но ответ не дошёл.

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

Параллельный FBY-заказ другой лампы записывается для учёта отдельно. Он не уменьшает доступное количество FBS и не создаёт сборку на собственном складе. На приёмке проверяем повтор, отмену и разделение моделей; журнал показывает причину каждого изменения.

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

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

Проверены открытые официальные обзоры FBS/DBS/FBY, методы ассортимента, цен, остатков и заказов, инструкция API-уведомлений. Ссылки приведены рядом с фактами. Дата проверки — 19 октября 2026 года; состав прав, контракт и ограничения перечитываем перед разработкой и повторно перед запуском.

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

Выберите вопрос перед брифом: нужен ли свой канал, какую CMS использовать, как устроить обмен или чем различаются площадки.