> This is a page from the ElevenLabs documentation. For a complete page index, fetch https://elevenlabs.io/docs/llms.txt. For the full documentation in a single file, fetch https://elevenlabs.io/docs/llms-full.txt.

# API Keys

## Overview

API keys authenticate your requests to the ElevenLabs API and track usage against your workspace's quota. There are two types:

* **User API keys** belong to an individual user and inherit that user's access to workspace resources. They are well suited to personal development and scripts, and can be given an [expiry](#expiring-user-api-keys) so they stop working automatically after a set period. Because they are tied to a person, a user API key is affected if that user's access changes or they leave the workspace. Creating personal API keys requires a [Full Seat](/docs/overview/administration/workspaces/members#full-seats).
* **Service account API keys** belong to a [service account](/docs/overview/administration/workspaces/service-accounts) rather than an individual, so they keep working regardless of changes to individual membership. They are recommended for backend systems, automation, and production workloads. Service accounts are available to multi-seat customers and are managed by workspace admins.

**Your API key is a secret.** Do not share it with others or expose it in client-side code (browsers, apps). For details on how to send your key with a request, see the [API Authentication](/docs/api-reference/authentication) reference.

Both types of key can be restricted in several ways:

1. **Scope restriction:** limit which API endpoints the key can access.
2. **Credit quota:** set a custom credit limit to control usage.
3. **IP allowlisting:** restrict the key to specific IP addresses or CIDR ranges. See [IP allowlisting](#ip-allowlisting).

## Expiring user API keys

User API keys can be given an expiry so they stop working automatically after a set period. This limits the window in which a leaked or forgotten key can be used and suits the short-lived nature of keys tied to an individual.

Set an expiry when you create or edit a key from your [personal API keys settings](https://elevenlabs.io/app/settings/api-keys). Use the **Expire After** selector to choose a preset ranging from 15 minutes to 30 days, or leave it as **Never** (the default). The **Expires** column shows when each key will lapse.

Once a key passes its expiry it stops authenticating, and requests made with it are rejected with a [`401` error](/docs/eleven-api/resources/errors). You can extend or clear the expiry by editing the key before it lapses; otherwise, [rotate](#rotating-api-keys) to a new key.

> **Note**
>
> Expiry applies only to user API keys. Service account API keys are intended for long-lived backend
> and production workloads, so they do not expire.

## Rotating API keys

> **Info**
>
> When creating a new API key to replace one that you are rotating out, copy the permissions from
> the old key to the new one so that no access is lost. For service account keys, make sure to
> create the new key for the same service account.

Rotation follows the same pattern in both cases: create a new key, switch your applications over to it, then delete the old key.

**User API keys** are rotated from the dashboard. Open your [personal API keys settings](https://elevenlabs.io/app/settings/api-keys), create a new key, and delete the old one once you have switched over.

**Service account API keys** can be rotated from the dashboard or via the API:

* In the dashboard, click your profile icon in the top right corner, select **Workspace settings**, and open the **Service Accounts** tab. Create a new key for the same service account, then delete the old one once you have switched over.
* Via the API, [create a new key](/docs/api-reference/service-accounts/api-keys/create) for the same service account, then [delete the old one](/docs/api-reference/service-accounts/api-keys/delete).

## IP allowlisting

You can restrict an API key so that it only works from specific IP addresses or CIDR ranges. Requests made from any other IP will be rejected with a [`403` error](/docs/eleven-api/resources/errors).

### Supported formats

* Individual IPv4 addresses (e.g. `203.0.113.10`)
* Individual IPv6 addresses (e.g. `2001:db8::1`)
* CIDR ranges (e.g. `203.0.113.0/24`)

You can add between 1 and 100 entries per API key. Bare IP addresses are automatically normalized to `/32` (IPv4) or `/128` (IPv6).

> **Note**
>
> Private IP ranges (e.g. `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`) are not accepted. Only
> public IP addresses can be allowlisted.

## Detecting leaked keys

ElevenLabs participates in [GitHub's secret scanning partner program](https://docs.github.com/en/code-security/secret-scanning/secret-scanning-partner-program). If an ElevenLabs API key is committed to a public GitHub repository, GitHub notifies ElevenLabs and the key is automatically disabled to prevent unauthorized use.

A key disabled this way reports a `disable_reason` of `exposed_publicly`. To restore access, [rotate the key](#rotating-api-keys) and update your applications to use the new one.

> **Note**
>
> Automatic disabling of leaked keys only applies when third-party disabling is allowed for the key.
> See [Controlling who can disable keys](#controlling-who-can-disable-keys).

## Self-disabling a key

If you believe a key has been compromised, the holder of the key can disable it directly using the [Disable API key](/docs/api-reference/api-keys/disable) endpoint. Call it with the query parameter `api_key_name=self`, which is required as an explicit confirmation that you intend to disable the key used to authenticate the request.

## Controlling who can disable keys

The `third_party_disable_allowed` setting controls whether a key can be disabled by its holder, either through the self-disable endpoint or automatically when it leaks publicly. By default, this is enabled for non-Enterprise plans and disabled for Enterprise plans.

> **Note**
>
> A notification email is sent to the workspace owner and the key's owner when a key is disabled by
> a third party, either automatically through GitHub secret scanning or through the self-disable
> endpoint. Disabling a key yourself in the web UI does not send a notification.

**Per key:** set `third_party_disable_allowed` when you [create](/docs/api-reference/service-accounts/api-keys/create) or [update](/docs/api-reference/service-accounts/api-keys/update) a service account API key. Omit it to use the workspace default, or pass `clear` on update to reset an individual key to the workspace default.

**Workspace-wide:** workspace admins can override every key's setting at once using the [Set workspace third-party disabling policy](/docs/api-reference/api-keys/set-third-party-disabling-policy) endpoint:

* `true` allows every key in the workspace to be disabled by its holder.
* `false` forbids it for every key.
* `null` removes the workspace-wide override, so each key's own value and the plan default apply again.