Authentication

Bearer keys

Authenticate by sending your key in the Authorization header as a bearer token. Keys are issued per organization and look like amai_sk_.... Create and manage them on the API keys page.

Authorization: Bearer amai_sk_8fK2...

Set the base URL to the gateway and the official OpenAI clients and any OpenAI-compatible tool work unchanged.

curl

curl https://api.advancedmind.ai/v1/chat/completions \
  -H "Authorization: Bearer $AMAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Klara-base-preview-v1",
    "messages": [{ "role": "user", "content": "ping" }]
  }'

Python (openai client)

The OpenAI Python SDK targets the gateway when you set base_url. Read the key from the environment rather than hard-coding it:

from openai import OpenAI

client = OpenAI(
    api_key="amai_sk_...",            # or os.environ["AMAI_API_KEY"]
    base_url="https://api.advancedmind.ai/v1",
)

resp = client.chat.completions.create(
    model="Klara-base-preview-v1",
    messages=[{"role": "user", "content": "ping"}],
)
print(resp.choices[0].message.content)

Base URL

The base URL is https://api.advancedmind.ai/v1 for all clients. Most SDKs accept it as a base_url or baseURL argument; tools that read environment variables honor OPENAI_BASE_URL. Append the standard paths such as /chat/completions and /models as usual.

Key scopes

A scope controls what a key may do. A request outside the key’s scope is rejected before inference, even if your organization holds the matching entitlement.

• standard: calls any standard route published to your account, including an available Klara Base Preview v1 or v2.
• research: calls made under your organization’s approved Research Mode project scope. The organization must hold an active entitlement naming the requested model, and the route must also be live. See Research Mode.

Scope your automation to the minimum it needs. A coding agent that does not need your Research Mode scope should hold a standard key so a leaked credential cannot act under it.

Spend limits

Each key may carry an optional monthly spend limit in USD. Once a key’s month-to-date spend reaches its limit, further requests on that key are rejected until the calendar month rolls over or you raise the limit. The limit is independent of your organization-wide credit balance: a request can be blocked by the key limit even when the org has credits to spare. Leave it unset for no per-key cap. Track spend per key on the usage page.

Revoking keys

Revoke a key the moment it is no longer needed or may have leaked. Revocation is immediate and permanent: the key stops authenticating on the next request and cannot be restored, so issue a new one instead. Past usage attributed to the key is retained for accounting. Revoke from the API keys page.

Security notes

• The secret is shown once. The full key value is returned only at creation time. Copy it immediately into a secret manager; if you lose it, revoke the key and create a new one. The dashboard only ever displays the key prefix afterward.
• Never commit keys. Keep secrets out of source control, client-side bundles, and logs. Load them from environment variables or a secrets store at runtime.
• One key per workload. Separate keys per service or environment so you can revoke and rotate without taking everything down, and so usage is attributable.
• Treat a leaked key as compromised. Revoke it, rotate the replacement, and review the usage log for unexpected activity.

See acceptable use for what the API may be used for.