Service Accounts

Last updated: January 30, 2026

Summary

Service Accounts are non-human (bot) users designed for integrations, automation, and API access. They allow teams to authenticate without tying credentials to an individual user, improving security, auditability, and ownership.

What is a Service Account?

A Service Account is a machine identity in Span. Unlike personal user accounts, service accounts are not associated with an individual person.

They are intended for:

  • Automation

  • CI/CD pipelines

  • External integrations

  • Background jobs

  • Bots and system-level access

Service accounts authenticate using bearer tokens and appear in logs and audit trails as the service account itself — not a human user.

Why use Service Accounts?

Service accounts help teams:

  • Avoid personal credentials in automation

    No more shared or long-lived personal access tokens.

  • Improve security and auditability

    Actions are clearly attributed to a specific service account.

  • Reduce risk when team members change

    Automation continues to work even if employees leave.

  • Create clearer ownership

    Tokens belong to systems, not people.

Core Capabilities

Bot User Creation

  • Create accounts for CI/CD pipelines, scripts, and external tools

  • Each service account receives its own API credentials

  • Actions are attributed to the service account

Authentication

  • Authenticate using bearer tokens

  • Tokens can be rotated or revoked at any time

Access Control

You can control access to each service account in two ways:

  • By role (e.g. entire teams)

  • By individual users

Notes:

  • The creator of a service account automatically retains access

  • Role- and user-based access can be combined

Managing Service Accounts

Service accounts can be managed from:

Organization Settings → Service Accounts

From there, you can:

  • Create new service accounts

  • Generate or rotate tokens

  • Assign access

  • Revoke or delete service accounts

Common Use Cases

Service accounts are ideal for:

  • CI/CD pipelines and deployment automation

  • Querying the catalog from external systems

  • Ingesting or exporting DORA metrics

  • Webhook processors

  • Scheduled jobs

  • AI agents and assistants (e.g. Claude integrations)

Best Practices

  • Use clear, descriptive names (e.g. ci-bot, claude-bot, metrics-ingest)

  • Prefer service accounts over personal access tokens for shared tools

  • Rotate tokens regularly

  • Grant the minimum required permissions

Migrating from Personal Tokens

If you currently use personal access tokens for automation:

  1. Create a service account

  2. Generate a service account token

  3. Update your integration or script

  4. Revoke the old personal token