Магнит Маркет через API и MCP: 36 методов, бывший KazanExpress и барьер без единой траты
Разбираем Seller API маркетплейса «Магнит Маркет» (бывший KazanExpress): 36 методов в семи разделах, self-service доступ по одному ключу, две формы отказа с общим полем и почему в барьере записи не оказалось ни одного тратящего действия — а также как всё это работает через MCP-сервер Mira без единой строки кода.
Обзор
«Магнит Маркет» — маркетплейс сети «Магнит». Для тех, кто продавал на нём раньше, площадка знакома под другим именем: до покупки «Магнитом» это был KazanExpress. Имя сменилось, а API продавца остался тем же контуром — тем же жизненным циклом FBS-заказа (Fulfillment by Seller): собрать заказ → разбить на посылки → промаркировать → отгрузить.
У площадки нет публичного портала документации в духе docs.ozon.ru — за
подробностями API официально отправляют к менеджеру. Но техническое
руководство продавца называет вторую, машиночитаемую дорогу: magnit-tech
(официальный аккаунт «Магнита» на GitHub) публикует Redoc-страницу с полной
спецификацией, а рядом, в том же репозитории — сам файл swagger.yaml,
который эта страница показывает. Тот случай, когда «спросите менеджера» и
«вот OpenAPI 3.0.3 с точным списком полей» относятся к одному и тому же API:
просто вторую дорогу выбирают реже.
Mira подключает Seller API «Магнит Маркета» целиком — 36 операций в семи разделах — и отдаёт его в Claude через MCP.
Что доступно продавцу
| Раздел | Операций | Что даёт |
|---|---|---|
| Задания на сборку | 12 | список, отмена целиком и по товарам, подтверждение сборки, разбиение на посылки, маркировка (Честный ЗНАК), этикетки |
| Отгрузка посылок | 6 | список, добавление и удаление посылок, подтверждение с датой доставки, отмена, документы (акт приёма-передачи, акт о расхождениях, лист отгрузки) |
| Товары | 8 | создание и правка СКУ, список, краткий список по магазину, архивация, разархивация, удаление, статус асинхронного создания |
| Цены | 2 | обновление и получение |
| Остатки | 2 | обновление и получение |
| Категории и справочники | 5 | категории, характеристики, словари, список и создание виртуальных складов |
| Магазины | 1 | список активных магазинов продавца |
Доступ — один ключ, без похода к нам за авторизацией
Ни OAuth, ни обмен пары ключей на токен: продавец выпускает api_key сам, в
личном кабинете, и этот ключ идёт заголовком X-Api-Key на каждый запрос —
принят или отвергнут, третьего не дано. Ровно тот же класс доступа, что у
Wildberries и MPStats, и он на порядок проще, чем у Авито или Ozon
Performance: там пара client_id/client_secret сначала обменивается на
временный токен отдельным запросом. Здесь обменивать нечего — заявок на
подключение ждать тоже не нужно.
Отказ — две формы конверта, одно общее поле
У площадки не один формат ошибки на весь API, а два, и они привязаны к разделам. «Задания на сборку» и «Отгрузка посылок» отвечают простым массивом:
{"errors": [{"message": "Задание уже собрано"}]}
«Товары», «Цены», «Остатки», «Категории» и «Магазины» — тем же массивом, но с более богатым элементом и дополнительным полем на верхнем уровне:
{
"error": "null",
"errors": [{"code": "VALIDATION", "message": "Категория не найдена", "detailMessage": "..."}]
}
Общее в обеих формах — errors[].message. Разбор ошибок в коннекторе Mira
не различает, из какого раздела пришёл ответ: берёт message из массива,
если он есть, и только при пустом массиве откатывается на верхнее поле
error. Это сверено по всем 36 путям официальной спецификации — не по паре
примеров, которые могли бы ввести в заблуждение насчёт формы, общей для
всего API.
Барьер записи — 20 из 36, и ни одной траты
20 из 36 операций меняют данные площадки: отмена задания на сборку, разбиение на посылки, маркировка, создание и отмена посылки, шаги отгрузки, создание и правка СКУ, обновление цены и остатков, создание виртуального склада. Все они требуют у источника разрешения на запись — то же правило, что у остальных коннекторов Mira, выведенное из таблицы вызовов программно, а не отдельным списком, который может с ней разойтись.
Необычно другое: в этом барьере нет ни одного тратящего действия. У Ozon Performance из 15 меняющих 8 списывают деньги или запускают показы — это рекламный кабинет, там есть что тратить. У «Магнит Маркета» рекламы и платного продвижения в API нет вовсе: спецификация не называет ни кампаний, ни ставок, ни бюджетов. Барьер здесь защищает не от расходов, которых негде взять, а от необратимых и внешне видимых действий — отменённое задание на сборку не восстановить (дословно из спецификации: «Это действие нельзя отменить»), удалённый товар пропадает из каталога, а у виртуального склада в API нет метода удаления вовсе — создание становится частью схемы продавца навсегда.
Файлы внутри JSON — этикетки и документы отгрузки
Два метода возвращают не структурированные данные, а файл: этикетки для
посылок и документы по отгрузке (акты, лист отгрузки) приходят PDF-ом,
закодированным в поле file_content — иногда десятками тысяч символов
base64. Содержимое такого файла в переписку с моделью не переносится (тот
же приём, что у записи разговора Авито и файла отчёта Ozon Performance) —
инструмент возвращает размер и явную пометку, что содержимое осталось за
пределами канала, а не молча обрезает ответ.
Живая проверка
Ключей от боевого кабинета «Магнит Маркета» нет — раздел появится, когда
продавец выпустит api_key в личном кабинете. Разбор адреса и тела, две
формы отказа, барьер записи (проверен мутацией: убранная пометка
«меняет» красит тест) и работа с файловым полем проверены перехватом на
транспорте — против собственного HTTP-сервера в тестах, а не против
b2b-api.magnit.ru.
Новости в Telegram
Подпишитесь на каналы — новые статьи и обзоры каждый день.
Источники
Ещё по теме «MCP-серверы»
1С через OData: как достать данные учётной базы без единой строки кода на встроенном языке
Разбираем стандартный OData-интерфейс 1С:Предприятие: чем он отличается от API конкретного сервиса, как узнать, что вообще опубликовано на конкретной базе, как проводить и отменять проведение документов и как всё это работает через MCP-сервер Mira без единой строки кода на встроенном языке.
3 сентября 2026 г.CloudPayments через API и MCP: 32 метода, конверт отказа, который не отличает 400 от отклонённой карты, и Public ID, который просят дважды
Разбираем API CloudPayments изнутри: платежи, выплаты, подписки и счета чужого магазина — не биллинг самой Миры, — почему списание по сохранённому токену считается расходом, а обычная оплата картой нет, зачем платёжной ссылке СБП собственный Public ID в теле запроса поверх Basic Auth, и как всё это доступно через MCP-сервер Mira без единой строки кода.
3 сентября 2026 г.Финтабло через API и MCP: 112 методов финучёта, семь путей без объявленных параметров и почему тут нет отчётов
Разбираем API Финтабло изнутри: 112 методов финансового учёта — ДДС, счета, контрагенты, сделки, зарплата, имущество, ОПиУ, — где спецификация поставщика сама не дописывает параметры пути, почему у четырёх PUT-запросов id дублируется в теле и куда делись отчёты. Всё доступно через MCP-сервер Mira без единой строки кода.
3 сентября 2026 г.