Service accounts are non-human accounts that own their own API keys. Use them to run integrations, automations, and AI agents that aren't tied to any person's account, with access you control channel by channel.
Service accounts are available on the Enterprise plan, and can only be created and managed by workspace Owners and Admins.
Why use a service account?
Until now, every API key belonged to a person and inherited everything that person could access. That causes problems for automations:
- If the key's owner leaves the workspace, the integration breaks.
- A personal admin key used in shared code gives everyone with that code admin-level access.
- A key can never see less than its owner, so there was no way to scope access down.
A service account solves all three: it isn't tied to anyone, it survives team changes, and it only accesses what you explicitly grant it. Service accounts don't use a paid seat and never appear in your members list.
Typical uses: automated backups and exports, syncing docs from other tools, CI or internal scripts, and giving an LLM or AI agent controlled access to your knowledge base.
Create a service account
Click your workspace logo in the top-left corner.
Select
Settings from the menu, then go to the API section.Under
Service accounts , click New service account .Give it a name (for example "Backup bot") and choose its access level.
Access levels
- Restricted (default): the service account starts with access to nothing. You grant it specific channels or docs, exactly like sharing with a person (see below). Best for least-privilege setups.
- Full workspace : the service account can read all public channels, including ones created later. Best for workspace-wide automations like backups.
You can have up to 10 service accounts per workspace.
Create an API key for a service account
In
Settings → API , find your service account in the Service accounts list.Click
Create key , name the key, and choose its scope: read-only or read & write.Copy the key and store it somewhere safe.
The API key is only displayed once. If you lose it, revoke it and create a new one. Keys can be disabled or revoked at any time without affecting the service account itself.
Use the key
A service account key works everywhere a personal API key does. Requests act as the service account: they can only reach what it has access to, and anything it creates or edits is attributed to it.
With the Slite API
Pass the key in the
x-slite-api-key header, exactly like a personal key (see Slite API and the full API reference ):curl 'https://api.slite.com/v1/search-notes?query=onboarding' \--header 'accept: application/json' \--header 'x-slite-api-key: YOUR_SERVICE_ACCOUNT_KEY'
With the Slite MCP server
The Slite MCP server accepts service account keys as bearer tokens, so there is no OAuth sign-in step. This makes it the right fit for headless agents, CI pipelines, and agent frameworks. Point your MCP client at
https://api.slite.com/mcp with an Authorization header:{"mcpServers": {"slite": {"url": "https://api.slite.com/mcp","headers": {"Authorization": "Bearer YOUR_SERVICE_ACCOUNT_KEY"}}}}
The key's scope controls which MCP tools are available: a read-only key exposes only search and read tools, while a read & write key adds doc creation and editing tools.
For interactive assistants like Claude Desktop or ChatGPT, the OAuth setup described in Slite MCP is usually simpler: the assistant then acts as the signed-in person. Use a service account key when the agent should run unattended or with its own scoped access instead of a person's.
Grant access to channels and docs
A Restricted service account has no access until you give it some. Grant access the same way you share with a person:
Open the channel (or doc) you want the service account to access.
Open the sharing settings and search for the service account by name.
Pick its role: reader or writer.
The service account's API keys can then read (or edit, with a write key) only within those grants. A read-only key can never write, even where the service account has writer access.
Good to know
- Actions are attributed to the service account : docs it creates or edits show the service account as the author, and audit logs record it by name, not the admin who created its key.
- Service accounts can never sign in : they have no password and no email inbox. They only act through their API keys.
- They're free : service accounts don't count toward your billed seats.
- They stay out of the way : they don't appear in your members list, don't receive notifications or emails, and are not provisioned or deprovisioned by SSO/SCIM, so your Okta or Azure AD setup never touches them.
Archive a service account
When an integration is retired, archive its service account from the
Service accounts list in Settings → API. Archiving immediately invalidates all of its API keys and removes its access. This cannot be undone. If you need one again, create a new service account.
FAQ
Should I replace my personal API keys?
Personal keys still work and remain the quickest way to script against your own account. Use a service account whenever the key will live in shared code, run unattended, or needs access different from any one person's.
Can a service account be an admin?
No. Service accounts can be granted reader or writer roles on channels and docs, but they can never hold admin rights, manage members, or change workspace settings. A channel always keeps at least one human admin.
Why don't I see this in my workspace?
Service accounts are an Enterprise feature. If you're on Enterprise and still don't see the section, contact support@slite.com .
