API Keys

A short introduction to Personal Access Tokens — creating one, using it, and keeping it safe.

Personal Access Tokens (PATs) allow you to authenticate with the TestKase API programmatically — for CI/CD pipelines, test automation, and integrations.

Creating a Token

Go to Profile → API Keys (or testkase.com/api-keys) — the page is titled Api Keys
Click Create Key
Give it a descriptive name (e.g., "CI/CD Pipeline") and pick an expiry
Click Create API Key, then copy the token — it's only shown once

Token Format

PATs start with xyz_ prefix:

xyz_abc123def456...

Using Tokens

In API Calls

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

In Test Frameworks

Pass the token as an environment variable to the TestKase reporter:

TESTKASE_PAT=xyz_your_token_here npx @testkase/reporter

In CI/CD

Store the token as a secret in your CI/CD platform and reference it in your pipeline config.

A token carries the same permissions as the user who created it — it never grants more than that person has. It also carries less: a token is accepted only on the endpoints that have been explicitly opened to token authentication.

A token is not a general-purpose key to the whole API. On an endpoint that has not been opened to token authentication, the request is refused with 403 PAT not allowed for this API — whoever created the token and whatever their role. That check runs before permissions are considered, so a token belonging to an Owner is refused exactly like a token belonging to a Guest.

Token authentication is enabled across the Test Management REST API — projects and project members, test cases, folders, test cycles, test plans, labels, issues, reports, attachments, integrations and the AI endpoints — which is what CI/CD pipelines and the TestKase reporter need.

It is deliberately not enabled for:

Personal Access Tokens themselves. You cannot create, list or revoke tokens with a token. Sign in to the app to manage them.
Billing and subscriptions. Plans, seats, invoices and payments are unreachable with a token.
Organization administration. Inviting or removing members, changing roles, product access and permission configuration are unreachable with a token. Reading your own organization's details is allowed; changing anything about its people is not.

Token limits

Maximum 10 active tokens per user. The eleventh is refused with "You can create a maximum of 10 Personal Access Tokens".
Letting a token expire does not free its slot. The limit counts every token you have not revoked — expiry is not revocation. Ten expired-but-unrevoked tokens will block you from creating an eleventh even though none of them still works. Revoke the dead ones to get the slots back.
Choose an expiry of 30, 60, or 90 days, or never when you create the token.
Never commit tokens to source code — use environment variables.

Revoking Tokens

Go to API Keys page
Click the revoke icon next to the token
The token is immediately invalidated

Method	Use Case
PAT (API Key)	CI/CD, Postman, test frameworks, scripts
Cookie	Browser sessions (automatic, handled by login)
JWT Bearer	Copy from login response for quick API testing

All three methods are supported simultaneously. The backend checks Authorization header first, then falls back to cookie.