Кабинет

Консоль запросов

Почему консоль ходит в мок с сервера, что она отправляет и что остаётся в журнале.

На этой странице · 6

Консоль — это способ дёрнуть метод стенда, не выходя из кабинета и не собирая запрос руками: слева сервис, метод, путь, параметры и тело, справа ответ, заголовки и готовый cURL. Ключ подставляется сам.

Почему запрос уходит с сервера

Браузерная консоль не ходит в мок напрямую. Причина продуктовая, а не техническая: боевой Ozon с 16 мая 2025 года запрещает запросы к Seller API из браузера, а Wildberries не отдаёт заголовки CORS вовсе. Мок повторяет поведение боевых сервисов — и если бы он повторял его буквально, собственная консоль APIStend перестала бы работать первой. Прокси снимает это противоречие: запрос выполняет API кабинета, а мок отвечает ему так же, как ответил бы вашему серверному коду.

Попутно серверное исполнение даёт то, чего браузер не знает: IP клиента и боевой адрес, который был бы вызван без APIStend, — оба поля видны в карточке запроса в журнале.

Произвольный адрес передать нельзя

Консоль принимает код сервиса и путь, а не URL. Иначе эндпоинт превратился бы в открытый SSRF-прокси: любой пользователь кабинета ходил бы через сервер APIStend куда угодно.

Что уходит в запрос

POST /api/console/execute принимает:

Поля запроса

ПолеПо умолчаниюЗначения
serviceCode—bitrix24, ozon, wildberries
httpMethod—GET POST PUT PATCH DELETE HEAD
path—путь без префикса сервиса, начинается со слэша
query{}параметры строки запроса
headers{}заголовки; из кабинета всегда пусто
bodyнеттело; в кабинете вводится как JSON
scenariosuccessinvalid_token, not_found, rate_limit, server_error, timeout
apiKeyIdнетконкретный ключ вместо подобранного
delayMsнетзадержка 0–3000 мс вместо расчётной

Ключ подбирается с учётом прав: берётся самый старый неотозванный ключ песочницы, которому открыт нужный сервис. Явно указанный apiKeyId уважается как есть. Если подходящего ключа нет, приходит 400 с понятной причиной: NO_KEY — ключей песочницы нет вообще. Разбиения по сервисам у ключа нет: любой активный ключ песочницы открывает все сервисы стенда.

Задержка ответа — минимум из задержки песочницы и задержки самого метода, если её не задали полем delayMs. Лимит запросов проверяется до вызова движка: при превышении сценарий подменяется на rate_limit, и ответ приходит такой, какой боевой сервис отдал бы при исчерпании лимита.

Что приходит в ответе

Живой ответ на POST /v3/posting/fbs/list у Ozon:

{
  "requestId": "f0c9ea91aae8abf9",
  "status": 200,
  "durationMs": 181,
  "sizeBytes": 4218,
  "scenario": "success",
  "responseSource": "example",
  "readiness": "ready",
  "upstreamUrl": "https://api-seller.ozon.ru/v3/posting/fbs/list",
  "method": {"id": "ozon:POST:/v3/posting/fbs/list", "title": "Список отправлений", "group": "Обработка заказов FBS и rFBS"}
}

Заголовки ответа приходят отдельным полем и показываются на вкладке «Заголовки» — те же самые, что получил бы ваш код:

content-type: application/json
x-o3-trace-id: f0c9ea91aae8abf9
x-apistend-request-id: f0c9ea91aae8abf9
x-apistend-source: example
x-apistend-readiness: ready
x-apistend-scenario: success
x-apistend-upstream: https://api-seller.ozon.ru
x-apistend-snapshot: 2026-04-16

Набор зависит от сервиса: у Wildberries вместо x-o3-trace-id придут x-request-id и счётчики x-ratelimit-*, у Битрикс24 — ни того ни другого, зато в теле будет конверт time. Консоль показывает ровно то же, что получил бы ваш код по curl.

Сценарий «Таймаут» — единственный, который не исполняется по-настоящему: консоль сразу отдаёт 504, durationMs: 30000 и признак simulated: true, не занимая соединение на полминуты.

cURL

Вкладка «cURL» показывает не то, что сделала консоль, а то, что должен отправить ваш код: адрес стенда, родной для сервиса заголовок авторизации и тело запроса.

curl -X POST \
  'http://localhost:8080/oz/v3/posting/fbs/list?lang=RU' \
  -H 'Client-Id: 123456' \
  -H 'Api-Key: stend_sbx_c40d…' \
  -H 'Content-Type: application/json' \
  -d '{"limit":2}'

Заголовок авторизации подставляется по сервису: Client-Id и Api-Key у Ozon, Authorization у Wildberries, X-Mock-Key у Bitrix24. Строка X-Mock-Scenario добавляется, только если выбран сценарий, отличный от success.

Ключ в cURL обрезан

В команде стоит префикс ключа и многоточие — полный ключ показывается один раз, при создании, и кабинет его не хранит. Скопированный cURL нужно допилить: подставить свой ключ вместо stend_sbx_….

Что попадает в журнал

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

Секреты маскируются на записи: заголовки authorization, api-key, x-api-key, x-mock-key, cookie и set-cookie заменяются целиком, а ключ, попавший в тело запроса — у Bitrix24 это штатный параметр auth, — приводится к виду stend_sbx_3c29••••d7b2. Тело запроса сохраняется усечённым до 8000 символов.

Подводные камни

  • Путь пишется так, как его ждёт шлюз, включая внутренний префикс сервиса. У Bitrix24 это /rest/: запрос к /crm.deal.list вернёт 404 и подсказку в заголовке x-apistend-did-you-mean: /rest/crm.deal.list, /rest/crm.deal.add, ….
  • Свои заголовки из кабинета не отправляются: поле headers всегда пустое. Сценарий и задержка задаются не заголовками, а переключателями — на боевом запросе из кода это X-Mock-Scenario и X-Mock-Delay.
  • «История вызовов» под ответом хранит последние двенадцать запросов и живёт в памяти вкладки: перезагрузка страницы её очищает. Постоянная история — это журнал.
  • Кнопка «Сохранить» не сохраняет запрос — она открывает создание своего мока с телом полученного ответа и путём /custom + текущий путь. Сохранённых запросов в продукте нет.