Service Accounts

When to Use a Service Account

Service accounts are the recommended way to run tests from shared, non-human contexts. Use one when you want to:

• Run tests from CI/CD pipelines without tying them to a person's login.
• Give each pipeline, environment, or team its own labelled credentials so you can tell their runs apart.
• Rotate or revoke a set of credentials independently if they leak or a pipeline is retired, without disrupting your own access.

Creating a Service Account

Go to Team Management > Service Accounts and click Add Accounts. Enter an identifier (at least 3 characters) and click Submit.

The new service account appears in the table straight away with its generated TestingBot Key and TestingBot Secret. Use the eye icon to reveal a value and the copy icon to copy it. You can come back and reveal these credentials at any time, so there is no one-time "save it now" step.

The Identifier

The identifier is a human-friendly label you give the service account, for example ci-runner or nightly-regression. It is used to mark the tests run by that service account on your dashboard and on the test detail page, so you can see at a glance which pipeline or environment started a test.

The identifier must be at least 3 characters and must be unique within your account. You can change it later at any time.

Using the Credentials

Use the service account's key and secret anywhere you would normally use your own TestingBot key and secret.

Browsers + Device Grid

Point your tests at the TestingBot hub using the service account's key and secret:

https://YOUR_KEY:YOUR_SECRET@hub.testingbot.com/wd/hub

Or pass them in your capabilities (tb:options / key and secret) exactly as you would with a personal key/secret.

REST API

The REST API uses HTTP Basic authentication with the key and secret:

curl -u YOUR_KEY:YOUR_SECRET https://api.testingbot.com/v1/tests

We recommend storing the key and secret as environment variables or CI secrets, never committing them to source control.

Editing a Service Account

To rename a service account, open the actions menu (the ... button) next to it and choose Edit. Change the identifier and click Submit. Editing the identifier does not change the key or secret.

Rotating the Access Key

From the actions menu, choose Rotate access key to generate a fresh key and secret for the service account. This is useful if a credential may have leaked.

Rotating takes effect immediately: the previous key and secret stop working right away, so any automation still using the old credentials will start failing to authenticate. Update your pipelines with the new key and secret after rotating.

Deleting a Service Account

From the actions menu, choose Delete to remove a service account. Its key and secret stop working immediately. Tests that were already run by the service account stay in your account and keep their history; they remain labelled with the identifier on the test detail page.

How Test Runs Are Attributed

Tests started by a service account run on your account owner's subscription: they consume your plan's concurrency and minutes and are visible to your team, just like any other test. On the test detail page, the Started by field shows the service account's identifier so you can tell its runs apart from those of human team members.

Service Accounts vs Sub-Accounts

Both run tests under your account, but they serve different purposes:

• Sub-account: a person on your team. It has a dashboard login, can view and manage tests, and can be given roles (Admin / Member / Viewer). See Team & Sub-Accounts.
• Service account: an API-only identity for automation. It has no dashboard login, no role management, and no 2FA. It exists purely to run tests with a dedicated, rotatable key and secret.