---
updatedAt: 2025-11-17T00:43:10.000Z
agentTools:
  projectIndex: https://docs.split.io/llms.txt
---

# API Keys Overview

Use these endpoints to create or delete an API key.

> 🚧 Management of `admin` API keys will be moving
>
> As a part of integrating with Harness,`admin` API keys will soon be managed by general Harness systems. We recommend against creating any new integrations that manage `admin` API keys with this endpoint unless it is for a temporary purpose.
>
> The `server_side` and `client_side` SDK API keys will continue to be managed using this endpoint.
>
> For more information, go to [Before and After Guide: API for Split Admins](https://help.split.io/hc/en-us/articles/34773611130893-Before-and-After-Guide-API-for-Split-Admins).  You can also contact us at <support@split.io> and we will be happy to guide you to the best path forward.

***

When creating an API key, the key itself is returned in the response body.

> ❗️ Keep your server\_side and admin keys private
>
> Never expose `admin` and `server_side` API keys in untrusted contexts.
>
> Do not put your `admin` or  `server_side` API keys in client-side JavaScript or mobile SDKs. Split has special  `client_side` API keys that you can use in JavaScript, Android, and iOS.
>
> If you accidentally expose your API key, revoke it in the APIs tab in Account settings or using the [Delete an API key](https://docs.split.io/reference/delete-an-api-key) endpoint.
>
> Be sure to copy your Admin API key once it's generated. For security purposes, **you won’t see the key again**.

In addition to API keys, you can authenticate with Harness [personal access tokens (PATs)](/docs/platform/automation/api/api-quickstart/#create-a-harness-api-key-and-toke). For more information, see [Authentication](https://docs.split.io/reference/authentication).

### API key types

There are three types of keys that can be created:

* `admin` API keys are used for access to the Split Admin API endpoints.
* `server_side` API keys are recommended to use with SDKs that live in your infrastructure (for example, your servers).
* `client_side` API keys are for SDKs living in public environments (for example, browsers or mobile clients).

### Admin API key roles

Roles aim to limit the access and operations a key can perform within Split within two functional areas - Administrative Permissions and Resource (Feature Flag & Segment) Permissions.\
Here is a brief overview of the new roles introduced that can be specified while creating an Admin API key using Split API:

> 🚧 Important
>
> * Roles are not editable, once assigned, they cannot be changed.
> * A valid Admin API key cannot create another Admin API key with more roles than it contains.
> * Roles can be combined.

<Table align={["left","left","left"]}>
  <thead>
    <tr>
      <th>

      </th>

      <th>
        Role
      </th>

      <th>
        Description
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        **Administrative Permissions**
      </td>

      <td>
        `API_ALL_GRANTED`
      </td>

      <td>
        A key with this role grants access to all of your Account's settings and resources via Split API.\
        This is the **default role** if none is specified.\
        Admin API keys created before `Aug 2023` are associated to this role.
      </td>
    </tr>

    <tr>
      <td>

      </td>

      <td>
        `API_APIKEY`
      </td>

      <td>
        A key with this role allows the creation and deletion of other API keys.
      </td>
    </tr>

    <tr>
      <td>

      </td>

      <td>
        `API_ADMIN`
      </td>

      <td>
        Reduced Admin capabilities.\
        This role enables administration of the account via Split API. However, this role excludes permission to manage `API Keys` and the following resources: `feature flags`, `segments`, `change requests`, `tags`, and `rollout statuses`.
      </td>
    </tr>

    <tr>
      <td>

      </td>

      <td>
        `API_WORKSPACE_ADMIN`
      </td>

      <td>
        Admin capabilities within a project (formerly known as workspace), similar to `API_ADMIN`, but excluding  permission to manage `users` and `groups`.
      </td>
    </tr>

    <tr>
      <td>
        **Resource Permissions**\
        Feature Flags
      </td>

      <td>
        `API_FEATURE_FLAG_VIEWER`
      </td>

      <td>
        View-only access to `feature flags` including permission to view associated `tags`, `change requests` and `rollout statuses`.
      </td>
    </tr>

    <tr>
      <td>

      </td>

      <td>
        `API_FEATURE_FLAG_EDITOR`
      </td>

      <td>
        Grants access to all `feature flag` operations including operations related to associated `tags`, `change requests` and `rollout statuses`.
      </td>
    </tr>

    <tr>
      <td>
        **Resource Permissions**\
        Segments
      </td>

      <td>
        `API_SEGMENT_VIEWER`
      </td>

      <td>
        View-only access to `segments` including permission to view associated `tags` and `change requests`.
      </td>
    </tr>

    <tr>
      <td>

      </td>

      <td>
        `API_SEGMENT_EDITOR`
      </td>

      <td>
        Grants access to all `segment` operations including operations related to associated `tags` and `change requests`.
      </td>
    </tr>
  </tbody>
</Table>

### Admin API key scopes

Admin API keys can be scoped to different levels of access:

* `Global` - access to all current and future resources **across the org**.
* `Workspace` - access to all current and future resources **across a single project (formerly known as workspace)**.
* `Environment` - access to all current and future resources **across the environments selected**.