Manage your sessions and check the processing model

Status and access

This guide describes the qualified staging version, not a production update. Use the staging API address supplied by your workspace operator. Availability of these APIs in production has not been confirmed.

Changing a password and revoking sessions require a current session for your active account and its current local password. These actions apply only to the current user. They do not change another user’s password or sessions. If you use SSO without a local IAM.Docs password, use your identity provider’s normal controls; the requests below will be refused.

This version adds no new interface buttons for password changes or expanded model metadata. The path below is an API workflow for a configured integration client. Keep passwords and tokens out of URLs, command history, screenshots and support requests.

Change your password

Check the client’s current account: GET /api/auth/me with Authorization: Bearer <ACCESS_TOKEN> must return your sub and tenant_id.
Send one POST /api/auth/change-password with the same authorization header and Content-Type: application/json. The values below are placeholders, not a ready-to-use password:

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

The replacement must differ from the current password and contain 8–128 characters. A 200 response contains new access_token, refresh_token and token_type values. Store them using your client’s normal protected mechanism and stop using the previous pair.
Call GET /api/auth/me with the new access token. The user and workspace must remain the same. Other tabs and devices holding old sessions will require a new sign-in.

The password change and revocation of earlier session generations commit in one transaction. Previously issued access and refresh tokens cannot restore access after a successful change. An existing status connection also rechecks its session and closes with code 4401 when it observes revocation.

End all your sessions

Send one POST /api/auth/sessions/revoke with a current access token and JSON:

{"current_password":"CURRENT_PASSWORD"}

A successful response is:

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

This also ends the current session and issues no replacement tokens. Sign in through the normal login form again. A separate password change is unnecessary if your intention was only to end sessions.

Recover from an unexpected result

Result	Next action
`401`	The session is absent, expired or revoked. Sign in normally; do not automatically repeat the request with an old token.
`403`	Check the current password and whether the account has a local password. The request grants no access to another user.
`400` during password change	The replacement equals the current password; choose a different one.
`422`	Check field names and password length. Validation responses must not echo entered secret values.
Lost response or disconnected request	The result is unknown. Do not automatically replay the change. After a password change, first try normal sign-in with the new password. Use your account’s existing support process if access cannot be recovered.

Check which model processed a document

After document processing finishes, provide its document ID and processing step when contacting support. An authorized operator can inspect llm_calls.model_name and the saved input_payload.llm_provenance block for that document. The expanded block is not a separate customer screen or a new public endpoint.

For new successful field-extraction, party-normalization and summary calls, attribution first uses the observed result model when available, then the route model header, then the selected client’s resolver. Historical rows are not rewritten. A model configured in settings alone does not prove that a fresh request ran on particular hardware.

Field	Meaning
`model_name`, `response_model`	Model reported by the result; without that result, `model_basis` identifies the attribution source.
`requested_model`	Model selected by the client’s resolver before the call.
`model_basis`	`returned_response`, `returned_response_unobserved`, `route_header`, `client_resolver` or `unavailable`; the attribution basis remains explicit.
`transport_response_observed`	A successful HTTP response was observed for this call. This alone does not prove a fresh computation without caching.
`router_request_id`	Router response identifier for an exact audit lookup. No new ID is invented for a result without observed transport.
`route_provider`, `route_model`, `route_perimeter`	Allowlisted response-header metadata; compare this separate observation surface with Router audit.

A cached result or a client without an observed HTTP response may use returned_response_unobserved or client_resolver. Never replace a missing Router ID with an invented identifier. Even an exact Router ID requires a separately confirmed mapping to a TaskEngine task: the same model and a nearby timestamp are not a direct ID join. Preserve differing perimeter values from response headers and audit separately rather than replacing one with the other.