# service-accounts

Source: https://docs.applivery.com/en/platform/api/service-accounts/

---

---
title: Service Accounts
description: >-
  Applivery Service Accounts for secure, automated API access — roles,
  permissions, and best practices for token management.
slug: service-accounts
type: article
collection: docs
locale: en
visible: true
canonical: 'https://docs.applivery.com/en/platform/api/service-accounts/'
category: App Distribution
section: API
platform: API
audience: administrators
difficulty: intermediate
keywords:
  - Service Account
  - API
  - Automation
  - Bearer Token
  - Workspace API
  - CI/CD
  - Security
item_name: Service Accounts
schema_type: TechArticle
faqs:
  - question: What is an Applivery Service Account?
    answer: >-
      A Service Account is a special Applivery account for non-human
      authentication, representing an automated system that interacts with the
      Applivery API.
  - question: How do Service Accounts authenticate?
    answer: >-
      Service Accounts authenticate against the Workspace API using a Bearer
      token, granting workspace-level access.
  - question: When should I use a Service Account vs. an App API Token?
    answer: >-
      Use a Service Account for workspace-wide access (multiple apps) and the
      Workspace API. Use an App API Token for single-app access and the
      Integrations API.
  - question: What roles can I assign to a Service Account?
    answer: >-
      You can assign Admin (full access), Developer (app resource access), or
      Viewer (read-only access) roles to a Service Account.
  - question: How do I create a Service Account in Applivery?
    answer: >-
      Go to Workspace Settings > Service Accounts and click '+ Create Service
      Account'. You must have Admin permissions.
  - question: Where can I find the Service Account Bearer token?
    answer: >-
      The Bearer token is displayed after creating the Service Account. Copy it
      immediately, as it cannot be retrieved later.
  - question: How should I store the Service Account Bearer token securely?
    answer: >-
      Store the token as a secret in your CI/CD platform or secret manager, and
      never commit it to source control.
  - question: What Applivery features require a Service Account?
    answer: >-
      The Workspace API, BrowserStack App Live integration, and cross-app
      automation scripts require a Service Account.
language: en
domain: api-management
capability: api-authentication
headline: Understanding and Using Service Accounts for API Access
target_keyword: Applivery Service Account
secondary_keywords:
  - Workspace API
  - Bearer Token
  - API Authentication
intent: informational
reading_time: 8
prerequisites:
  - Basic understanding of APIs
  - Familiarity with Applivery platform
  - Knowledge of authentication methods
faq_items:
  - question: What is an Applivery Service Account?
    answer: >-
      A Service Account is a special Applivery account for non-human
      authentication, representing an automated system that interacts with the
      Applivery API.
  - question: How do Service Accounts authenticate?
    answer: >-
      Service Accounts authenticate against the Workspace API using a Bearer
      token, granting workspace-level access.
  - question: When should I use a Service Account vs. an App API Token?
    answer: >-
      Use a Service Account for workspace-wide access (multiple apps) and the
      Workspace API. Use an App API Token for single-app access and the
      Integrations API.
  - question: What roles can I assign to a Service Account?
    answer: >-
      You can assign Admin (full access), Developer (app resource access), or
      Viewer (read-only access) roles to a Service Account.
  - question: How do I create a Service Account in Applivery?
    answer: >-
      Go to Workspace Settings > Service Accounts and click '+ Create Service
      Account'. You must have Admin permissions.
  - question: Where can I find the Service Account Bearer token?
    answer: >-
      The Bearer token is displayed after creating the Service Account. Copy it
      immediately, as it cannot be retrieved later.
  - question: How should I store the Service Account Bearer token securely?
    answer: >-
      Store the token as a secret in your CI/CD platform or secret manager, and
      never commit it to source control.
  - question: What Applivery features require a Service Account?
    answer: >-
      The Workspace API, BrowserStack App Live integration, and cross-app
      automation scripts require a Service Account.
how_to_steps: []
updatedDate: '2026-04-01'
show_child_grid: true
featured: false
noindex: false
evergreen: false
pillar_content: false
og_title: 'Applivery Service Accounts: Secure API Access'
og_description: >-
  Learn how to use Applivery Service Accounts for secure, automated API access.
  Understand roles, permissions, and best practices.
og_type: article
og_template: gradient-modern
twitter_card: summary_large_image
summary: >-
  Applivery Service Accounts provide a secure way for non-human entities like
  automated systems and CI/CD pipelines to interact with the Applivery API. They
  use Bearer tokens for authentication and offer workspace-level access,
  enabling cross-app automation and platform-level integrations. Understanding
  the roles, permissions, and secure storage of these tokens is crucial for
  maintaining the security of your Applivery workspace.
tldr: >-
  Applivery Service Accounts enable secure, automated API access for non-human
  entities using Bearer tokens and workspace-level permissions.
answer_target: >-
  An Applivery Service Account is a special type of account designed for
  non-human, machine-to-machine authentication with the Applivery API. It uses a
  Bearer token for authentication and provides workspace-level access, allowing
  automated systems, integrations, or pipelines to interact with resources
  across all apps and modules in your organization. This is ideal for cross-app
  automation and platform-level integrations.
key_takeaways:
  - Service Accounts are for non-human API access.
  - Bearer tokens provide workspace-level access.
  - Securely store and rotate tokens regularly.
  - Choose the appropriate role based on the principle of least privilege.
  - Understand the difference between Service Accounts and App API Tokens.
main_topics:
  - Service Account creation
  - Roles and Permissions
  - Bearer token usage
  - Secure token storage
  - Service Account vs App API Token
entities:
  - Applivery
  - Workspace API
  - BrowserStack App Live
  - GitHub Actions
  - Azure Pipelines
  - Bitrise
  - Jenkins
related_queries:
  - What is an Applivery Service Account?
  - How do I create an Applivery Service Account?
  - What are the different roles for Applivery Service Accounts?
  - How do I use a Bearer token for API authentication?
  - Where should I store my Applivery Service Account token?
  - What is the difference between a Service Account and an App API Token?
  - How do I manage existing Applivery Service Accounts?
  - How to rotate Applivery Service Account tokens?
related_topics:
  - app-api-token
  - workspace-api
  - api-authentication
content_scope: comprehensive
confidence_level: well-established
limitations: This guide provides comprehensive coverage of the topic.
update_frequency: occasionally
word_count: 858
sources: []
organization: Not specified
related_articles: []
see_also: []
translations: {}
doc-type: api-reference
section: "api-reference"
---
A Service Account is a special type of Applivery account designed for non-human, machine-to-machine authentication. Unlike user accounts, which are tied to a person, a Service Account represents an automated system, integration, or pipeline that needs to interact with the Applivery API on its own behalf.

Service Accounts authenticate against the **Workspace API** (Organizations API) using a Bearer token. This gives them Workspace-level access to resources across all Apps and modules in your organization, making them the right credentials for cross-app automation and platform-level integrations.

* * *

## Service Accounts vs. App API Tokens

Applivery has two distinct authentication mechanisms. Choosing the right one for your use case is important:

|  | Service Account | App API Token |
| --- | --- | --- |
| **Scope** | Workspace-wide — all Apps in the organization | Single app only |
| **Used for** | Workspace API (Organizations API) | Integrations API (per-app upload, Publications, Builds) |
| **Typical use cases** | Cross-app automation, BrowserStack App Live, Workspace-level scripts | CI/CD build uploads, per-app integrations |
| **Token format** | Bearer token | App Token string |
| **Created in** | Workspace Settings → Service Accounts | App Settings → API Tokens |

If you need to upload Builds from a CI/CD pipeline for a single app, use an [App API Token](https://docs.applivery.com/en/app-distribution/api/app-api-token/). If you need to query or manage resources across multiple Apps, or connect a third-party platform like BrowserStack App Live, use a Service Account.

* * *

## Roles and Permissions

When creating a Service Account, you assign it one of three roles. The role determines what operations the Service Account can perform across the Workspace:

| Role | Description |
| --- | --- |
| **Admin** | Full access to all Workspace resources and settings. Can create, modify, and delete any resource. |
| **Developer** | Read and write access to app resources (Builds, Publications, configurations). Cannot manage Workspace settings or other users. |
| **Viewer** | Read-only access to Workspace resources. Cannot create or modify any data. |

:::tip
Follow the principle of least privilege: assign the most restrictive role that still allows the Service Account to perform its intended function.
:::

* * *

## Creating a Service Account

Service Accounts are managed from your Workspace Settings. Only users with **Admin** permissions can create or delete Service Accounts.

Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to your **Workspace Settings** 1 from the top dropdown menu, then open **Service Account** 2 in the left-hand menu and click the **\+ Create Service Account** 3 button.

![Service Account](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7b329256-a6af-40b1-a101-837f11ca1866.png)

Enter a descriptive name for the account (e.g., `ci-pipeline`, `browserstack-integration`), and select a **Role**: Admin, Developer, or Viewer. Once you're doine click **Create**.

:::warning
Don’t forget that you’ll also need to grant permissions to the Service Account depending on the segment where you want it to be used. You can read more about segment-based permission assignment at the following [link](https://docs.applivery.com/en/device-management/general-settings/segments/#how-to-create-segments-and-permissions).
:::

The Service Account details will be displayed:

| Field | Description |
| --- | --- |
| **Account** | The Service Account identifier, in the format `{service-account-id}@{organization-id}.iam.applivery.io` |
| **Bearer token** | The authentication token used in API requests. |

:::warning
Copy the Bearer token immediately. For security reasons, Applivery does not display the full token again after you leave this screen. If you lose the token, you will need to delete the Service Account and create a new one.
:::

* * *

## Using the Bearer token in API requests

Pass the Bearer token in the `Authorization` header of every Workspace API request:

```bash
curl 'https://api.applivery.io/v1/organizations/{organizationId}/...' \
  -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN'
```

Replace `YOUR_SERVICE_ACCOUNT_TOKEN` with the token copied during creation, and `{organizationId}` with your organization's identifier.

* * *

## Storing the token securely

The Bearer token grants Workspace-level access. Treat it like a password:

-   **Never commit it to source control.** Store it as a secret in your CI/CD platform, secret manager, or environment variable.
    
-   **One Service Account per integration.** Create a separate Service Account for each external system (e.g., one for BrowserStack, one for a Workspace automation script). This limits the blast radius if a token is compromised and makes it easy to rotate without affecting other systems.
    
-   **Rotate tokens periodically.** Delete and recreate Service Accounts as part of your regular credential rotation policy.
    

**CI/CD platforms — where to store the token:**

| Platform | Where to store |
| --- | --- |
| GitHub Actions | Repository or organization Secret |
| Azure Pipelines | Pipeline Variable (secret) |
| Bitrise | Secret (Protected toggle enabled) |
| Jenkins | Jenkins Credential (Secret text) |

* * *

## Managing existing Service Accounts

All Service Accounts in your Workspace are listed in the **Service Accounts** section under **Workspace Settings**. From this view, you can:

-   **View** the account identifier and role for each Service Account.
    
-   **Delete** a Service Account to immediately revoke its access. Any system using the deleted account's token will receive `401 Unauthorized` errors on subsequent requests.
    

There is no way to retrieve or regenerate a token for an existing Service Account. If a token needs to be replaced, delete the account and create a new one.

* * *

## Where Service Accounts are required

The following Applivery features and integrations authenticate using a Service Account Bearer token:

| Feature | Reason |
| --- | --- |
| Workspace API (Organizations API) | All Workspace API endpoints require Service Account authentication. |
| BrowserStack App Live integration | App Live connects to your Applivery Workspace using a Service Account Bearer token. |
| Cross-app automation scripts | Any script that reads or writes data across multiple Apps needs Workspace-level access. |