В этом материале
Схема задаёт ожидаемую структуру, но приложение всё равно должно проверять ответ. Поддержку structured outputs нужно подтвердить у конкретного endpoint и не смешивать формат разных API.
Для получения структурированного JSON через OpenRouter используйте механизм structured outputs у поддерживающей его модели и endpoint. Просьба «ответь JSON» в обычном тексте помогает описать намерение, но не заменяет передачу схемы и проверку результата приложением.
Структура запроса зависит от API. В Chat Completions используется response_format, а в Responses — text.format. Примеры настроек ниже относятся к документации, проверенной 1 ноября 2026 года.
Опишите небольшой контракт
Руководство Structured Outputs показывает передачу JSON Schema. Начинайте с нескольких обязательных полей, понятных типов и допустимых значений. Сложная схема с десятками вариантов затрудняет диагностику, если исходная интеграция ещё не проверена.
Условная задача — извлечь из тестового предложения модель GPU и количество карт. Приложению нужны строка gpu_model, целое count и признак, что сведения не найдены. Не заставляйте модель придумывать количество, если в документе его нет: такое поведение закладывается в контракт и инструкцию заранее.
Проверьте фактическую поддержку
Одна модель может обслуживаться разными исполнителями. Поэтому наличие функции в общем описании модели не означает одинаковую поддержку на любом маршруте. Provider Routing позволяет ограничивать выбор исполнителей и учитывать необходимые параметры.
Проверяйте текущий endpoint, а не прошлый успешный запрос к похожему имени. Если функция обязательна, настройте маршрут так, чтобы отсутствие совместимой цели приводило к понятному отказу. Незаметное ослабление требований усложняет дальнейший разбор данных.
Различайте режимы API
| Выбранная операция | Где задаётся схема |
|---|---|
| Chat Completions | В response_format с JSON Schema |
| Responses | В text.format с JSON Schema |
| Обычная текстовая просьба | В инструкции, без эквивалентной гарантии контракта |
Не копируйте весь объект настроек из другого формата. Сначала проверьте один синхронный запрос, затем добавляйте потоковую передачу или инструменты. Так проще определить, связан отказ со схемой, маршрутом или чтением ответа.
Валидируйте два уровня
Первый уровень — синтаксис и соответствие схеме. Проверяйте наличие полей, типы, диапазоны и лишние свойства. Второй — смысл: существует ли указанная модель GPU в исходном документе, не перепутаны ли единицы памяти, соответствует ли количество строке предложения.
Даже строгая структура не делает извлечённые сведения истинными. Для важных полей полезно сохранять ссылку на фрагмент исходного тестового документа и разрешать состояние «не определено». Отсутствие ответа иногда полезнее аккуратно оформленной догадки.
Испытайте неудобные входы
Подготовьте документ без количества, неоднозначное название карты, конфликтующие строки и обрезанный вход. Отдельно проверьте превышение ограничения ответа и отказ модели. Приложение должно выдать контролируемое состояние, а не сохранить произвольный текст как подтверждённый инвентарный факт.
Сохраните версию схемы вместе с результатом проверки. При изменении контракта старые записи не должны молча трактоваться по новым правилам. Это особенно полезно, когда ответы модели попадают в технический реестр оборудования или влияют на следующий этап обработки.
Для развития интеграции прочитайте про tool calling и ключ приложения. Структурированное извлечение может помочь заполнить черновик, однако сведения о железе подтверждает владелец.