Обычный ответ модели — свободный текст. Разбирать его программно тяжело: сегодня модель напишет «Цена: 1200 ₽», завтра — «стоит примерно тысячу двести». Структурированный вывод снимает эту проблему: ответ приходит строго в форме, описанной заранее.

Значение response_formatЧто гарантирует
{"type": "json_object"}Ответ будет корректным JSON. Какие в нём окажутся поля — на усмотрение модели
{"type": "json_schema", ...}Ответ будет соответствовать переданной схеме: те же поля, те же типы

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

Схема описывается в формате JSON Schema. Флаг strict включает строгую проверку — без него схема считается пожеланием, а не требованием.

curl "https://api.proxyapi.ru/v1/chat/completions" \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer <КЛЮЧ>" \
    -d '{
        "model": "openai/gpt-5-mini",
        "messages": [
            {"role": "user", "content": "Ноутбук, 14 дюймов, 89990 рублей, в наличии"}
        ],
        "response_format": {
            "type": "json_schema",
            "json_schema": {
                "name": "product",
                "strict": true,
                "schema": {
                    "type": "object",
                    "properties": {
                        "title": {"type": "string"},
                        "price": {"type": "number"},
                        "in_stock": {"type": "boolean"}
                    },
                    "required": ["title", "price", "in_stock"],
                    "additionalProperties": false
                }
            }
        }
    }'

Структура ответа не меняется: JSON приходит строкой в том же поле choices[0].message.content, что и обычный текст. Разница в содержимом — вместо предложения там документ, готовый к разбору.

{"title": "Ноутбук 14 дюймов", "price": 89990, "in_stock": true}

Строгий режим накладывает ограничения, и задаёт их конечный сервис, а не ProxyAPI. Общие для большинства моделей:

  • все поля перечислены в required — необязательных нет;
  • у каждого объекта проставлено "additionalProperties": false;
  • поддерживается не весь JSON Schema: часть ключевых слов, вроде ограничений на длину строки, игнорируется.

Необязательное поле обычно выражают через тип-объединение: ["string", "null"].

Строгий режим доступен не у каждой модели. Если она его не поддерживает, конечный сервис либо ответит ошибкой 400, либо проигнорирует схему и вернёт обычный текст. Поэтому разбор ответа лучше оборачивать в проверку, а не полагаться на формат вслепую.

Частые вопросы

Чем json_schema отличается от json_object?

Режим json_object гарантирует только то, что ответ будет корректным JSON — набор полей модель выбирает сама. Режим json_schema закрепляет конкретную структуру: поля, типы и вложенность.

Почему в строгой схеме все поля обязательные?

Такое требование предъявляет конечный сервис. Необязательное поле описывают через объединение типов, разрешая наряду с основным типом значение null, и модель возвращает null, когда значения нет.

Почему ответ приходит строкой, а не объектом?

Структура ответа API не меняется: JSON лежит в поле message.content как текст. Его нужно разобрать самостоятельно — стандартными средствами языка.

Что делать, если модель не поддерживает схему?

Ответом будет либо ошибка 400, либо обычный текст вместо JSON. Варианта два: выбрать модель с поддержкой строгого режима или описать нужный формат в системном сообщении и проверять результат на своей стороне.

Последняя редакция: 2 сентября 2026 г.