Кабинет
Консоль запросов
Почему консоль ходит в мок с сервера, что она отправляет и что остаётся в журнале.
На этой странице · 6
Консоль — это способ дёрнуть метод стенда, не выходя из кабинета и не собирая запрос руками: слева сервис, метод, путь, параметры и тело, справа ответ, заголовки и готовый cURL. Ключ подставляется сам.
Почему запрос уходит с сервера
Браузерная консоль не ходит в мок напрямую. Причина продуктовая, а не техническая: боевой Ozon с 16 мая 2025 года запрещает запросы к Seller API из браузера, а Wildberries не отдаёт заголовки CORS вовсе. Мок повторяет поведение боевых сервисов — и если бы он повторял его буквально, собственная консоль APIStend перестала бы работать первой. Прокси снимает это противоречие: запрос выполняет API кабинета, а мок отвечает ему так же, как ответил бы вашему серверному коду.
Попутно серверное исполнение даёт то, чего браузер не знает: IP клиента и боевой адрес, который был бы вызван без APIStend, — оба поля видны в карточке запроса в журнале.
Произвольный адрес передать нельзя
Консоль принимает код сервиса и путь, а не URL. Иначе эндпоинт превратился бы в открытый SSRF-прокси: любой пользователь кабинета ходил бы через сервер APIStend куда угодно.
Что уходит в запрос
POST /api/console/execute принимает:
Поля запроса
Ключ подбирается с учётом прав: берётся самый старый неотозванный ключ песочницы,
которому открыт нужный сервис. Явно указанный 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+ текущий путь. Сохранённых запросов в продукте нет.