Uzum Market API через MCP: документации нет, а спецификация — есть, прямо в личном кабинете
Uzum Market не публикует документацию для разработчиков — но личный кабинет продавца отдаёт настоящую OpenAPI-спецификацию через встроенный Swagger UI. Разбираем 38 методов Seller API — товары, остатки, заказы FBS/DBS, накладные, финансы — и как всё это работает через MCP-сервер Mira.
Обзор
У Uzum Market — крупнейшего маркетплейса Узбекистана — нет публичной страницы для разработчиков. Ни developers.uzum.uz, ни раздела «API» в руководстве продавца: инструкция на seller.uzum.uz/manual/ рассказывает про интерфейс личного кабинета, а не про интеграции.
Но сам личный кабинет продавца отдаёт настоящую спецификацию. Встроенный Swagger UI (api-seller.uzum.uz/api/seller-openapi/swagger/...) грузит конфигурацию, а та называет адрес самого OpenAPI-документа — Uzum market seller openapi, версия 1.0.0. Это не пересказ и не зеркало третьей стороны: тот же JSON, который отдаёт сам поставщик за собственным доменом.
Mira подключает Seller API целиком — 38 методов в восьми разделах — и отдаёт его в Claude через MCP.
Что доступно продавцу
| Раздел | Методов | Что даёт |
|---|---|---|
| Orders | 11 | Заказы FBS/DBS, подтверждение, отмена, привязка идентификаторов, передача и выдача DBS, возврат |
| FBS Invoice | 11 | Накладные сборки: создание, состав, отмена, таймслоты и пункты приёма |
| Product | 4 | Товары, цены, справочник и печать этикеток |
| FBO Invoice | 3 | Накладные поставки на склад Uzum |
| Return Invoice | 3 | Возвраты со склада |
| Stocks | 3 | Остатки по SKU, обновление остатков FBS/DBS |
| Finance | 2 | Заказы для сверки выплат, расходы (логистика, хранение, штрафы) |
| Shop | 1 | Список собственных магазинов продавца |
Устройство, которое стоит знать заранее
Токен — один, и без «Bearer»
Продавец выпускает единственный токен сам, в личном кабинете (seller.uzum.uz → Настройки → API), и вставляет его в форму подключения Mira. Обмена ключей на токен здесь нет — не как у Авито или Ozon Performance, где backend сам меняет пару ключей на рабочий токен. И заголовок авторизации — не привычный Bearer <токен>: спецификация прямо говорит, что префикс отправлять не нужно. С «Bearer» Uzum отвечает 401, неотличимым от неверного токена, — деталь, которую легко упустить, если писать интеграцию по образцу других площадок.
Платного продвижения в этом API нет
В спецификации нет ни кампаний, ни ставок, ни рекламного кабинета — только товары, остатки, цены, поставки, заказы, накладные и финансовые отчёты. Барьер записи покрывает 12 действий (изменение цены, статусов заказа, остатков, накладных), но ни одно из них не списывает деньги напрямую — это решение самого API, а не то, что Mira решила не показывать.
Печать документов — Base64 внутри JSON, а не файл
У большинства площадок печать этикетки или акта — это отдельный HTTP-ответ с файлом. У Uzum печать в основном устроена иначе: JSON-конверт, а внутри поля document — PDF, закодированный в Base64. Полтора мегабайта PDF превращаются в два мегабайта текста прямо в теле ответа. Инструмент Mira эту особенность не передаёт агенту целиком — отдаёт размер и тип, как и с обычным файлом при скачивании. Только печать этикеток товара (barcode_print) отвечает настоящим application/pdf — тут спецификация не разошлась сама с собой.
Баг в самой документации, а не в интеграции
У трёх методов раздела «накладные сборки» путь в спецификации содержит {invoiceId}, а объявленный параметр называется иначе — id у двух методов и не назван вовсе у третьего (при этом то же значение требуется в теле запроса). Это несогласованность самой публикуемой Uzum спецификации, а не повод либо гадать по смыслу, либо переписывать таблицу вызовов под чужую опечатку: адрес и подстановка значения работают по тому, что реально написано в шаблоне пути, и это зафиксировано отдельной проверкой контракта.
Как это выглядит через MCP
Какие заказы Uzum ждут подтверждения?
Claude запрашивает список заказов по статусу CREATED, показывает, что нужно собрать в первую очередь.
Обнови остатки по SKU 3001 — на складе осталось 5 штук
Claude вызывает обновление остатков, барьер записи проверяет разрешение источника перед тем, как запрос уйдёт к поставщику.
Что защищено от случайного действия
Из 38 методов 12 меняют данные: правка цены; подтверждение, отмена и привязка идентификаторов заказа; передача, подтверждение выдачи и возврат по DBS; обновление остатков; создание, изменение состава, отмена и обновление таймслота накладной. Барьер выведен из той же таблицы, где описан каждый метод, — тем же устройством, что у Авито, Ozon и Ozon Performance в Mira.
Что это даёт на практике
Продавцу. Заказы, остатки и цены одним вопросом — без переключения между личным кабинетом Uzum и таблицами учёта.
Логисту. Жизненный цикл FBS/DBS-заказа — от подтверждения до накладной сборки — доступен в чате, без ручного похода в каждый раздел кабинета.
Разработчику. Готовый клиент вместо самостоятельной охоты за спецификацией через Swagger UI и разбора нестандартного заголовка авторизации.
Как подключить
- Личный кабинет продавца (
seller.uzum.uz) → Настройки → API. - Создать токен и скопировать его.
- В Mira: проект → источники → Uzum Market → вставить токен.
Дальше Uzum Market доступен и в чате Mira, и через MCP-сервер в Claude, Cursor или другом клиенте с поддержкой протокола.
Новости в 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 г.