Эндпоинт сообщений чата

POST /v1/chat/completions принимает диалог в OpenAI-совместимой форме messages. Используйте модель с нужными возможностями текста, инструментов и анализа изображений; наличие эндпоинта не делает любой параметр допустимым для любой модели.

Запрос

curl https://api.b2b-llm.com/v1/chat/completions \
  -H "Authorization: Bearer $B2B_API_KEY" -H 'Content-Type: application/json' \
  -d '{"model":"gpt-5.4","messages":[{"role":"user","content":"Draft one sentence confirming receipt of a support request."}],"stream":false}'

Ответ

{"id":"chatcmpl_example","object":"chat.completion","choices":[{"index":0,"message":{"role":"assistant","content":"We received your request and will review it."},"finish_reason":"stop"}]}

Читайте текст ассистента и вызовы инструментов из возвращённых choices. Не считайте все ответы обычными строками. Для постепенного вывода включите потоковый режим и используйте обработчик потока, соответствующий Chat Completions.

Собственное отложенное выполнение включается через async: true при выключенном потоковом режиме. Временный сеанс Playground не может создавать такую долговременную работу; нужен ключ интеграции. Для обычного запроса к API свежий браузерный код аутентификатора не требуется.

Session ID

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

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

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

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