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

POST /v1/messages использует структуру диалога Anthropic. system находится на верхнем уровне, а max_tokens задаёт запрошенный максимум вывода. Для соответствующих видов содержимого по-прежнему требуется модель с поддержкой инструментов или анализа изображений.

Запрос

curl https://api.b2b-llm.com/v1/messages \
  -H "x-api-key: $B2B_API_KEY" -H 'anthropic-version: 2023-06-01' \
  -H 'Content-Type: application/json' \
  -d '{"model":"claude-sonnet-4.6","max_tokens":256,"system":"Use professional language.","messages":[{"role":"user","content":"Confirm the planned maintenance in one sentence."}]}'

Ответ

{"id":"msg_example","type":"message","role":"assistant","content":[{"type":"text","text":"The maintenance window is confirmed."}],"stop_reason":"end_turn","usage":{"input_tokens":20,"output_tokens":9}}

Содержимое — список блоков, а не одно текстовое свойство. При продолжении диалога сохраняйте поддерживаемые сообщения вызова инструмента и его результата. Отдельно оценивайте вход через подсчёт токенов.

Для модели с поддержкой PDF блок документа использует source.type=base64, source.media_type=application/pdf и чистый base64 в source.data. Не переносите свойство file_data из Responses в этот протокол. Веб-поиск на стороне поставщика через поддерживаемый интерфейс Responses описан в руководстве по поиску.

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; эту возможность настраивает оператор, а не клиент.