Эндпоинт Responses

POST /v1/responses принимает input и возвращает список элементов output. Этот интерфейс используется конструктором запросов Responses и совместимыми агентными клиентами. Различайте типы элементов: текст, вызовы инструментов и сгенерированные медиа.

Запрос

curl https://api.b2b-llm.com/v1/responses \
  -H "Authorization: Bearer $B2B_API_KEY" -H 'Content-Type: application/json' \
  -d '{"model":"gpt-5.4","input":[{"role":"user","content":[{"type":"input_text","text":"Summarize a safe deployment checklist."}]}],"stream":false}'

Ответ

{"id":"resp_example","object":"response","status":"completed","output":[{"type":"message","role":"assistant","content":[{"type":"output_text","text":"Back up, validate, deploy, then check service health."}]}]}

Представление PDF

Для поддерживаемого PDF-входа добавьте {"type":"input_file","filename":"brief.pdf","file_data":"data:application/pdf;base64,BASE64_PDF"} рядом с текстовым содержимым. Замените заполнитель реальными байтами PDF в base64. Чистый base64 без data URL в file_data не соответствует контракту этого конструктора.

Генерация изображений и поиск

Модель с поддержкой инструментов генерации изображений может принимать tools: [{"type":"image_generation"}]; результат возвращается в result элемента image_generation_call. Это отличается от массива data эндпоинта Images. Веб-поиск у поставщика использует отдельный инструмент; см. поиск Responses. Не включайте неподдерживаемые инструменты только потому, что модель принимает текстовые Responses.

Инструмент изображений Responses остаётся зависящей от поставщика возможностью Responses. Он не наследует учёт операций Images компании, API закрытых файлов или защиту отправки одного намерения. Не подменяйте им недоступный проверенный маршрут изображений; проверьте отдельный контракт инструмента и расчёта либо используйте специализированные операции Images.

Session ID

Передавайте стабильный JSON session_id или заголовок X-Session-ID в каждом обращении этого диалога. Приоритет: session_id → X-Session-ID → распознанная сессия в metadata.user_id → prompt_cache_key → начальное содержимое диалога. Уровень идентификации не зависит от типа поставщика. Один и тот же ID не гарантирует попадание в кеш и не отключает допустимое резервное переключение. Автоматическое поведение, область действия, ограничения и отличия от идемпотентности и хранения контекста описаны в разделе идентификатор диалога и привязка маршрута.

Выбранный идентификатор сохраняется для потока и асинхронной отправки, когда эндпоинт её поддерживает. После тайм-аута не отправляйте новый платный POST только для проверки сессии: сначала проверьте существующий запрос.

При продолжении через previous_response_id повторяйте явный ID диалога. Идентификатор сохранённого ответа и Session ID решают разные задачи; не заменяйте один другим.

Уже заданная распознанная сессия в метаданных используется без ошибки несовпадения; обычный metadata.user_id сохраняется и не считается диалогом. Более приоритетные явные поля побеждают. Форматы и ограничения передачи поставщику приведены в указанном справочнике идентификации.

Распознанная metadata-сессия имеет приоритет перед подсказкой кеширования. Автоматическая идентичность не учитывает известные маркеры cache_control и эквивалентные одиночные текстовые обёртки, не меняя запрос к модели. Отдельно настроенный совместимый транспорт сессионного заголовка не занимает обычный metadata.user_id; эту возможность настраивает оператор, а не клиент.