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

# Authentication

> Organization API keys, where they come from, and what they can do.

Every request carries an organization API key as a bearer token:

```
Authorization: Bearer ek_live_…
```

## Creating and revoking keys

Organization admins create keys in the app under **Settings → Team → API keys**, give each one a
name and an optional expiry, and can revoke any key at any time. Any member can see the list
(name, prefix, creator, last used); only admins create and revoke. A workspace can hold up to
25 active keys.

The secret is shown once, at creation. Ekly stores only a hash, so a lost key cannot be recovered;
revoke it and create a new one.

## Environments

| Prefix | Where it works |
| - | - |
| `ek_live_` | `https://api.ekly.ai` (production) |
| `ek_test_` | `https://api-staging.ekly.ai` and local development |

A key is bound to the environment and organization it was created in.

## What a key can reach

A key calls the `/v1` endpoints and nothing else. Requests to any other path return `403` with
code `api_key_scope`. Sessions for the app itself stay separate.

## Who gets billed

Generations charge your organization's credits **as the person who created the key**, so if your
workspace sets per-member credit caps, the creator's cap applies to the key. If the creator leaves
the organization, their keys stop working on the next request.

## Keeping keys safe

* Load the key from an environment variable or a secret manager; never commit it.
* Create one key per integration so a leak can be revoked without breaking the others.
* Set an expiry for keys used in short-lived jobs.
* If a key leaks, revoke it in Settings → Team first; rotation beats cleanup.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.