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

# Service accounts

> Scoped keys for CI jobs, BI tools, and agents, independent of any individual person.

A **service account** is a key for programmatic access to Nekt, for CI jobs, BI tools, and AI agents. It is scoped to exactly the capabilities and resources it needs, and it does not depend on any person staying in the workspace. Unlike a personal API token, which inherits the access of the user who created it, a service account has its own access and keeps working regardless of team changes.

> [!NOTE]
>
> Service accounts are available on all **paid plans**. Selecting specific resources requires the **Growth** or **Custom** plan; on **Starter**, each area is either fully included or left out. They are managed in **Settings → Service accounts**, and only workspace Admins can see and manage them. Organization Owners and Admins are Admins of every workspace.

## How a service account is scoped

A service account is defined in three parts:

**1. Account**

A **name**, shown as the actor of everything the account creates or triggers; a **description** of what the account is for; and an **expiration** of 30, 60, or 90 days, 1 year, or a custom date up to one year away. The key stops authenticating once it expires.

**2. Capabilities**

What the account can **do**, grouped by family: **Pipelines**, **Sources & destinations**, **Data API**, **Catalog**, **Volumes**, **Semantic Layer**, **MCPs**, **Permissions**, and **Audit**. Pick only the capabilities it needs.

**3. Access**

Where the account can **act**. Choose **Full access** to reach everything in the areas its capabilities use, including anything created there later, or **Custom scope** to pick resources area by area. Only the areas its capabilities use are shown.

With **Custom scope**, each area has its own tab: **Sources**, **Transformations** (Queries, Notebooks, and Histories), **Destinations**, **Tables**, **Volumes**, **Secrets**, **Context layer**, and **MCPs**. Every tab starts empty. Turn on the tab's **All** toggle (such as **All sources** or **All tables**) to include every resource of that type in the workspace, now and in the future, or select specific items. Selecting a layer or folder includes everything inside it, including tables added later. On **Starter**, Custom scope is a list of areas instead of tabs, and you check each area to include it whole. SQL through the [Data API](https://docs.nekt.com/data-api/introduction.md) is limited to the tables selected in the **Tables** tab.

> [!TIP]
>
> Some actions need resources on more than one tab. Creating a source also needs its output layer or folder in the **Tables** tab; creating a transformation also needs its input tables, output layer or folder, and any volumes and secrets it uses; creating a destination also needs its input tables.

## Create a service account

**1. Open Service accounts**

Go to **Settings → Service accounts** and click **Create service account**.

**2. Describe the account**

Enter a name, a description, and an expiration, then select the capabilities the account needs.

**3. Choose its access**

Choose **Full access**, or **Custom scope** and, for each tab, turn on its **All** toggle or select specific resources.

**4. Save the key**

After creating the account, **copy the key and store it somewhere safe**. For security reasons it is shown only once and cannot be viewed again.

> [!WARNING]
>
> Treat a service account key like a password. It is displayed only at creation and after a rotation. If a key is exposed, rotate it immediately.

## Use the key

Send the key in the `x-api-key` header of each request to the [Platform API](https://docs.nekt.com/platform-api/introduction.md) or the [Data API](https://docs.nekt.com/data-api/introduction.md):

```bash theme={null}
curl --request GET \
  --url https://api.nekt.ai/api/v1/sources/ \
  --header "x-api-key: <service-account-key>"
```

While it works, a service account behaves as follows:

* **Attribution**: everything it creates, triggers, grants, or revokes shows the service account's name as the actor, never a person.
* **What it creates stays in reach**: a source, transformation, destination, or MCP it creates is added to its own scope automatically.
* **Out of reach looks absent**: a resource outside its scope responds as not found, the same as a resource that does not exist.
* **No account management**: it cannot manage workspace users, invitations, MCP tokens, or other service accounts.

## Manage service accounts

The list shows each account's name, the number of capabilities and its scope, who created it and when, its expiry, and when it was last used. From an account's row menu you can:

* **Edit**: change its description, capabilities, or resources. The name and the expiration are set at creation and cannot be changed.
* **Rotate key**: issue a new key. The current one stops working immediately, so anything using it must switch to the new key. The new key is valid for the same period the account was created with, counted from the rotation, so rotating is also how you renew an account, even after it has expired.
* **View logs**: open the account's requests in [Audit logs](https://docs.nekt.com/workspaces/audit-logs.md).
* **Remove service account**: disable the key immediately and delete the account. Requests made with it are rejected, which can break any system still using it. This cannot be undone.

Use the toggle on each row to **activate or deactivate** an account without removing it. A deactivated account's key is rejected until you activate it again.


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