Управлять своими сессиями и проверить модель обработки

Статус и доступ

Эта инструкция описывает проверенную staging-версию, а не обновление production. Используйте адрес staging API, выданный оператором вашего рабочего пространства. Наличие этих API в production не подтверждено.

Для смены пароля и отзыва сессий нужны действующая сессия своего активного аккаунта и его текущий локальный пароль. Эти действия относятся только к текущему пользователю. Они не меняют пароли или сессии других пользователей. Если вход выполняется через SSO и локального пароля IAM.Docs нет, используйте штатные средства своего провайдера входа; описанные ниже запросы вернут отказ.

Новых кнопок смены пароля или просмотра расширенных метаданных модели в интерфейсе эта версия не добавляет. Ниже приведён API-путь для настроенного интеграционного клиента. Не помещайте пароли и токены в URL, историю команд, скриншоты или обращения в поддержку.

Сменить свой пароль

Убедитесь, что клиент использует нужный аккаунт: GET /api/auth/me с текущим заголовком Authorization: Bearer <ACCESS_TOKEN> должен вернуть ваши sub и tenant_id.
Отправьте один POST /api/auth/change-password с тем же заголовком и Content-Type: application/json. Значения ниже — обозначения, а не готовый пароль:

{"current_password":"CURRENT_PASSWORD","new_password":"NEW_DIFFERENT_PASSWORD"}

Новый пароль должен отличаться от текущего и содержать от 8 до 128 символов. Ответ 200 содержит новые access_token, refresh_token и token_type. Сохраните их штатным защищённым способом своего клиента и больше не используйте прежнюю пару.
Проверьте GET /api/auth/me уже с новым access-токеном. Пользователь и рабочее пространство должны остаться прежними. Другие вкладки и устройства со старой сессией потребуют нового входа.

Смена пароля и отзыв предыдущих поколений сессий фиксируются одной транзакцией. Ранее выданные access- и refresh-токены после успешной смены не восстанавливают доступ. Уже открытое соединение статусов также проверяет сессию и закрывается с кодом 4401 при обнаружении отзыва.

Завершить все свои сессии

Отправьте один POST /api/auth/sessions/revoke с действующим access-токеном и JSON:

{"current_password":"CURRENT_PASSWORD"}

Успешный ответ:

{"status":"revoked","scope":"current_principal_all_sessions"}

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

Если запрос не завершился ожидаемым образом

Результат	Следующее действие
`401`	Сессия отсутствует, истекла или отозвана. Выполните обычный вход; не повторяйте запрос со старым токеном автоматически.
`403`	Проверьте текущий пароль и наличие локального пароля у аккаунта. Запрос не даёт права менять другого пользователя.
`400` при смене пароля	Новый пароль совпадает с текущим; задайте другой.
`422`	Проверьте поля и длину пароля. В ответе валидации не должны возвращаться введённые секретные значения.
Ответ потерян или соединение оборвалось	Результат неизвестен. Не повторяйте изменение автоматически: при смене пароля сначала попробуйте обычный вход с новым паролем. Если восстановить доступ не удалось, используйте существующий процесс поддержки своего аккаунта.

Как проверить, какая модель обработала документ

После завершения обработки документа для обращения в поддержку достаточно передать идентификатор документа и название этапа. Авторизованный оператор может проверить llm_calls.model_name и сохранённый блок input_payload.llm_provenance для этого документа. Расширенный блок пока не является отдельным пользовательским экраном или новым публичным endpoint.

Для новых успешных вызовов извлечения полей, нормализации сторон и подготовки сводки имя модели берётся из наблюдаемого результата, если оно доступно, затем из заголовка маршрута, затем из резолвера выбранного клиента. Старые записи не переписываются. Установленное имя модели в настройках само по себе не доказывает выполнение нового запроса на конкретном оборудовании.

Поле	Как понимать
`model_name`, `response_model`	Модель, указанная в результате; при отсутствии результата основа имени определяется `model_basis`.
`requested_model`	Модель, выбранная резолвером клиента перед вызовом.
`model_basis`	`returned_response`, `returned_response_unobserved`, `route_header`, `client_resolver` или `unavailable`; основа атрибуции остаётся явной.
`transport_response_observed`	Наблюдался успешный HTTP-ответ этого вызова. Это не отдельное доказательство нового вычисления без кэша.
`router_request_id`	Идентификатор из ответа Router для адресного поиска запроса. У результата без наблюдаемого транспорта новый ID не создаётся.
`route_provider`, `route_model`, `route_perimeter`	Разрешённые метаданные заголовков ответа; это отдельная поверхность наблюдения, которую нужно сверять с аудитом Router.

Для результата из кэша или клиента без наблюдаемого HTTP-ответа атрибуция может иметь основу returned_response_unobserved либо client_resolver. Отсутствие Router ID не следует заменять вымышленным идентификатором. Даже при точном совпадении Router ID переход к задаче TaskEngine требует отдельного подтверждённого сопоставления: одинаковая модель и близкое время не являются прямым ID-соединением. Различающиеся значения периметра в заголовке ответа и в аудите сохраняют отдельно, не подменяя одно другим.