Authentication

Creating a key

API keys are issued from a workspace on console.artfical.com, on the API keys page. Creating a key there is the only way to get one; there is no way to mint or rotate a key through the API itself, and that's deliberate: key creation is a sensitive, low-frequency action, and putting it behind the console's own authenticated session keeps it out of reach of anything that only has API-level access.

A key looks like this, always with the same prefix:

tai-sk-bSL2q4ja-skivx5JVNaJyyDVtKgiBAxuq8yRzsb6-e8

The full key value is shown exactly once, at the moment you create it. After that, the console only ever shows a truncated form for identification (the first few characters and the last few, with the middle masked). If you lose the full value, there is no way to recover it; the only option is to revoke that key and create a new one. Treat a key the same way you would treat a database password: store it in an environment variable or a secrets manager, not in source code, and never in a client-side application where an end user's browser could read it.

Sending the key on a request

Every request to /v1/chat/completions and /v1/models must include the key in a standard Authorization header, using the Bearer scheme:

Authorization: Bearer tai-sk-bSL2q4ja-skivx5JVNaJyyDVtKgiBAxuq8yRzsb6-e8

This is the exact same header shape OpenAI's own API uses, which is why pointing an existing openai-SDK-based client at tAI is usually a one-line change: set base_url to https://api.artfical.com/v1 and api_key to your tAI key, and the SDK's own request code doesn't need to change.

# Python, using the official openai package
from openai import OpenAI

client = OpenAI(
    base_url="https://api.artfical.com/v1",
    api_key="tai-sk-...",
)

response = client.chat.completions.create(
    model="tai-4.1",
    messages=[{"role": "user", "content": "Merhaba"}],
)
print(response.choices[0].message.content)

A request missing the header entirely, or sending it in the wrong shape (no Bearer prefix, an empty value, a key that doesn't parse), is rejected the same way as an outright invalid key: a 401 with an authentication_error type. See Errors for the exact response shape.

Workspaces and scope

A key belongs to exactly one workspace and can only be used to make requests on that workspace's behalf. There's no concept of a key that spans multiple workspaces, and no way to grant a single key partial access to just some models or some rate limit tier; every key in a workspace has the same access to every model listed on the Models page. If you need to separate usage or billing between two different projects, the answer is two workspaces with their own keys, not one key shared between them.

Usage made with a given key, request counts, token counts, and estimated cost, is attributed to that key and visible in the console's Usage page, scoped to the workspace the key belongs to. This is purely for visibility on your side; it doesn't affect how a request is processed.

Expiration

A key can optionally be created with an expiration date (7, 30, or 90 days out, or never, chosen when the key is created). Once a key passes its expiration date, every request made with it is rejected with the same 401 authentication_error as an invalid key, indistinguishable from the outside. If requests using a previously-working key suddenly start failing with 401, an expired key is the first thing to check, on the API keys page, before assuming something else broke.

There is no automatic renewal. A key nearing its expiration date has to be replaced with a newly created one; the console does not extend an existing key's lifetime in place.

Revoking a key

A key can be revoked at any time from the API keys page, immediately and irreversibly. A revoked key behaves exactly like an expired one from the API's point of view: every subsequent request with it gets 401. Revocation is the right response to a leaked key; there's no way to rotate a key's secret value in place, only to revoke the old one and create a new one to replace it.

What a key does not grant on its own

Holding a valid API key is sufficient to make chat completion requests and list models. It does not grant access to anything in the console UI itself, workspace settings, billing information, or other members' activity; those are gated by the console's own session-based login, entirely separate from API keys. A leaked API key is a real problem, since it lets someone make requests (and incur the associated usage) on your workspace's behalf, but it does not by itself expose your console account or let someone sign in as you.