API Keys

Overview

Personal Access Tokens (PATs) provide secure, authenticated access to the TestKase API and CI/CD integrations. Each token is tied to your user account, inherits your permissions, and acts as a password substitute for programmatic access. PATs are essential for:

• API requests — Authenticate calls to the TestKase REST API for automation, scripting, and custom integrations.
• CI/CD pipelines — Authenticate the @testkase/reporter CLI to push test results from your CI pipelines.
• Third-party tools — Connect external tools and services that need programmatic access to your TestKase data.

Create an API Key

Follow these steps to generate a new Personal Access Token:

1. Navigate to Settings → API Keys in your organization settings.
2. Click Generate New Token.
3. Enter a descriptive name for the token. 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 (see Expiration Periods below).
5. Click Generate.
6. A dialog displays your new token. Copy it immediately using the copy button.

What a Token Looks Like

TestKase PATs are long, random strings. You will see only a partial preview (first and last few characters) in the API Keys management page after creation:

tk_pat_a1b2c3d4...x9y8z7  (full token shown only at creation)

Expiration Periods

Every token must have an expiration period. Choose the shortest duration that meets your needs to follow the principle of least privilege:

Manage Keys

The API Keys settings page shows all your active 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

PATs authenticate requests 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-projects

CI/CD Reporter CLI

Pass the token to the @testkase/reporter CLI using the --token flag. 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-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. 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 7-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., "ci-bot@yourcompany.com") with the minimum required role and generate tokens from that account.

FAQ