Skip to main content
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.
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 is limited to the tables selected in the Tables tab.
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.
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 or the Data API:
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.
  • 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.