Managing API Keys

Overview

An API key (also called a Personal Access Token, or PAT) lets your scripts, CI pipelines and tools sign in to TestKase as you, without your password. The same key works for every product:

Create an API Key

Follow these steps to generate a new Personal Access Token:

1. Open the profile menu (top right) → API Keys. The page lives on the main domain at testkase.com/api-keys. It is an account page available to every user, not an organization setting.
2. Click Create Key.
3. In the Create API Key dialog, enter a Key Name. Use a name that identifies its purpose, such as:
   • GitHub Actions — Production Pipeline
   • GitLab CI — Staging Tests
   • API Script — Nightly Report
   • Local Development
4. Select an expiration period from the dropdown — 30, 60, or 90 days, or Never (see Expiration Periods below).
5. Click Create API Key.
6. The API Key Created Successfully dialog displays your new token. Copy it immediately using the copy button, then click Done.

What a Token Looks Like

TestKase PATs are long, random strings beginning xyz_. After creation, the API Keys page masks the token entirely — the Key column shows a row of asterisks, and no part of the token is ever returned again.

Expiration Periods

TestKase offers a fixed set of expiration periods. Choose the shortest duration that meets your needs to follow the principle of least privilege:

Manage Keys

The API Keys page shows all your tokens in a table view. For each token, you can see:

Deleting a Token

To revoke a token, click the Delete button next to it and confirm the action. Deletion is immediate and irreversible:

• Any API calls using this token will immediately receive a 401 Unauthorized error.
• Any CI/CD pipelines using this token will fail on their next run.
• The token cannot be recovered — you must create a new one.

Using Your PAT

Automate

Put the key in the address your tests connect to:

https://x:[email protected]/wd/hub

Keep the x — it's a placeholder name. The full setup is in Quick Start: Automate.

Visual

Save the key as a CI secret named TESTKASE_TOKEN; the upload CLI reads it from there. See Uploading from CI.

Test Management API

API requests send the key by being included in the Authorization HTTP header using the Bearer scheme:

Authorization: Bearer YOUR_PAT_TOKEN

REST API

Include the header in any API request:

curl -H "Authorization: Bearer YOUR_PAT_TOKEN" \
  -H "Content-Type: application/json" \
  https://api.testkase.com/api/v1/projects/user/my-projects

MCP Server (AI Agents)

PATs also authenticate the MCP Server — connect AI agents like Claude, GitHub Copilot, and Cursor to manage tests through natural language. Set the TESTKASE_PAT_TOKEN environment variable in your agent config.

CI/CD Reporter CLI

Pass the token to the @testkase/reporter CLI using the --token flag. You'll also need your Organization ID, found on your Profile page. See the Automation guide for full pipeline setup.

npx @testkase/reporter report \
  --token YOUR_PAT_TOKEN \
  --project-id PRJ-1 \
  --org-id 1173 \
  --cycle-id TCYCLE-5 \
  --format junit \
  --results-file test-results/junit.xml

API Usage Examples

Here are common API calls you can make with your PAT:

List Your Projects

curl -H "Authorization: Bearer YOUR_PAT_TOKEN" \
  https://api.testkase.com/api/v1/projects/user/my-projects

Get Test Cases in a Project

curl -H "Authorization: Bearer YOUR_PAT_TOKEN" \
  https://api.testkase.com/api/v1/test-cases?projectId=PRJ-1

Get Test Cycles

curl -H "Authorization: Bearer YOUR_PAT_TOKEN" \
  https://api.testkase.com/api/v1/test-cycles?projectId=PRJ-1

CI/CD Usage

The primary use of PATs in CI/CD is authenticating the @testkase/reporter CLI. Here is how to securely configure the token in each platform:

GitHub Actions

Store the token as a repository secret named TESTKASE_PAT:

# Settings > Secrets and variables > Actions > New repository secret
# Name: TESTKASE_PAT
# Value: (paste your token)

# Reference in workflow:
--token ${{ secrets.TESTKASE_PAT }}

GitLab CI

Add as a masked CI/CD variable:

# Settings > CI/CD > Variables > Add variable
# Key: TESTKASE_PAT
# Value: (paste your token)
# Options: Mask variable ✓, Protect variable (optional)

# Reference in .gitlab-ci.yml:
--token $TESTKASE_PAT

Jenkins

Add as a "Secret text" credential:

# Manage Jenkins > Manage Credentials > Add Credentials
# Kind: Secret text
# ID: testkase-pat
# Secret: (paste your token)

# Reference in Jenkinsfile:
environment { TESTKASE_PAT = credentials('testkase-pat') }

Azure DevOps

Add as a secret pipeline variable:

# Pipeline > Edit > Variables > New variable
# Name: TESTKASE_PAT
# Value: (paste your token)
# Keep this value secret: ✓

# Reference in azure-pipelines.yml:
--token $(TESTKASE_PAT)

CircleCI

Add as a project environment variable:

# Project Settings > Environment Variables > Add Variable
# Name: TESTKASE_PAT
# Value: (paste your token)

# Reference in .circleci/config.yml:
--token $TESTKASE_PAT

For complete pipeline templates with the reporter CLI, see the Automation guide.

Token Scoping & Permissions

PATs inherit the full permissions of the user account that created them. Anything the key starts — an Automate session, a Visual upload, an API change — is recorded as you. In Test Management this means:

• If your account is a Project Admin, the token can perform all admin-level actions via the API.
• If your account is a User (regular member), the token is limited to the same actions you can perform in the UI.
• If your account is a Guest, the token has read-only access.

Multi-Project Access

A single PAT provides access to all projects that the token owner has access to. There is no per-project token scoping. If your account has access to 5 projects, the token can access all 5.

Token Rotation

Token rotation is the practice of periodically replacing tokens with new ones. This limits the impact of a token being compromised. Here is the recommended rotation process:

1. Generate a new token with the same name (appended with a version, e.g., "GitHub Actions v2").
2. Update the secret in your CI/CD platform or application with the new token.
3. Verify that the new token works by triggering a pipeline run or API call.
4. Delete the old token from the API Keys page once confirmed.

Recommended Rotation Schedule

Security Best Practices

1. Never commit tokens to source code. Use CI/CD secrets, environment variables, or secret management tools (Vault, AWS Secrets Manager, etc.) to store tokens.
2. Use descriptive names. Name tokens after their purpose and environment (e.g., "GitHub Actions — Production", "Local Dev — John") so you can identify and manage them easily.
3. One token per integration. Create a separate token for each CI/CD pipeline, application, or environment. This way, revoking one token does not break other integrations.
4. Use the shortest expiration that works. A 90-day token for CI/CD pipelines is a good default. Use 30-day tokens for temporary scripts or demos.
5. Delete tokens you no longer use. Regularly audit your token list and remove tokens for decommissioned pipelines, old environments, or departed team members.
6. Rotate before expiration. Set calendar reminders to rotate tokens 1-2 weeks before they expire. This avoids pipeline failures from expired tokens.
7. Monitor for unauthorized use. If you suspect a token has been compromised, delete it immediately and generate a replacement. Check recent API activity for unexpected requests.
8. Use dedicated service accounts for shared tokens. If multiple team members need API access, create a dedicated TestKase account (e.g., "[email protected]") with the minimum required role and generate tokens from that account.

FAQ

Questions