Яндекс Доставка через API и MCP: два разных API под одним токеном и почему request/create тоже тратит деньги

Обзор

Яндекс Доставка для бизнеса — это на самом деле ДВА разных API под одной вывеской: «Экспресс» возит заказы в пределах города день в день, «Доставка по России» — плановая доставка между городами через ПВЗ и склады. У обоих свой хост, свой набор путей и своя логика заявки — но один и тот же способ получить доступ: self-service Bearer-токен из личного кабинета, без заявок и одобрений.

Mira подключает оба API одним источником — 53 действия из 57 операций официальной документации — и отдаёт их в Claude через MCP.

Что доступно

У Яндекс Доставки нет файла OpenAPI — но есть кое-что почти такое же

В отличие от Модульбанка, у которого есть настоящий Swagger 2.0 на боевом хосте, документация Яндекс Доставки не публикует спецификацию отдельным файлом. Зато каждая страница метода отрисована из внутренней OpenAPI-схемы, и у каждой есть markdown-версия с той же json-schema-разметкой, что несёт настоящий Swagger: обязательные и необязательные поля помечены явно, путь и метод — в отдельном блоке. Мы написали скрипт, который скачивает оба «Списка методов» и разбирает КАЖДУЮ из 57 страниц этим же способом — а не читает их глазами по одной. Снимок из 53 разобранных операций закоммичен, и таблица вызовов сверяется с ним тестом.

Разбор скриптом сразу поймал то, что человек мог бы пропустить: страница метода request/place/edit в «Списке методов» описана как GET, а её собственный markdown-файл (и имя файла на сервере) говорят, что метод — POST. Мы поверили странице метода, а не сводной таблице.

Четыре операции исключены — не забыты, а недоступны

Раздел «Управление мерчантами» API «Доставка по России» описывает 6 операций, но у четырёх из них (merchant/register — оба варианта, merchant/search, merchant/delete) страницы документации на 2026-09-03 отдают 404 — битая ссылка в собственном «Списке методов» Яндекса. Без рабочей страницы нельзя сверить обязательные поля, а для merchant/delete — необратимого действия — рисковать угадыванием было бы худшим из решений. Все четыре явно исключены с названной причиной; тест держит это число.

Самое неочевидное место: два пути создать заказ, и оба тратят

У «Доставки по России» есть привычная схема — offers/create (получить варианты) → offers/confirm (забронировать один) — и её подтверждение однозначно списывает деньги за доставку. Но есть и второй путь, request/create — «создание заказа на ближайшее доступное время» ОДНИМ вызовом, без отдельного шага бронирования. Это не альтернативное чтение: заказ создаётся и уходит в исполнение сразу, с тем же эффектом, что у явного подтверждения. Если бы барьер записи считал его только «меняет», агент мог бы обойти защиту от траты денег вторым путём создания того же заказа. Оба помечены как тратящие деньги.

Одно и то же имя поля значит разное в двух API

request_id — обязательный параметр у нескольких методов, и в «Экспрессе» это токен ИДЕМПОТЕНТНОСТИ (защита от дубля при повторе после сетевого сбоя), а в «Доставке по России» — ИДЕНТИФИКАТОР ЗАКАЗА, который возвращается при создании и нужен, чтобы прочитать или отменить существующий заказ. Инструмент не пытается угадать смысл поля по имени — оба обязательны там, где обязательны по документации, а какое значение подставить, решает вызывающий.

Токен — self-service, один на оба API

Доступ выдаётся в личном кабинете dostavka.yandex.ru → «Интеграции» → «Получить токен» — без одобрения заявки, и один и тот же токен работает для обоих API (сверено по документации каждого). Токен действует неограниченное время и меняется только сменой пароля кабинета или ручным перевыпуском.

Живая проверка

Живых ключей от боевого личного кабинета Яндекс Доставки нет — раздел появится, когда владелец бизнеса их даст. Разбор адреса и тела, барьер записи и Bearer-заголовок проверены против собственного HTTP-сервера в тестах — перехват на транспорте, тот же приём, что у Модульбанка и Яндекс KIT, — а не против b2b.taxi.yandex.net и b2b-authproxy.taxi.yandex.net.