Authentication

Every request to the Tase API is authenticated with an API key. There is no session flow and no OAuth for server-to-server use — one key in one header is all you need.

Key format

API keys are created in your Tase dashboard and always start with the tase_sk_ prefix. The full secret is shown once, at creation time. If you lose it, create a new key — the value cannot be retrieved later.

tase_sk_51xK9mQvT3nP8wRb2cJd7fLh

The Authorization header

Pass the key as a bearer token in the Authorization header on every request:

curl https://api.tase.app/v1/models \
  -H "Authorization: Bearer $TASE_API_KEY"

The same header works for every endpoint, including POST /v1/chat/completions. There are no per-endpoint credentials.

Keep your key secret

• Server-side only. Call the API from your backend. Browsers and mobile apps should talk to your server, and your server talks to Tase.
• Never embed keys in client code. Anything shipped to a browser bundle, app binary, or public repo is readable by anyone. A key in client code is a leaked key.
• Load from the environment. Keep the key in an environment variable or a secrets manager, not in source control or config files that get committed.
• Revoke on leak, immediately. If a key appears in a commit, log, screenshot, or error report, revoke it in the dashboard first and investigate second. Revocation takes effect right away.

What a 401 looks like

A missing, malformed, or revoked key returns HTTP 401 Unauthorized with an error object:

{
  "error": {
    "message": "Invalid API key provided.",
    "type": "authentication_error",
    "code": "invalid_api_key"
  }
}

If you see a 401, check three things in order: the header is exactly Authorization: Bearer tase_sk_... with a space after Bearer, the key has not been revoked, and your environment variable actually contains the key (no quotes, no trailing whitespace).

Key rotation

Rotate keys on a schedule and whenever a team member with key access leaves. Multiple keys can be active at once, so rotation requires no downtime:

1. 1

   Create a new key

   Generate a second key in the dashboard. Both the old and new key work during the transition.
2. 2

   Deploy the new key

   Update the environment variable or secrets manager entry in every service that calls the API, and roll out.
3. 3

   Verify traffic moved

   Confirm your services authenticate successfully with the new key in production.
4. 4

   Revoke the old key

   Delete the old key in the dashboard. Any request still using it will start returning 401, which flags stragglers you missed.