Authentication¶
Genesis Model API and Product API use different credentials and authentication headers. Identify the API first, then send only the credential that API requires. Do not reuse base URLs, headers, or browser sessions across the two API categories.
Choose authentication¶
API target |
Credential |
Authentication header |
Additional scope |
|---|---|---|---|
Genesis Model API |
A Genesis-enabled personal access token or service-account API key |
|
The model must be visible to the current credential. |
Product API |
UC personal access token (PAT) |
|
Workspace resources normally also require |
X-Workspace-ID selects a Product resource and permission scope; it is not a second credential. GET /workspaces is the exception because no workspace has been selected yet.
Call Genesis Model API¶
export GENESIS_BASE_URL='<Complete Genesis Base URL copied from the console>'
export GENESIS_ACCESS_TOKEN='<Genesis access token>'
curl "$GENESIS_BASE_URL/models" \
-H "Authorization: Bearer $GENESIS_ACCESS_TOKEN" \
-H "Accept: application/json"
Use a returned model ID for later inference requests. Protocol-specific SDK parameters and version headers are documented by the relevant SDK or endpoint page.
Call Product API¶
export PRODUCT_API_BASE_URL='<Product API Base URL ending in /newmoi>'
export PRODUCT_API_KEY='<your-personal-access-token>'
curl "$PRODUCT_API_BASE_URL/workspaces" \
-H "X-API-Key: $PRODUCT_API_KEY" \
-H "Accept: application/json"
After selecting a workspace, send the returned ID with X-Workspace-ID on later resource requests. Do not send a Product PAT, an Authorization header, and browser cookies together.
Keep credentials safe¶
Inject credentials through environment variables or a secret manager; do not place them in source code, images, URLs, logs, or screenshots.
Rotate credentials by updating callers and verifying a read-only request before disabling the old credential.
Authentication establishes the caller identity, not permission to operate every model, workspace, or resource.