# Create API tokens

> Source: https://elaichi.ai/docs/guides/settings/api-tokens/

Organization API tokens let scripts, CI pipelines, and other systems call the Elaichi API (and MCP flows that require an extra token) without a browser session.

**Where to find it:** **Settings → API tokens**

You need **Manage API tokens** (`api_token:manage`). Without it, the tab shows that access is required. Built-in **Org Owner** and **Org Admin** include this permission.

## How tokens work

| Property | Behavior |
| --- | --- |
| **Scope** | Bound to the **current organization** only |
| **Permissions** | Act as the **person who created** the token — the union of that member’s roles in this org |
| **Secret** | Shown **once** at creation; never viewable again |
| **Revoke** | Immediate; clients using that token fail right away |

Treat a token like a password for whoever created it. If that person’s roles change later, effective access of existing tokens follows their current membership permissions.

## Create a token

1. Open **Settings → API tokens**.
2. Choose **Create API token**.
3. Enter a **Name** that identifies where it will be used (for example `CI pipeline` or `Inventory sync`).
4. Choose **Create**.
5. **Copy the token immediately.** Acknowledge that you stored it securely, then choose **Done**.

The list shows name, created date, and last used (or Never). It never shows the secret again.

**You'll know it worked when:** The new row appears in the table and your client can authenticate with the copied value.

:::callout{type="warning"}
Anyone with the raw token can use this organization within the creator’s permissions. Store it in a secret manager — not in source control or chat.
:::

## Revoke a token

1. On the API tokens list, choose **Revoke** for that row.
2. Confirm. Elaichi asks you to [confirm it’s you](/guides/basics/confirming-sensitive-actions) before the revoke completes.
3. Update any clients that still embed the old value.

Revoke cannot be undone — create a new token if you still need access.

## Good to know

- Tokens are separate from **SCIM tokens** (provisioning only) and from **MCP server** credentials.
- Last used updates when the token successfully authenticates (throttled), so “Never” may simply mean unused.
- Prefer a dedicated admin account with least-privilege roles when minting automation tokens, so the token does not inherit broader Owner access than needed.

## Related

- [Confirming sensitive actions](/guides/basics/confirming-sensitive-actions)
- [Roles and permissions](/guides/members/roles)
- [Creating an MCP server](/guides/mcp-servers/creating-an-mcp-server)
- [Provisioning members with SCIM](/guides/sso/scim-provisioning)