
A service account is a virtual identity for an integration, bot, or automated process. It exists so that an external system can authenticate against Indicate without using a specific person's credentials, and without depending on any individual team member.
Technical reasons to use a service account:
Stability across team changes. A token paired with a Member User stops working when that person leaves the space. A token paired with a Service User stays valid as long as the integration is needed.
Auditability. Actions performed by an integration show up under the Service User's name in the Audit Log, so it's always clear which integration did what, separated from any human user's activity.
Separation of concerns. Service Users have no login and can't be hijacked through password compromise or session theft. The only credential is the token, which can be rotated or revoked independently.
Typical examples: a customer-data sync bot, a data infrastructure connection that streams metrics into your software tool, an automation that runs on a schedule.
A service account on its own doesn't grant access, it needs a token to authenticate. Service accounts can be paired with either token type:
Agent Tokens for external tool connections (Claude, Cursor, n8n, etc.).
API Tokens for software platforms reading Indicate as a data source. Included with the Enterprise plan.
The typical flow is:
Create a service account (gives the integration an identity in your space).
Generate a token for it under Settings → Tokens (gives it the actual credentials).
Copy paste the token into your third party service
If you revoke a token, the service account stays, you can generate a new token and resume access. If you delete the service account, every token paired with it is revoked and the integration breaks immediately.
Service accounts live under Settings → Team → Service Accounts. From there you can:
Create new service accounts (see → Create a service account).
See the current status, role, and creation date of each one.
Delete service accounts you no longer need (see → Delete a service account).
Tokens are managed separately under Settings → Tokens. See → Tokens for the token types and how to create them.
Only Owners and Admins can create or delete service accounts and generate tokens for them.
A service account is the identity, not the credentials. After creating it, you'll need to pair it with a token under Settings → Tokens before it can authenticate.
Go to Settings → Team and open the Service Accounts tab.
Click the + Add button in the top right and select Create service account.
Enter a Name for the service account. Use something descriptive that tells your team what integration it powers e.g. CRM Sync Bot, Ops Automation, or the consuming platform's name like Chat Bot, Internal Data Warehouse. Generic names like bot1 make it hard to know what depends on the account later.
(Optional) Add a Description explaining what this service account does and which system uses it. The dialog placeholder asks: "What does this service account do?"
Select a Role. The default is User, which is enough for most read access. The role's impact depends on the token type you'll pair the account with later, see the callout below before going higher than User.
Click Create. The service account now appears in your Service Accounts tab
Why the role matters more than you might think:
A service account's role doesn't hit equally for both token types: - Agent Tokens authenticate read-only metric access through MCP-compatible tools. The role barely matters in practice — a User-level Agent Token can do the same things as an Admin-level one when querying metrics. User is always enough. - API Tokens authenticate full Indicate API access. Here the role fully applies: an Admin-level API Token can change space settings, invite or remove team members, create connections, and modify pipelines — programmatically, at any time, with no UI safeguards. If the API Token leaks, an attacker inherits Admin powers. Rule of thumb: Default to User. Only choose Admin if you have a specific API integration that genuinely needs to manage workspace resources — and treat that token's storage with extra care.
A service account on its own can't authenticate. To actually use it:
Go to Settings → Tokens.
Create a new token and assign it to the service account you just created. Choose an Agent Token for tool connections (Claude, Cursor, n8n) or an API Token for data infrastructure use (Enterprise only).
Copy the token immediately. You won't see it again after you close the dialog.
Configure your tool or downstream platform with the token.
Removing a service account is permanent and breaks every integration that depends on it. The account itself disappears, and any token paired with it is revoked immediately.
Identify what depends on it. Check which tool, team, or platform uses this account's token. If you're not sure, look at the service account's name and description, or ask the person who created it.
Disable or repoint the integration first. Either turn it off, or generate a new token on a different account and swap it in before you delete.
Consider just revoking the token instead. If only a token is compromised (e.g. it leaked), you can revoke the token under Settings → Tokens and generate a new one. The service account itself stays intact.
Go to Settings → Team and open the Service Accounts tab.
Find the service account you want to remove in the list.
Click the ⋮ (three-dot menu) on the right side of the service account's row.
Select Remove from the dropdown.
Confirm the removal when prompted.
This action is permanent and cannot be undone. The service account is removed from the space immediately, all tokens paired with it are revoked, and any tool or platform using one of those tokens stops working on the next request. To restore access, you'll need to create a new service account and a new token, then update everything that was using the old credentials.
Once confirmed:
The service account is removed from the Service Accounts tab.
Every token paired with it is revoked immediately. Any external tool, team integration, or platform using one of those tokens will receive an authentication error on the next request.
The removal is recorded in the Audit Log under the Service Users namespace, with timestamp and the Admin or Owner who performed it.
My tool suddenly gets authentication errors after I removed a service account.
Removing a service account revokes every token paired with it. Create a new service account, generate a new token, and update the tool with the new credentials.
Should I revoke the token or delete the service account?
If only the token is compromised, revoke the token under Settings → Tokens and generate a new one. The service account stays intact. Delete the account only when you want to remove the integration's identity entirely.
What role should a service account have?
Default to User. Only choose Admin if an API integration genuinely needs to manage workspace resources, and protect that token carefully.