MCP-серверыMCP-серверыГде Слон APICPA-сети

«Где Слон?» через API и MCP: один метод — и почему остальные не подошли

Разбираем API партнёрской сети «Где Слон?» со стороны рекламодателя: почему из десятка найденных интерфейсов подошёл ровно один, куда делись остальные и как выгрузка заказов и статусов подключается к Claude через MCP-сервер Mira без единой строки кода.

3 сентября 2026 г.4 мин чтения

Обзор

«Где Слон?» — партнёрская (CPA) сеть: магазин-рекламодатель платит комиссию за заказы, которые пришли через партнёров сети — блогеров, кэшбэк-сервисы, сайты сравнения цен. У рекламодателя есть свой доступ к API, и первое, что удивляет при подключении, — насколько узко он документирован по сравнению с соседями по категории «Реклама» вроде Ozon Performance или Яндекс.Директа.

У сети действительно есть с десяток HTTP-интерфейсов. Мы обошли всю публичную документацию gdeslon.ru/faq/ целиком, а не по первой ссылке из поиска — и выяснилось, что рекламодателю из них подходит ровно один. Остальные либо принадлежат другой стороне сети, либо смотрят в противоположном направлении. Разобраться в этом стоило отдельного внимания — и именно поэтому здесь не 46 методов, как у Ozon Performance, а один, зато подключённый честно.

Единственный метод, который есть у рекламодателя

POST https://www.gdeslon.ru/api/orders/ — «API по продажам в JSON». Авторизация — HTTP Basic парой «ID пользователя:ключ доступа», дословно по примеру документации: curl -L --user 'ID:ключ' ... -X POST https://www.gdeslon.ru/api/orders/. Тело запроса — фильтр из 18 полей: магазин (merchant_id), статус (0 новый, 1 отменён, 2 отложен, 3 подтверждён, 4 выплачен), тип (товарный заказ или лид), период по пяти видам даты (переход, создание, обновление, подтверждение, выплата), суммы, валюта, sub_id, ключевые слова.

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

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

Куда делись остальные методы

Обход документации нашёл ещё несколько интерфейсов «Где Слон?», и ни один не попал в таблицу вызовов — не по недосмотру, а по разбору.

Три интерфейса принадлежат другой стороне сети

XML-поиск товаров, список рекламодателей, категории — всё это авторизуется отдельным api_token, а не парой «ID:ключ» рекламодателя, и служит противоположной задаче: подбору чужих офферов для размещения у себя. Это инструменты партнёра (вебмастера), а не магазина, чьи заказы мы выгружаем. Разные ключи, разные акторы, разное назначение — не вопрос покрытия, а вопрос, чья это вообще сторона API.

Postback и «интеграция по API» смотрят в обратную сторону

Здесь самая содержательная находка обхода. По документации, у «Где Слон?» есть режим, когда сеть сама «периодически делает запросы к API рекламодателя и автоматически забирает подготовленные для него данные» — то есть рекламодатель публикует у себя эндпоинт, а «Где Слон?» его опрашивает. Postback устроен так же: сеть сама вызывает адрес, который назвал рекламодатель, при смене статуса заказа.

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

«Потерянные заказы» — форма, не API

Отдельная страница документации описывает инструмент для случаев, когда заказ не отследился автоматически: в личном кабинете можно «создать заявку», указать номер заказа и сумму, приложить скан чека. Это веб-форма для человека, а не HTTP-метод — документация не называет для неё ни адреса, ни параметров, и придумывать их значило бы то самое, от чего предостерегает правило «не покрывать API по памяти»: выдуманный метод хуже отсутствующего.

Барьер записи — пуст, и это не упрощение

У API рекламодателя нет ни одного метода записи. Единственное действие — чтение: запрос с фильтром, который ничего не создаёт и не меняет на стороне поставщика. Статус заказа и комиссию считает сам «Где Слон?» по данным, которые получает своей стороной — постбэком или обратным опросом, а не по этому вызову. Барьеру здесь буквально нечего охранять, и это не решение «упростить», а точное отражение того, что существует у поставщика.

Как это выглядит через MCP

Сколько заказов подтвердил «Где Слон?» за последнюю неделю и на какую сумму комиссии?

Claude запрашивает заказы с фильтром по дате обновления и статусам «подтверждён»/«выплачен», складывает partner_payment и отвечает суммой — с оговоркой про суточную задержку отчёта, если она уместна.

Есть отменённые заказы за сегодня по магазину 2573?

Claude вызывает orders с merchant_id и state: [1], а не бежит в личный кабинет руками.

Что это даёт на практике

Владельцу магазина. Сверка комиссии CPA-канала без захода в кабинет «Где Слон?» — тот же вопрос, что уже решён для Авито и маркетплейсов, только источник другой.

Финансисту. Заказы и выплаты партнёрской сети рядом с остальными деньгами бизнеса — тем же инструментом, что уже собирает данные Точки, Т-Банка и ЮKassa.

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

Как подключить

  1. Получить ID пользователя и ключ доступа у менеджера «Где Слон?» при подключении рекламодателя — точное расположение этой пары в личном кабинете документация не описывает.
  2. В Mira: проект → источники → «Где Слон?» → вставить оба значения.

Дальше «Где Слон?» доступен и в чате Mira, и через MCP-сервер в Claude, Cursor или другом клиенте с поддержкой протокола.

Новости в Telegram

Подпишитесь на каналы — новые статьи и обзоры каждый день.

Источники

Ещё по теме «MCP-серверы»

MCP-серверы

1С через OData: как достать данные учётной базы без единой строки кода на встроенном языке

Разбираем стандартный OData-интерфейс 1С:Предприятие: чем он отличается от API конкретного сервиса, как узнать, что вообще опубликовано на конкретной базе, как проводить и отменять проведение документов и как всё это работает через MCP-сервер Mira без единой строки кода на встроенном языке.

3 сентября 2026 г.
MCP-серверы

Admitad через MCP: отчёты партнёрской программы без выгрузки в Excel

Разбираем advertiser API партнёрской сети Admitad: отчёты по действиям, публикаторам, площадкам и баннерам, данные программы для интеграции — и почему у рекламодателя весь этот API устроен на чтение. Как устроена выдача токена по client_id/client_secret со скоупом и как всё это работает через MCP-сервер Mira.

3 сентября 2026 г.
MCP-серверы

Adv.Cake через MCP: заказы и визиты партнёрской сети без захода в кабинет

Разбираем API рекламодателя Adv.Cake — партнёрской сети: список заказов и визитов, которые привели партнёры и вебмастеры, с суммой, комиссией и ДРР, плюс валидация рефералов. Три метода вместо привычных полусотни — и почему один из них, несмотря на GET, требует разрешения на запись. Всё это работает через MCP-сервер Mira без единой строки кода.

3 сентября 2026 г.