Quick Start: Connect the API to Your System

Create a key, choose which models it may call, set rate limits and quotas, send the first request, then trace every call in the logs.

This page takes one API key from creation to monitoring: create → scope to models → rate limits → quota → first request → logs.

An API key is the credential your application uses against the Runtime API. Keys start with sk- and travel in the Authorization header as a bearer token.

A key grants no model permission of its own. It can only narrow the set of models its owner is already entitled to use. A model is selectable because the owner already has access to it.

Before you start

Check the workspace at the top left. A key created in a personal workspace is a personal key and its usage lands on your account; a key created in an organization workspace works only inside that organization's model permissions and its usage lands on the organization.
Organization keys can be created and managed only by the organization's creator or collaborators. Ordinary members can view keys and usage but cannot add or modify them.
Pending users cannot create keys.

Step 1. Create the key

Sidebar → Workspace → API keys.

The four cards at the top summarize the account: Keys (total), Manageable, Protected, and Limited (keys with a request, token, or cost limit set).

Click Create key.

Enter a key name (required): letters, digits, _, -, up to 30 characters. Optionally set an expiry — past that time the key no longer authenticates.

Expand Model access and Rate limits and quota (steps 2–4), then click Generate.

In the API key secret dialog, click Copy secret and store it somewhere safe.

This is the only time the full secret is shown. Once the dialog closes the page will not display it again. Losing it means regenerating — and regenerating invalidates the old secret immediately.

The default key

Personal and organization workspaces each get one key marked Default and Protected, used by Studio's internal features and the default inference path.

You can	You cannot
View its usage	Disable or delete it
Regenerate the secret (the old one dies immediately)	Edit its rate limits on this page

Step 2. Choose which models the key may call

In the create dialog, expand Model access → Allowed models:

The list contains both base models and custom models, with a search box.
Empty means every model the owner has. Tick models explicitly to narrow it.
Changes take effect within seconds; no need to regenerate the secret.
A model still in effect on the key but no longer available in this workspace is flagged as unavailable and can be removed.

One key, one purpose. A key for a front-end demo should hold one cheap small model; a key for a batch job should hold only the model it needs. When something goes wrong you can revoke it alone.

The Access column in the key list shows how many models a key is limited to.

Step 3. Set rate limits

In the same dialog, expand Rate limits and quota. There are three independent mechanisms here, and an empty field always means no limit.

Request throttle (per second)

Max requests per second caps how fast this key can send, counting text, image, and audio requests together. It stops bursts; running out of quota is a different thing.

Period limits

Limits can be set separately for minute, hour, day, week, and month, and each period can cap:

Field	What it limits
Max requests	Requests in that period
Max tokens	Total tokens in that period
Max images	Images generated or processed in that period
Max audio seconds	Audio seconds in that period
Max cost (USD)	Money spent in that period; minimum 0.01, at most two decimals

A cost ceiling is the most direct guardrail. If you are unsure which field to fill, set a daily max cost — it covers price changes, traffic spikes, and longer outputs all at once.

Step 4. Set the token quota (rolling window)

Token quota differs from the period limits above: it is a pool that recovers on a rolling window rather than resetting on calendar boundaries.

Enter Total tokens — how many tokens this key may spend inside one window.

Then enter Recovery time (minutes). The dialog requires the total first, and the recovery time must be at least 1 minute.

Once exhausted, requests with this key are rejected until the recovery window resets. The key list shows Remaining quota for the current window.

What happens when a limit is hit

Any exhausted limit rejects subsequent requests with that key until its period or recovery window resets. The caller sees a rate limit error, not a model error.

Step 5. Send the first request

Replace the runtime base URL, key, and model slug with your own:

curl https://your-runtime-base-url/v1/chat/completions \
  -H "Authorization: Bearer sk-your-api-key-here" \
  -H "Content-Type: application/json" \
  -d '{"model":"your-model-slug","messages":[{"role":"user","content":"Hello"}]}'

The model slug comes from a custom model's Overview station or Operate → Integrate, which generates runnable cURL, Python, and JavaScript examples.

This is an OpenAI-compatible API — point an existing OpenAI SDK at the UnieAI base URL and key. Supported endpoints and parameters are in API Compatibility.

Before calling, confirm: the target wallet has balance, the key is neither disabled nor expired, and the key's allowed models include the one you are calling.

Step 6. Read the logs

There are two levels of records, answering different questions.

One key: view usage

⋯ → View usage on the key's row covers that key alone:

Status, created, last used, expiry
Requests, tokens, average tokens, spend
Remaining quota in the current recovery window
Recent usage records — this key's latest requests, paginated

Start here when a key misbehaves: is it not being called at all (a stale "last used"), or out of quota (remaining quota at zero)?

The whole workspace: the usage page

Sidebar → Token usage (/usage) covers the entire workspace. Two tabs at the top:

Tab	Answers
Token usage	What model calls cost
Compute usage	What holding machines costs (reserved quota × time)

The filters have different scopes, and this is easy to misread:

Date range and API key are global — they update the summary cards, charts, performance samples, and request logs.
Endpoint and model narrow only the request log table; they do not recompute the summary cards.

Summary metrics include requests, tokens, spend, throughput, TTFT P50/P99, and latency P50/P99. Missing performance data means unavailable, not zero.

Performance charts and request logs are drawn from the most recent batch of records, while the traffic and spend totals above use the full aggregates. They are expected to disagree — the summary is the ledger, the charts are a sample.

The request log table

Columns: time, request ID, endpoint, model, status, TTFT, throughput, latency, tokens, cost, API key. Headers sort, and API key, endpoint, and model can be filtered from the header. Deleted keys remain in history with a deleted marker.

Clicking a row expands that request: input JSON, output JSON, input/output text, output reasoning text, input images and audio, retrieval results, and trace metadata.

No detail is available when the row has no request ID, the retention window has passed, or the trace backend is unavailable. Failed requests may have incomplete token, timing, or cost fields.

Pulling logs programmatically

GET /api/logs is the API-key-authenticated request log interface:

start_time and end_time are required, as Unix timestamps or parseable date-time strings
model and apiKey filter the result; apiKey must be a valid user API key — filtering is by key identity, not by display name
Give date-time strings an explicit time zone; an end time before the start time returns an error

Step 7. Day-to-day management

The ⋯ menu on a key's row offers, depending on key type and your permissions:

Action	What it does
View usage	See step 6
Edit limits	Update a normal key's rate limits and quota (not available on protected default keys)
Regenerate secret	Issue a new secret; the old one dies immediately
Enable / Disable	Pause or resume requests with this key
Delete	Permanently revoke a normal key

Security practice

Keep secrets in environment variables or a secret manager. Never commit them, never put them in browser-side code, never send them over chat or email.
Use separate keys for development, staging, and production so they can be tracked and revoked separately.
On any suspicion of a leak, regenerate the secret — the old one stops working at once.
Disable or delete keys you no longer use.

Where to look when something is off

Symptom	Check first
Requests return a rate limit error	That key's remaining quota, plus its per-second and period limits
Requests say the model is unavailable	Whether allowed models includes it, and whether the owner has access to it at all
Every request suddenly fails auth	Whether the key was disabled, expired, or regenerated by someone
`/usage` numbers disagree with the summary	Endpoint and model filters affect only the table, not the summary cards
A request's content is missing	That row has no request ID, or it is past the trace retention window