---
title: Authentication | FLORA API
description: Create and manage API keys for the FLORA REST API.
---

The FLORA REST API uses **bearer-token authentication** with API keys. Every request must include an `Authorization` header.

```
Authorization: Bearer sk_live_XXXX
```

API keys grant full access to the workspace they’re scoped to. Never expose them in frontend code, public repos, or logs. Use environment variables or a secrets manager.

For interactive agents (Claude, Cursor, VS Code), use the [MCP/OAuth flow](/mcp/authentication/index.md) instead — it doesn’t require pasting an API key into the client.

## Create a key

1. Sign in to [FLORA](https://app.flora.ai).
2. Open **Settings** → **API Keys**, or go directly to `https://app.flora.ai/projects?openSettings=true&initialTab=apiKeys`.
3. Click **Create API Key**, give it a name, and copy the secret immediately. **It is shown only once.**
4. Store it in a secrets manager or set it as an environment variable.

Keys begin with `sk_live_` (production) or `sk_test_` (sandbox, when available).

## One active key at a time

During the public beta, each workspace can have **one active API key**. To rotate keys:

1. Create the new key in a separate browser window or tab.
2. Update your applications to use the new key.
3. Revoke the old key in **Settings** → **API Keys**.

There is no overlap window with two valid keys, so plan the cutover carefully for production traffic. If you need a hot-swap window, contact support and we can flip it on for your workspace.

## Use the key

### TypeScript

```
import Flora from '@flora-ai/flora';


const client = new Flora({
  apiKey: process.env['FLORA_API_KEY'],
});
```

### Go

```
client := flora.NewClient(
    option.WithAPIKey(os.Getenv("FLORA_API_KEY")),
)
```

### CLI

Terminal window

```
export FLORA_API_KEY="sk_live_XXXX"
flora techniques list
```

### curl

Terminal window

```
curl https://app.flora.ai/api/v1/techniques \
  -H "Authorization: Bearer $FLORA_API_KEY"
```

## Identifying which key made a request

Every response includes a `request-id` header. The request ID uniquely identifies the call in our logs and tells you which key was used. Capture it:

Terminal window

```
curl -i https://app.flora.ai/api/v1/techniques \
  -H "Authorization: Bearer $FLORA_API_KEY"
```

Look for `request-id: req_...` in the response. Include this when contacting support about a specific request.

## What the key can do

An API key inherits the permissions of the workspace it was created in:

| Capability                                                                     | Allowed                    |
| ------------------------------------------------------------------------------ | -------------------------- |
| List and read all resources (Techniques, Projects, Workspaces, Assets, Models) | Yes                        |
| Create runs (consumes credits)                                                 | Yes                        |
| Upload assets                                                                  | Yes                        |
| Create or modify Projects                                                      | If the workspace allows it |
| Manage billing or members                                                      | No (use the FLORA app)     |

Permission-restricted operations return `403 forbidden`. See [Errors](/platform/errors/index.md).

## Revoke a key

In **Settings** → **API Keys**, click **Revoke** on the key. The key stops working immediately — any in-flight or subsequent request with that key returns `401 invalid_api_key`.

Revocation is irreversible. To restore access, create a new key.

## Suspected compromise

If you think a key has leaked:

1. **Revoke it immediately** in the FLORA app.
2. Create a new key and update your applications.
3. Contact support — we can audit recent activity tied to the compromised key.
4. If the leak was a public repo, scrub git history with `git filter-repo` and force-push (treat the key as compromised even after scrubbing — secret scanners may have already cached it).

## Security best practices

- **Server-side only.** Never embed keys in mobile apps, single-page apps, or anything that ships to a user.
- **Environment variables.** Read keys from `process.env`, `os.Getenv`, or a secrets manager (1Password, AWS Secrets Manager, GCP Secret Manager, Vault) — not hardcoded.
- **Separate environments.** Use a dedicated production workspace + key for production traffic. Don’t share a single key across staging and prod.
- **Rotate periodically.** Even without a known compromise, plan a rotation every 90 days.
- **Limit blast radius.** If you have multiple use cases, each in its own workspace, keys are naturally isolated.

## Related

- **[Errors](/platform/errors/index.md)** — what auth failures look like (`401 unauthorized`, `401 invalid_api_key`, `403 forbidden`).
- **[Idempotency](/platform/idempotency/index.md)** — retry safely without duplicate side effects.
- **[MCP authentication](/mcp/authentication/index.md)** — OAuth flow for interactive agents.