Identity
EntityRef — the lightweight (type, id, name?) reference used throughout the SDK — and identity information from login.
EntityRef
EntityRef is a frozen dataclass used everywhere in the SDK to refer to a server-side entity without hydrating its full record. You will encounter it in IngestResult.origin_nodes, WorkflowNode.label_ref, AuditEvent.actor_ref, and many other places.
from optixlog import EntityRefSignature
@dataclass(frozen=True)
class EntityRef:
type: str
id: str
name: str | None = NoneFields
Prop
Type
Example
from optixlog import EntityRef
ref = EntityRef(type="workflow_node", id="node_abc123", name="FDTD Simulation Run 42")
print(ref.type) # workflow_node
print(ref.id) # node_abc123
print(ref.name) # FDTD Simulation Run 42Identity information from login
When you run optixlog login, the CLI calls the server's v0.whoami endpoint and caches the response in ~/.optixlog/credentials.toml. The following fields are stored alongside the API key:
| Field | Type | Description |
|---|---|---|
key_type | str | "service" or "user". Service keys belong to a service account; user keys belong to a human user. |
organization_id | str | The ID of the organization associated with the key, e.g. "org_abc123". |
user_email | str | The email address of the authenticated user or service account. |
These fields are available on the StoredCredential returned by resolve_credential() and are displayed by optixlog whoami.
from optixlog._credentials import resolve_credential
cred = resolve_credential()
print(cred.key_type) # service
print(cred.organization_id) # org_abc123
print(cred.user_email) # founder@optixlog.comStoredCredential is not part of the public Management API
StoredCredential is used internally by OptixClient and the CLI. You typically do not need to call resolve_credential() directly — OptixClient() handles it for you.