> ## Documentation Index
> Fetch the complete documentation index at: https://docs.teasy.link/api-v1/llms.txt
> Use this file to discover all available pages before exploring further.

# Authentication

> Every request carries an API key in the Authorization header.

```text theme={null}
Authorization: Bearer tsl_live_<32 characters><32 characters>
```

Keys are issued from the API Keys page of your dashboard. The full value is shown **once**, right after creation — save it then. Afterwards you will only see its first six characters, enough to tell your keys apart in a list. A key you have lost cannot be recovered, only revoked andAPI Keys page of your dashboard. The full value is shown **once**, right after creation — save it then. Afterwards you will only see its first six characters, enough to tell your keys apart in a list. A key you have lost cannot be recovered, only revoked and replaced.

## What a key looks likeWhat a key looks like

```text theme={null}
tsl_live_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
└┬┘ └─┬┘ └───────────────┬──────────────┘
 │    │                  └── 32 random characters, unique to this key
 │    └────────────────────── key's environment
 └─────────────────────────── our platform identifier
```

The `tsl_live_` prefix is stable, which means secret scanners can be taught to recognise it. If you keep configuration in a repository, it is worth enabling that.

## Rules

* **Header only.** The key is never accepted as a query parameter, since query strings leak into places you do not control.
* **Server-side only.** Cross-origin browser calls to `/v1` are not permitted. A key shipped in a frontend bundle can be read by any visitor.
* **Several keys per account.** Your plan sets how many are active at once. More than one is what makes rotation possible without downtime: issue, deploy, then revoke. They share one quota rather than adding to it — see [Rate limits](/api-v1/api-v1/rate-limits#one-budget-several-keys).
* **No expiry, and version-neutral.** The same key works on `/v1` and on any future major version, so migrating means changing a URL, not reissuing a secret.

## Plan changes and suspension

A downgrade revokes nothing. We check the plan on every request, so the key simply starts returning `403 api_access_not_available_on_current_plan`, and it works again the moment you return to a plan that includes the API. The same is true of a suspended account, which returns `403 account_suspended`.

## Failures

A missing, malformed, revoked or unknown key all return `401 invalid_api_key`. The response does not tell you which of those it was — if it did, it would help someone guessing at keys narrow the search. Repeated rejected requests from one address are throttled with a `429`, so check the key rather than retrying.

```text theme={null}
tsl_live_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
└┬┘ └─┬┘ └───────────────┬──────────────┘
 │    │                  └── 32 random characters, unique to this key
 │    └────────────────────── key's environment
 └─────────────────────────── our platform identifier
```

The `tsl_live_` prefix is stable, which means secret scanners can be taught to recognise it. If you keep configuration in a repository, it is worth enabling that.

## Rules

* **Header only.** The key is never accepted as a query parameter, since query strings leak into places you do not control.
* **Server-side only.** Cross-origin browser calls to `/v1` are not permitted. A key shipped in a frontend bundle can be read by any visitor.
* **Several keys per account.** Your plan sets how many are active at once. More than one is what makes rotation possible without downtime: issue, deploy, then revoke. They share one quota rather than adding to it — see [Rate limits](/api-v1/api-v1/rate-limits#one-budget-several-keys).
* **No expiry, and version-neutral.** The same key works on `/v1` and on any future major version, so migrating means changing a URL, not reissuing a secret.

## Plan changes and suspension

A downgrade revokes nothing. We check the plan on every request, so the key simply starts returning `403 api_access_not_available_on_current_plan`, and it works again the moment you return to a plan that includes the API. The same is true of a suspended account, which returns `403 account_suspended`.

## Failures

A missing, malformed, revoked or unknown key all return `401 invalid_api_key`. The response does not tell you which of those it was — if it did, it would help someone guessing at keys narrow the search. Repeated rejected requests from one address are throttled with a `429`, so check the key rather than retrying.