Интеграция CRM и Яндекс Маркет

Интеграция CRM с Яндекс Маркетом — это обмен через Partner API: заказы приходят в систему, остатки и цены уходят на витрину, статусы бегают в обе стороны, комиссия площадки ложится в заказ расходом. Штатного модуля Маркета нет ни у amoCRM, ни у Битрикс24 — их подключают приложением или собственным коннектором; у RetailCRM модуль есть, но работает он с кампаниями по модели FBS. И самое важное: модель работы на площадке определяет состав данных сильнее, чем выбор CRM.

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

Что дает интеграция CRM с Яндекс Маркетом

Четыре потока данных, и каждый решает свою задачу.

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

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

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

Модель работы решает больше, чем выбор CRM

У Маркета четыре модели, и они дают принципиально разный набор данных. Это первое, что мы выясняем на старте проекта.

Модели можно совмещать в одном кабинете: ходовые позиции на FBY, сезонные и редкие на FBS. Для интеграции это означает, что в CRM должны приезжать разные сценарии обработки, а не один универсальный. Готовые модули такое умеют не всегда — например, модуль RetailCRM подключает кампании, работающие по FBS, и под FBY нужен отдельный контур.

Как устроен доступ: Partner API и токены

Авторизация идет по API-Key-токену, который передается в заголовке запроса. Старая схема через OAuth помечена как устаревшая, и новые интеграции на ней делать не стоит.

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

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

Пара технических моментов из практики 2026 года. Постраничная выборка через параметры page и pageSize помечена устаревшей, работать надо через токенную пагинацию — старые самописные интеграции из-за этого начинают отваливаться на больших выгрузках. И глубина данных в отчетах вместе с числом одновременно генерируемых отчетов теперь зависит от тарифного плана, так что аналитику стоит проектировать с оглядкой на подписку.

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

Что синхронизируется на самом деле

Все держится на связи товаров. Каталог в CRM сопоставляется с предложениями на Маркете, и если сопоставление кривое, дальше поедет все: и цены, и остатки, и состав заказа. Уникальность артикулов проверяется до начала работ, а не после первых расхождений.

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

Про скорость обмена. Заказы приходят из Маркета в систему в режиме реального времени — и создание, и обновление статусов. А вот изменения, которые вы делаете у себя, уходят обратно по расписанию, примерно раз в две минуты. Для FBS этого достаточно, для Экспресса разница между реальным временем и двумя минутами уже ощутима, и такие сценарии мы проектируем аккуратнее.

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

Подменный номер: почему Маркет не отдаст вам клиента

Отдельный разговор, который приходится вести почти на каждом проекте. Маркетплейс — это витрина и логистика, а не источник клиентской базы.

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

Отсюда практический вывод. Строить на данных Маркета повторные продажи, реактивацию и сегментацию по истории покупок не получится, и это не ограничение интеграции, а позиция площадки. Компании, которые заходили в проект с целью «соберем базу и будем продавать напрямую», разочаровывались не в CRM, а в самой идее.

Что CRM селлеру дает на самом деле — операционный контур и общую картину. Заказы всех каналов в одном месте, актуальные остатки, статусы без ручного переноса, документы и понятная экономика с учетом комиссий. Это много, просто это другая задача.

amoCRM, Битрикс24 или RetailCRM: что выбрать

Короткий ответ: если маркетплейсы — основной канал, берите RetailCRM. Если Маркет соседствует с сайтом, розницей и оптом, обычно выигрывает Битрикс24. amoCRM имеет смысл, когда площадка для вас дополнительный канал, а основные деньги приносят услуги или B2B.

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

Битрикс24 берут, когда Маркет надо свести с сайтом, оптом и внутренними задачами компании. Приложения из каталога закрывают базовый обмен, но упираются в нестандартные сценарии — тут мы дописываем логику своим коннектором на REST, а товарный учет выносим в МойСклад или 1С.

amoCRM — про воронку и сделку, а не про склад. Завести заказы Маркета сделками технически можно, но остатки, себестоимость и юнит-экономику туда не положить. Честный сценарий: площадка приносит клиента или оптовый запрос, а дальше сделка идет по нормальной воронке.

Порядок работ: как мы настраиваем интеграцию

1. Фиксируем модели и кабинеты. Какие модели используются, сколько кампаний, что где лежит. От этого зависит и объем работ, и то, что вообще возможно.
2. Определяем источник истины по остаткам. Одна система главная, остальные читают. Если остаток правят и в CRM, и в кабинете, расхождения появятся на первой же неделе.
3. Проверяем каталог. Уникальность артикулов, соответствие товаров и предложений, чем связываем позиции. Шаг скучный и обязательный.
4. Получаем доступы правильно. Токен нужных прав от владельца кабинета, отдельный на нашу интеграцию, без лишних разрешений.
5. Настраиваем заказы и статусы. Маппинг статусов в обе стороны, сроки отгрузки, сценарии сборки под каждую модель, печатные формы.
6. Подключаем цены, остатки и комиссию. Типы цен, соответствие складов, статьи расходов для расчета маржи.
7. Тестируем на живых сценариях. Обычный заказ, частичная отмена, возврат, перенос даты доставки, заказ по другой модели. Возвраты забывают чаще всего, а они ломают и остатки, и деньги.
8. Включаем мониторинг. Уведомления об ошибках обмена и о заказах, зависших без движения. Интеграция ломается тихо, а штрафы за просрочку приходят громко.

Ошибки, которые мы разбираем чаще всего

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

Интеграцию делают под одну модель, а работают по трем. Заказы FBS обрабатываются нормально, а Экспресс и DBS вываливаются в ручной режим. Проектировать надо сразу под все используемые модели.

Остатки редактируют в двух местах. Кладовщик поправил в системе, менеджер в кабинете, синхронизация перезаписала. Итог — продажа того, чего нет, отмена и удар по рейтингу магазина.

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

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

Сроки и стоимость

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

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

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

Придут ли в CRM контакты покупателей с Яндекс Маркета?

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

Работает ли интеграция с моделью FBY?

Частично и по-другому. На FBY заказов в привычном виде нет, работа идет вокруг поставок и остатков на складе площадки. Готовые модули часто рассчитаны на FBS, поэтому под FBY контур проектируется отдельно.

Как быстро заказы попадают в систему?

В модуле RetailCRM создание и обновление заказов приходит из Маркета в реальном времени, а изменения из системы уходят обратно примерно раз в две минуты. В собственных коннекторах частоту задаем мы, но упираемся в лимиты Partner API.

Кто должен создавать токен для интеграции?

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

Можно ли подключить несколько кабинетов или магазинов?

Да, это типовая задача при нескольких юрлицах или брендах. Сложность не в подключении, а в разделении складов, цен и отчетности между кампаниями — это проектируется заранее.

Нужна ли учетная система, если есть CRM?

Зависит от системы. RetailCRM закрывает товарный контур сама. Для Битрикс24 и особенно amoCRM склад и себестоимость разумнее держать в 1С или МойСклад, а в CRM видеть заказы и процессы.

Коротко о главном

Интеграция CRM и Яндекс Маркета закрывает операционные задачи: заказы в одном окне, актуальные остатки и цены, статусы без ручного переноса, печатные формы из заказа и понятная экономика с учетом комиссии. Чего она не делает — не превращает площадку в источник клиентской базы: контактов покупателя Маркет не отдает, а подменный номер на DBS умирает вместе с заказом.

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

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