Create, store, and test an API key safely.

Direct answer

Create a key in the console

1. Create an account or sign in to an existing account.
2. Open API Keys and choose the add-token action.
3. Give the key a name that identifies its environment or workload, such as development, staging, or production.
4. Review the expiry, quota, model, and IP restrictions available in the console. Use limits that match the workload instead of granting more access than required.
5. Submit the key settings, copy the value from the token list, and move it directly into the intended secret store.

Keep the key outside application code

Use PRIMORDIAL_API_KEY as the local environment-variable name so the credential source is explicit when the same OpenAI SDK is used with a custom base URL.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["PRIMORDIAL_API_KEY"],
    base_url="https://www.primoraihub.com/v1",
)

The official OpenAI API key safety guidance recommends server-side storage, environment variables or a key-management service, no client-side deployment, no repository commits, usage monitoring, and rotation. Those are general credential practices; they are not an OpenAI endorsement of Primordial AI.

Test the key without spending a generation request

After setting PRIMORDIAL_API_KEY in the current server-side shell or secret-injected runtime, call the live discovery endpoint:

test -n "$PRIMORDIAL_API_KEY" || {
  echo "PRIMORDIAL_API_KEY is not set" >&2
  exit 1
}

curl --fail-with-body \
  https://www.primoraihub.com/v1/models \
  -H "Authorization: Bearer $PRIMORDIAL_API_KEY"

Read model identifiers from data[].id, choose one deliberately, and test the exact endpoint your application needs. See the model discovery guide and custom base URL guide for the next steps.

The OpenAI API authentication reference documents the Bearer-header pattern and recommends loading keys from an environment variable or key-management service on a server. This page applies the same request pattern to Primordial AI's compatible base URL.

Send one minimal first generation request

Copy one current identifier from data[].id in the GET /v1/models response. Set it explicitly instead of guessing a model name, then send this non-streaming Chat Completions request from the same server-side shell:

export PRIMORDIAL_MODEL_ID="MODEL_ID_FROM_V1_MODELS"

test -n "$PRIMORDIAL_API_KEY" || {
  echo "PRIMORDIAL_API_KEY is not set" >&2
  exit 1
}

curl --fail-with-body \
  https://www.primoraihub.com/v1/chat/completions \
  -H "Authorization: Bearer $PRIMORDIAL_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @- <<JSON
{
  "model": "$PRIMORDIAL_MODEL_ID",
  "messages": [
    {"role": "user", "content": "Reply with exactly: connected"}
  ],
  "stream": false
}
JSON

This request may consume account quota or balance. For this exact non-streaming check, require curl to exit successfully and verify that the JSON response contains a non-empty choices[0].message.content. That proves only that this request shape and selected model returned a result at that time; it does not validate streaming, tools, every model, or another endpoint.

If the request fails, preserve the HTTP status and request identifier but never the Authorization header, then use the error troubleshooting guide. If the application uses the newer Responses API instead, follow the separately tested Responses API guide.

Troubleshoot HTTP 401 without exposing the key

A live request to Primordial AI's GET /v1/models without authentication returned HTTP 401 on 2026-08-24. If an authenticated test returns 401:

1. Confirm that the environment variable exists, but do not print its value.
2. Confirm the header name is exactly Authorization and its value starts with Bearer .
3. Remove accidental quotes, newlines, leading spaces, or trailing spaces from the stored secret.
4. Confirm the key came from the intended Primordial AI account and has not been disabled or deleted.
5. Confirm the request URL is https://www.primoraihub.com/v1/models, not a dashboard URL or another provider's API host.

Log the HTTP status and a request identifier when available. Never log the Authorization header or full key. For 404, model-not-found, 429, 5xx, timeout, or connection failures, use the full API error troubleshooting guide.

Rotate without creating an avoidable outage

1. Create a replacement key with the intended name and restrictions.
2. Update the secret manager or deployment environment without deleting the current key.
3. Run the authenticated GET /v1/models check and one minimal request against the production endpoint.
4. Switch the workload to the replacement and monitor authentication errors.
5. Revoke the old key only after the replacement is confirmed, then review usage for unexpected activity.

Frequently asked questions