Authentication

Real login only

Both SDKs perform a real username/password login automatically on the first call when
username + password are present in the config:

• Endpoint: POST {serviceApiUrl}/api/account/login. Request body:
  { "applicationId": "<app-guid>", "userName": "<user>", "password": "<secret>" } -
  note userName (camelCase) and the required applicationId; the SDK supplies both.
• The response is stored on the SDK instance. Field names:
  token, refreshToken, expirationSeconds, id.
• ⚠️ The SDK spec/docstrings mention expiresIn / userId; the code reads
  expirationSeconds / id. Use the real names.
• Refresh: Python sdk.refresh_token, which calls POST /account/refresh-token.
• After login the UI calls GET /api/account/user (current user) and periodically
  POST /api/account/ping with { "applicationId", "userSessionId" } to keep the session
  warm. The SDK handles its own session, so tests rarely call these directly - but a stale
  userSessionId/expired token surfaces as 401, so re-login (a fresh SDK instance) on 401.

There is no out-of-band token minting, impersonation, or backdoor. If a token is needed,
it comes from a normal login.

Secret hygiene (non-negotiable)

• Credentials live only in gitignored config (e.g. config/<env>.json), never in code,
  output, logs, commit messages, or tool calls.
• Never print/console.log a config object that contains a password or token.
• Set disableLogging: true (Python) / mute console.log (JS) so the SDK does not echo
  the username.

Config keys (shared)

Portal vs Admin (apiType) - Portal-first

Every SDK method is guarded to exactly one apiType and raises
InvalidAPITypeException if called on the wrong session (no auto-fallback). Always
prefer the Portal API; use an Admin endpoint only when you need an admin-specific
capability that has no Portal equivalent (indexing, workflows, ad-breaks, server/content
administration).

As built, the core asset-management surface (create/upload/get/update/move/delete) is
guarded Admin-only, while the consumer surface (sharing, saved searches, annotations,
tracking) is Portal-only, so a workflow that creates a confined asset and then shares
it needs both session types. The full op-by-op split (and the handful of unguarded
ops that work on either) is in ../reference/api-types.md;
each component also records its requirement as requires_api_type in front-matter.